Recenze: Swift Playgrounds 3.0 pro iPad

Aplikace Swift Playgrounds pro iPad byla vždy trochu rozpolcená mezi dvěma značně odlišnými způsoby použití. Na jedné straně byla zjevně vytvořena s primárním zaměřením na vzdělávání a jako skvělý nástroj pro začátečníky – ale na druhé straně také funguje jako jediný způsob, jak mohou profesionální vývojáři spouštět kód ve Swiftu lokálně na svém iPadu.

Zajímavé je, že to tak trochu staví Swift Playgrounds do velmi podobné pozice jako iPad jako celek – v tom smyslu, že musí uspokojit jak příležitostné a jednoduché případy použití, tak působit jako schopný nástroj pro ty pokročilejší, zejména vzhledem k rostoucí popularitě iPadu Pro jako kompletní výpočetní platformy.

Tento týden se podíváme na to, jak dobře nová verze 3.0 Swift Playgrounds balancuje mezi jednoduchostí a výkonem a jak některé její nové funkce skutečně zlepšují způsoby, jak ji lze použít jako vysoce přenosný, pokročilý vývojový nástroj Swift.

Práce, hra a vzdělávání

Nemusíte dlouho přemýšlet, abyste si uvědomili, že hlavním účelem Swift Playgrounds je sloužit jako nástroj pro studenty, pedagogy a pro lidi, kteří se chtějí začít učit programovat. Aplikace hned po otevření viditelně prezentuje různé lekce kódování a výukové úkoly – a vše, od jazyka použitého pro položky nabídky a příkazy až po poznámky k vydání aplikace v App Store, má jasné zaměření na vzdělávání.

Jakmile však otevřete prázdné hřiště a začnete kódovat, skutečné možnosti aplikace byly vždy docela působivé – od způsobu, jakým poskytuje plný přístup k iOS SDK a Foundation, přes to, jak nám umožňuje nativně vykreslovat pohledy a kontroléry pohledů pomocí PlaygroundPage.current.liveView, až po rychlost překladače – zejména na nejnovějších modelech iPad Pro.

Verze 3.0 také přidává několik velmi vítaných vylepšení. Pro začátek byl překladač aktualizován na verzi Swift 5.0 a zlepšila se také celková stabilita editoru a způsob jeho interakce s překladačem. Když dojde k pádu nebo chybě při běhu, aplikace již nezobrazuje jednoduché zobrazení s upozorněním, že se něco pokazilo, ale zobrazuje bohaté chybové hlášení vedle řádku kódu, který chybu způsobil – a chyby při kompilaci se nyní zobrazují v seznamu „Issues“, podobném tomu, který najdete v Xcode.

Moduly jsou snadné

Možná největším vylepšením pro vývojáře, kteří chtějí používat Swift Playgrounds jako správný vývojový nástroj, je přidaná podpora modulů obsahujících více zdrojových souborů. Moduly Swift jsou v podstatě „čistou swiftovskou“ obdobou knihovny nebo frameworku a způsob, jakým byly integrovány do aplikace Playgrounds, je prostě fantastický.

V levém horním rohu editoru nyní najdeme novou ikonu dokumentu – klepnutím na ni se zobrazí vyskakovací okno, které nám umožní procházet a upravovat zdrojové soubory a moduly aktuálního Playgroundu. Nové soubory i moduly lze přidávat několika klepnutími a každý nový zdrojový soubor se v editoru automaticky otevře jako nová karta. Je to bezproblémové, rychlé a umožňuje to triviálně začít rozdělovat větší kus kódu na samostatné moduly. Každý modul se také automaticky importuje do hřiště, přičemž se stále vyžaduje explicitní import mezi moduly.

Srovnejte výše uvedené s tím, kolik kroků zabere přidání nového frameworku Swift v Xcode.

Modularizace může být často klíčová pro usnadnění údržby projektu – zejména s rostoucím množstvím funkcí a zdrojových souborů. Rozdělením věcí do samostatných modulů, z nichž každý má svou vlastní zodpovědnost a doménu, můžeme jednak zajistit dostatečné oddělení zájmů – a také snadno identifikovat architektonické problémy, například když jsou dvě různé části kódu příliš úzce provázané nebo když pohled vytváří příliš mnoho předpokladů o datech, která vykresluje (protože získání přístupu k těmto informacím by nyní vyžadovalo import dalšího modulu).

