Recenzja: Swift Playgrounds 3.0 dla iPada

Aplikacja Swift Playgrounds dla iPada zawsze była nieco rozdarta między dwoma skrajnie różnymi rodzajami przypadków użycia. Z jednej strony, został wyraźnie zbudowany z głównym naciskiem na edukację i jest doskonałym narzędziem dla początkujących – ale z drugiej strony, działa również jako jedyny sposób dla profesjonalnych programistów, aby uruchomić kod Swift lokalnie na iPadzie.

Ciekawe, że rodzaj stawia Swift Playgrounds w bardzo podobnej pozycji jak iPad jako całości – w tym, że zarówno musi zaspokoić casual i proste przypadki użycia, jak również działać jako zdolne narzędzie dla bardziej zaawansowanych, zwłaszcza biorąc pod uwagę rosnącą popularność iPad Pro jako kompletnej platformy obliczeniowej.

W tym tygodniu przyjrzyjmy się, jak dobrze nowa wersja 3.0 Swift Playgrounds zachowuje równowagę między prostotą a mocą, i jak niektóre z jej nowych funkcji naprawdę poprawiają sposoby, w jakie może być używana jako wysoce przenośne, zaawansowane narzędzie programistyczne Swift.

Praca, zabawa i edukacja

Nie trzeba długo czekać, aby zdać sobie sprawę, że głównym celem Swift Playgrounds jest służyć jako narzędzie dla studentów, edukatorów i osób, które chcą rozpocząć naukę kodowania. Zaraz po otwarciu go, aplikacja wyraźnie prezentuje różne lekcje kodowania i wyzwania edukacyjne – i wszystko, od języka używanego do elementów menu i poleceń, do notatki wydania aplikacji w App Store, mają wyraźny nacisk na edukację.

Jednakże, po otwarciu pustego placu zabaw i rozpoczęciu kodowania, rzeczywiste możliwości aplikacji zawsze były dość imponujące – od sposobu, w jaki zapewnia pełny dostęp do iOS SDK i Foundation, do tego, jak pozwala nam natywnie renderować widoki i kontrolery widoku za pomocą PlaygroundPage.current.liveView, do szybkości kompilatora – szczególnie na najnowszych modelach iPada Pro.

Wersja 3.0 dodaje również kilka bardzo pożądanych ulepszeń do mieszanki. Na początek, kompilator został teraz zaktualizowany do wersji Swift 5.0, a ogólna stabilność edytora i sposób, w jaki współdziała z kompilatorem, również zostały poprawione. Gdy wystąpi awaria lub błąd runtime, aplikacja nie prezentuje już prostego widoku alertu mówiącego, że coś poszło nie tak, ale raczej prezentuje bogate komunikaty o błędach obok linii kodu, która spowodowała błąd – a błędy kompilacji są teraz wyświetlane na liście „Problemy”, podobnej do tej, którą można znaleźć w Xcode.

Moduły ułatwione

Prawdopodobnie największym usprawnieniem dla programistów chcących używać Swift Playgrounds jako właściwego narzędzia programistycznego, jest dodana obsługa modułów zawierających wiele plików źródłowych. Moduły Swift są w zasadzie „czystym Swift” odpowiednikiem biblioteki lub frameworka, a sposób, w jaki zostały one zintegrowane z aplikacją Playgrounds, jest po prostu fantastyczny.

Nową ikonę dokumentu można teraz znaleźć w lewym górnym rogu edytora – a dotknięcie jej powoduje wyświetlenie okienka, które pozwala nam przeglądać i modyfikować bieżące pliki źródłowe i moduły placu zabaw. Zarówno nowe pliki jak i nowe moduły mogą być dodawane za pomocą kilku stuknięć, a każdy nowy plik źródłowy jest automatycznie otwierany jako nowa karta w edytorze. Jest to bezproblemowe, szybkie i sprawia, że trywialnie jest zacząć dzielić większy kawałek kodu na osobne moduły. Każdy moduł jest również automatycznie importowany do placu zabaw, podczas gdy nadal wymaga jawnego importu między modułami.

Porównaj powyższe z tym, ile kroków zajmuje dodanie nowego frameworka Swift w Xcode.

Modularyzacja może być często kluczem do łatwiejszego utrzymania projektu – zwłaszcza, gdy ilość funkcji i plików źródłowych rośnie. Dzieląc rzeczy na osobne moduły, z których każdy ma swoją własną odpowiedzialność i domenę, możemy zarówno zapewnić odpowiednią separację obaw, jak i łatwo zidentyfikować problemy architektoniczne, np. gdy dwa odrębne fragmenty kodu są zbyt silnie sprzężone lub gdy widok przyjmuje zbyt wiele założeń dotyczących danych, które renderuje (ponieważ uzyskanie dostępu do takich informacji wymagałoby teraz zaimportowania innego modułu).