Moduly nám také umožňují využívat úroveň řízení přístupu internal a znemožnit přístup k typům a funkcím, které jsou určeny pouze pro vnitřní použití v rámci modulu, mimo tento modul. Protože internal je ve Swiftu výchozí úrovní přístupu, znamená to také, že typy a funkce, které chceme prodávat jako součást veřejného API našeho modulu, musíme explicitně označit jako public. I když to někteří vývojáři mohou považovat za trochu „povinnost“, tak trochu nás to nutí k návyku navrhovat jasnější a lépe definované API.

Kompatibilita s Xcode

Přestože Swift Playgrounds nyní získal mnoho výkonu a několik nových funkcí, které z něj dělají mnohem schopnější vývojový nástroj, zdaleka není plnohodnotnou náhradou Xcode pro většinu případů použití – a ani se o to nesnaží. Existují dobré důvody, proč se jmenuje „Swift Playgrounds“, a ne „Xcode pro iPad“ (i když doufejme, že se někdy dočkáme i toho druhého). Je to nástroj pro hraní si s nápady, pro lehké kódování na cestách a pro vytváření prototypů a izolovaných modulů – spíše než kompletní IDE s podporou komplexních projektů.

Protože tedy – pro většinu vývojářů – bude Swift Playgrounds s největší pravděpodobností fungovat spíše jako doplněk Xcode než jako jeho náhrada, jak snadné je přesouvat projekty a kód mezi nimi? Odpověď bohužel zní, že většinou ne tak snadno. Ačkoli aplikace jako Working Copy (disclaimer: bývalý sponzor) a nástroje jako Shapeshift (disclaimer: napsaný mnou) umožňují poměrně triviální přesun skutečného zdrojového kódu mezi Macem a iPadem – přímá kompatibilita mezi Swift Playgrounds a Xcode je bohužel velmi malá.

Pro začátek používají různé formáty souborů. Xcode stále používá formát .xcodeproj svazků, který používá už léta, a přestože soubory vytvořené v Xcode .playground lze otevřít na iPadu, playgroundy vytvořené v samotné aplikaci Playgrounds používají formát .playgroundbook určený pouze pro iPad.

Jediné, co Xcode 10 umí s knihami Swift Playgrounds, je zobrazit ikonu – doufejme, že se to změní s letošní konferencí WWDC.

To znamená, že i když jsme nyní schopni snadno vytvářet moduly a hierarchie souborů na iPadu, jakmile budeme chtít náš kód přesunout zpět na Mac (což v případě, že vytváříme aplikaci, musíme v určitém okamžiku udělat), musíme tento kód znovu uspořádat do něčeho, co je kompatibilní s Xcode – například přidáním souborů do projektů Xcode a vytvořením rámců pro naše moduly.

Doufejme, že budoucí verze Swift Playgrounds i Xcode přinesou normovanější formát projektu (jak by nebylo úžasné, kdyby všechny vývojářské nástroje Apple používaly k definování projektů správce balíčků Swift a jeho Package.swift manifest?), díky čemuž by bylo mnohem snazší přenášet celé projekty do iPadu a z iPadu – což by mohlo otevřít ještě pokročilejší případy použití a umožnit nám upravovat celé aplikace na cestách.

Zpřístupnění testovatelnosti

Dalším aspektem vývoje ve Swiftu, který ve Swift Playgrounds na iPadu velmi chybí, je podpora jednotkových testů a testů uživatelského rozhraní. Nejenže aplikace nenabízí žádný vestavěný způsob spouštění testů, ale dokonce ani neobsahuje framework XCTest, na který se většina vývojářů Swiftu spoléhá, pokud jde o jakoukoli formu automatizovaného testování.

Znamená to tedy, že psaní testů na iPadu je zcela vyloučeno? Naštěstí ne. Přes všechna svá omezení Swift Playgrounds stále obsahuje kompletní kompilátor Swiftu, a protože XCTest není – koneckonců – nic jiného než kód, mohli bychom některé jeho základní aspekty docela snadno reimplementovat přímo v samotném Swift Playgrounds!