Moduły umożliwiają nam również korzystanie z poziomu kontroli dostępu internal i sprawiają, że typy i funkcje, które są przeznaczone tylko do użytku wewnętrznego w module, są niedostępne spoza tego modułu. Ponieważ internal jest domyślnym poziomem dostępu w Swift, oznacza to również, że musimy jawnie oznaczyć typy i funkcje, które chcemy sprzedawać jako część publicznego API naszego modułu, jako public. Podczas gdy niektórzy programiści mogą uważać, że jest to trochę „przykry obowiązek”, zmusza nas to do projektowania bardziej przejrzystych i dobrze zdefiniowanych interfejsów API.

Kompatybilność z Xcode

Although Swift Playgrounds zyskał teraz dużo mocy i kilka nowych funkcji, które czynią go znacznie bardziej wydajnym narzędziem deweloperskim, jest daleki od całkowitego zastąpienia Xcode dla większości przypadków użycia – ani nawet nie próbuje być. Istnieją uzasadnione powody, dla których nazywa się „Swift Playgrounds”, a nie „Xcode dla iPada” (choć miejmy nadzieję, że zobaczymy to ostatnie w pewnym momencie, jak również). Jest to narzędzie do zabawy z pomysłami, do robienia lekkiego kodowania w podróży, a do budowania prototypów i izolowanych modułów – a nie jest to kompletne IDE z obsługą złożonych projektów.

Więc ponieważ – dla większości programistów – Swift Playgrounds będzie najprawdopodobniej działać jako uzupełnienie Xcode, a nie zamiennik, po prostu jak łatwo jest przenieść projekty i kod między tymi dwoma? Niestety, odpowiedź brzmi, w przeważającej części, nie tak łatwo. Chociaż aplikacje takie jak Working Copy (disclaimer: były sponsor), a narzędzia takie jak Shapeshift (disclaimer: napisane przeze mnie) sprawia, że dość trywialne, aby przenieść rzeczywisty kod źródłowy między Mac i iPad – jest niestety bardzo mało bezpośredniej kompatybilności między Swift Playgrounds i Xcode.

Na początek, używają różnych formatów plików. Xcode nadal używa formatu .xcodeproj bundle, którego używa od lat, i chociaż pliki .playground utworzone przez Xcode mogą być otwierane na iPadzie, place zabaw, które są tworzone w samej aplikacji Playgrounds używa formatu .playgroundbook tylko dla iPada.

Jedyną rzeczą, którą Xcode 10 jest w stanie zrobić z książkami Swift Playgrounds jest wyświetlanie ikony – miejmy nadzieję, że to się zmieni przyjść w tym roku WWDC.

To oznacza, że nawet jeśli jesteśmy teraz w stanie łatwo tworzyć moduły i hierarchie plików na iPadzie, gdy chcemy przenieść nasz kod z powrotem na Maca (co, w przypadku gdy budujemy aplikację, musimy zrobić w pewnym momencie), musimy przeorganizować ten kod w coś, co jest kompatybilne z Xcode – na przykład poprzez dodawanie plików do projektów Xcode i tworzenie frameworków dla naszych modułów.

Miejmy nadzieję, że przyszłe wersje zarówno Swift Playgrounds, jak i Xcode przyniosą bardziej znormalizowany format projektu (jak niesamowite nie byłoby, gdyby wszystkie narzędzia deweloperskie Apple używały menedżera pakietów Swift i jego Package.swift manifestu do definiowania projektów?), co znacznie ułatwiłoby przenoszenie całych projektów do i z iPada – potencjalnie otwierając jeszcze bardziej zaawansowane przypadki użycia i umożliwiając nam edycję całych aplikacji w podróży.

Umożliwienie testowania

Kolejnym aspektem rozwoju Swift, którego tak bardzo brakuje w Swift Playgrounds na iPadzie, jest wsparcie dla testów jednostkowych i UI. Nie tylko aplikacja nie oferuje żadnego rodzaju wbudowany sposób na uruchomienie testów, to nawet nie pochodzą z XCTest ramki, że większość deweloperów Swift polegać, jeśli chodzi o jakąkolwiek formę zautomatyzowanego testowania.

Czy to znaczy, że pisanie testów na iPadzie jest całkowicie wykluczone? Na szczęście nie. Dla wszystkich swoich ograniczeń, Swift Playgrounds nadal mieści kompletny kompilator Swift, a ponieważ XCTest jest – na koniec dnia – nic oprócz kodu, możemy dość łatwo ponownie zaimplementować niektóre z jego podstawowych aspektów w samym Swift Playgrounds!

(To nie byłby artykuł o Swift by Sundell bez kilku próbek kodu, prawda? 😉 )

Zacznijmy od zdefiniowania „okrojonej” wersji klasy XCTestCase, ale jako protokołu. Będziemy wymagać, aby wszystkie przypadki testowe miały pusty inicjalizator (abyśmy mogli dynamicznie tworzyć instancje), metody do tworzenia i niszczenia każdego przebiegu testu, a także zainspirowaną Swift Package Managerem właściwość allTests, aby dać naszemu biegaczowi testowemu dostęp do każdej metody testowej, którą chcemy uruchomić:

protocol XCTestCase { init() func setUp() func tearDown() static var allTests: { get }}

While mogliśmy zaimplementować XCTestCase jako klasę konkretną zamiast tego i wykorzystać Objective-C runtime w celu identyfikacji metod testowych – tak jak robi to sam XCTest na platformach Apple – wymagałoby to od nas oznaczenia każdej metody za pomocą @objc, a także sprawiłoby, że nasz kod byłby mniej przenośny w przypadku, gdybyśmy chcieli wdrożyć go na platformach takich jak Linux.

Następnie, rozszerzmy nasz protokół XCTestCase o metodę, która pozwala nam uruchomić dany przypadek testowy (poprzez wyliczenie wszystkich jego metod i wywołanie każdej z nich), jak również puste domyślne implementacje setUp i tearDown:

Mając powyższe na miejscu, jesteśmy teraz w stanie zdefiniować przypadki testowe, ale potrzebujemy również sposobu na przeprowadzenie weryfikacji i asercji, gdy piszemy naszą rzeczywistą logikę testową. Aby to ułatwić, zacznijmy od zaimplementowania funkcji XCTFail, która pozwala nam na przerwanie testu w przypadku, gdy pewien warunek nie został spełniony. Przekażemy jej opcjonalny argument reason i automatycznie zapiszemy nazwę funkcji testowej, w której została wywołana, jak również numer linii – tak jak poniżej:

Korzystając z powyższego, możemy teraz zaimplementować funkcję XCTAssertEqual, która pozwoli nam stwierdzić, że wynik operacji okazał się równy wynikowi, którego oczekiwaliśmy:

To naprawdę wszystko, czego potrzebujemy, aby zacząć pisać podstawowe testy. Na przykład, oto jak moglibyśmy teraz sprawdzić, czy typ Playlist poprawnie śledzi swoje utwory, jak również upewnić się, że jego kod serializujący działa zgodnie z oczekiwaniami:

Aby uruchomić nasze powyższe testy, po prostu wywołujemy run() na typie przypadku testowego:

try PlaylistTests.run()

To może nie być kompletna re-implementacja XCTest, i musielibyśmy ciągle dodawać każdą funkcję asercji i funkcję testową, której będziemy potrzebować ręcznie – ale pokazuje to, że wiele różnych zaawansowanych funkcji programistycznych jest technicznie możliwych na iPadzie – czasami potrzebujemy tylko trochę czasu i kreatywności, aby je zrealizować.

Wspieraj Swift by Sundell, sprawdzając tego sponsora:

Podsumowanie

Wersja 3.0 Swift Playgrounds na iPada to fantastyczna aktualizacja już zachwycającej aplikacji – która dodaje nowe, potężne możliwości i sprawia, że podstawowe funkcje programistyczne, takie jak raportowanie błędów, są o wiele bardziej wydajne – a wszystko to przy jednoczesnym zachowaniu nacisku na łatwość obsługi i zawartość edukacyjną.

Swift 5, moduły, edycja w zakładkach i zarządzanie plikami źródłowymi to wspaniałe funkcje, które sprawiają, że ta wersja Swift Playgrounds jest jeszcze najbardziej wydajna – i jest to duży krok w kierunku umożliwienia wykonywania wielu innych zadań związanych z rozwojem Swift na iPadzie. Podobnie jak w przypadku pracy na iPadzie w ogóle, przy użyciu Swift Playgrounds czasami wymaga trochę dodatkowej cierpliwości i obejścia, ale wynik może często zrobić dla potężnego środowiska programistycznego na bardzo przenośnego urządzenia.

Swift Playgrounds nadal nie jest „Xcode zabójca”, i to prawdopodobnie nigdy nie będzie, ale to jest OK. Podczas gdy lepsza interoperacyjność z Xcode (zwłaszcza w zakresie formatów plików i struktury projektu) i bardziej zaawansowane funkcje edytora (takie jak refaktoryzacja i narzędzia do zastępowania tekstu) byłyby zdecydowanie bardziej niż mile widziane, tak długo, jak mogę szybko pisać kod Swift w podróży, będę bardziej niż szczęśliwy – przynajmniej czekając na „Xcode dla iPada”, aby przybyć.

.