(Nebyl by to článek o Swiftu od Sundella bez ukázek kódu, že? 😉)

Začněme tím, že definujeme „ořezanou“ verzi třídy XCTestCase, ale místo toho jako protokol. Budeme požadovat, aby všechny testovací případy měly prázdný inicializátor (abychom mohli dynamicky vytvářet instance), metody pro nastavení a zrušení každého spuštění testu a také vlastnost allTests inspirovanou správcem balíčků Swift, která našemu testovacímu běhu umožní přístup ke každé testovací metodě, kterou chceme spustit:

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

Mohli bychom sice místo toho implementovat XCTestCase jako konkrétní třídu a využít běhové prostředí Objective-C k identifikaci testovacích metod – stejně jako to dělá samotná XCTest na platformách Apple – ale to bychom museli každou metodu označit @objc a náš kód by byl také méně přenositelný v případě, že bychom jej chtěli nasadit na platformách, jako je Linux.

Dále rozšíříme náš protokol XCTestCase o metodu, která nám umožní spustit daný testovací případ (výčtem všech jeho metod a voláním každé z nich), a také o prázdné výchozí implementace setUp a tearDown:

S výše uvedeným jsme nyní schopni definovat testovací případy, ale potřebujeme také způsob, jak provádět ověření a tvrzení při psaní naší skutečné testovací logiky. Abychom si to usnadnili, začneme implementací funkce XCTFail, která nám umožní selhat test v případě, že nebyla splněna určitá podmínka. Dáme jí nepovinný argument reason a automaticky zaznamenáme název testovací funkce, ve které byla zavolána, a také číslo řádku – například takto:

Pomocí výše uvedeného můžeme nyní implementovat funkci XCTAssertEqual, která nám umožní tvrdit, že výsledek operace se ukázal být roven výsledku, který jsme očekávali:

To je vlastně vše, co potřebujeme, abychom mohli začít psát základní testy. Například takto bychom nyní mohli ověřit, že typ Playlist správně sleduje své písně, a také se ujistit, že jeho serializační kód funguje podle očekávání:

Pro spuštění našich výše uvedených testů jednoduše zavoláme run() na typ testovacího případu:

try PlaylistTests.run()

Není to sice úplná reimplementace XCTest a každou funkci tvrzení a testovací funkci, kterou budeme potřebovat, bychom museli přidávat ručně – ale ukazuje to, že mnoho různých pokročilých vývojových funkcí je na iPadu technicky možné – jen k jejich realizaci někdy potřebujeme trochu času a kreativity.

Podpořte Swift by Sundell tím, že se podíváte na tohoto sponzora:

Závěr

Verze 3.0 aplikace Swift Playgrounds pro iPad je fantastická aktualizace již tak úžasné aplikace – která přidává nové výkonné funkce a výrazně zvyšuje možnosti základních vývojových funkcí, jako je hlášení chyb – to vše při zachování zaměření na snadné používání a vzdělávací obsah.

Swift 5, moduly, editace se záložkami a správa zdrojových souborů – to vše jsou skvělé funkce, díky kterým je tato verze aplikace Swift Playgrounds zatím nejschopnější – a je to velký krok k tomu, aby bylo možné na iPadu provádět mnoho dalších vývojových úloh ve Swiftu. Stejně jako pokud jde o práci na iPadu obecně, vyžaduje používání Swift Playgrounds někdy trochu více trpělivosti a obcházení, ale výsledkem může být často výkonné vývojové prostředí na vysoce přenosném zařízení.

Swift Playgrounds stále není „zabiják Xcode“ a pravděpodobně nikdy nebude, ale to je v pořádku. I když lepší interoperabilita s Xcode (zejména pokud jde o formáty souborů a strukturu projektů) a pokročilejší funkce editoru (například nástroje pro refaktoring a nahrazování textu) by byly rozhodně více než vítané, dokud budu moci rychle psát kód ve Swiftu na cestách, budu více než spokojený – alespoň při čekání na příchod „Xcode pro iPad“.