iPad 用 Swift Playgrounds アプリは、常に 2 つの大きく異なる種類のユースケースの間で少し揉めています。 一方では、明らかに教育に主眼を置いて構築され、初心者にとって素晴らしいツールですが、他方では、プロの開発者が自分の iPad でローカルに Swift コードを実行する唯一の方法としても機能します。

今週は、Swift Playgrounds の新しいバージョン 3.0 がシンプルさとパワーのバランスをどの程度保っているか、また、その新機能のいくつかが、非常にポータブルで高度な Swift 開発ツールとして使用する方法をどのように向上させるかについて見ていきたいと思います。 Instabug が各バグレポートに自動的に添付する詳細なスタック トレース、ネットワーク ログ、および UI イベントを使用して、バグ、クラッシュ、およびその他の問題をより迅速に解決します。 私と世界中の何千もの iOS 開発チームの両方によって使用されます。 3663>

仕事、遊び、教育

Swift Playgrounds の主な目的は、学生、教育者、およびコードの学び方を始めたい人のためのツールとして機能することだと理解するのに時間はかかりません。 アプリを起動するとすぐに、さまざまなコーディングのレッスンや学習課題が目立つように表示され、メニュー項目やコマンドに使用されている言語から、App Store でのアプリのリリース ノートまで、すべてが教育に焦点を当てていることが明らかです。PlaygroundPage.current.liveView を使用してビューおよびビュー コントローラーをネイティブにレンダリングする方法、そしてコンパイラーの速度 (特に最新の iPad Pro モデル) までです。 まず、コンパイラーは Swift 5.0 バージョンに更新され、エディターとコンパイラーとの相互作用の全体的な安定性も改善されました。 クラッシュまたはランタイム エラーが発生した場合、アプリは何かがうまくいかなかったという単純なアラート ビューを表示しませんが、エラーを引き起こしたコード行の横に豊富なエラー メッセージを表示します。 Swift モジュールは、本質的にライブラリまたはフレームワークの「純粋な Swift」に相当し、Playgrounds アプリケーションに統合された方法は、単に素晴らしいものです。 新しいファイルやモジュールは、数回のタップで追加でき、新しいソースファイルは、エディタ内の新しいタブとして自動的に開かれます。 新しいソースファイルは、エディタ内の新しいタブとして自動的に開かれます。これはシームレスで高速であり、大きなコードを個別のモジュールに分割することも簡単です。 各モジュールは、モジュール間の明示的なインポートを必要としながらも、自動的にプレイグラウンドにインポートされます。

Xcode で新しい Swift フレームワークを追加するのにかかる多くのステップと上記を比較してみてください。 それぞれ独自の責任と領域を持つ別々のモジュールに物事を分割することにより、懸念事項の分離をかなり確実にすることができ、また、コードの 2 つの異なる部分が高度に結合されている場合、またはビューがレンダリングするデータについてあまりにも多くの仮定をしている場合 (そのような情報へのアクセスを得るには、現在別のモジュールをインポートする必要があるので) など、アーキテクチャーの問題を簡単に特定することができます。

また、モジュールは internal アクセス制御レベルを使用することを可能にし、モジュール内の内部使用のみを目的とした型および関数を、そのモジュールの外側からアクセスできないようにします。 internal は Swift のデフォルトのアクセスレベルなので、それはまた、私たちのモジュールのパブリック API の一部として売りたい型と関数を、public として明示的にマークする必要があることを意味します。 一部の開発者はそれを少し「面倒」だと考えるかもしれませんが、より明確でよく定義された API を設計する習慣を強制するようなものです。

Xcode との互換性

Swift Playgrounds が多くのパワーといくつかの新機能を得て、より有能な開発ツールになりましたが、ほとんどの使用例において Xcode を完全に代替するにはほど遠いです – そうなろうとすることさえしてません。 Swift Playgrounds」と呼ばれ、「Xcode for iPad」と呼ばれないのには、それなりの理由があります（後者もいつかは見られるといいのですが）。 これは、複雑なプロジェクトをサポートする完全な IDE というよりも、アイデアで遊んだり、外出先で軽いコーディングをしたり、プロトタイプや孤立したモジュールを構築したりするためのツールです。 悲しいことに、その答えは、ほとんどの場合、それほど簡単ではありません。 Working Copy (免責事項: 以前のスポンサー) のようなアプリや、Shapeshift (免責事項: 私が書いた) のようなツールは、Mac と iPad の間で実際のソースコードを移動することを非常に簡単にしますが、残念ながら Swift Playgrounds と Xcode の間にはほとんど直接的な互換性がありません。 Xcode は長年使用してきた .xcodeproj バンドル形式をまだ使用しており、Xcode で作成された .playground ファイルは iPad で開くことができますが、Playgrounds アプリケーション自体で作成される Playgrounds は iPad 専用の .playgroundbook 形式を使用します。Swift Playgrounds と Xcode の両方の将来のバージョンで、より正常なプロジェクト形式がもたらされることを期待します (Apple のすべての開発者ツールが Swift Package Manager とその Package.swift マニフェストを使用してプロジェクトを定義したら、どれほど素晴らしいことでしょう)。さらに高度なユースケースを開く可能性があり、外出先でアプリ全体を編集できるようになります。

Enabling testability

iPad 上の Swift Playgrounds からひどく失われた Swift 開発の別の側面は、ユニットおよび UI テストに対するサポートです。 アプリはテストを実行するための組み込みの方法を提供しないだけでなく、自動テストの任意のフォームに来るとき、ほとんどの Swift 開発者が依存している XCTest フレームワークさえも付属していないのです。 ありがたいことに、そうではありません。 その制限のすべてについて、Swift Playgrounds はまだ完全な Swift コンパイラーを収容し、XCTest は – 一日の終わりに – コード以外の何ものでもないので、私たちは非常に簡単に Swift Playgrounds 自身の中で正しいそれのコア側面の一部を再実装できました！XCTestは、Swift Playgrounds を使用するために必要なすべての機能を提供します。

（いくつかのコードサンプルがなければ、Swift by Sundell の記事にはなりませんよね）

XCTestCase クラスの「縮小版」、しかし代わりにプロトコルとしての定義から始めましょう。 すべてのテストケースに空のイニシャライザー (インスタンスを動的に作成できるように)、各テスト実行のセットアップとテイルダウンのためのメソッド、および Swift パッケージマネージャにヒントを得た allTests プロパティを必要とし、テストランナーに実行したい各テストメソッドへのアクセスを提供します。

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

代わりに具象クラスとして XCTestCase を実装し、テスト メソッドを識別するために Objective-C ランタイムを使用することもできますが (Apple プラットフォームで XCTest 自体がそれを行う方法と同様)、それは @objc でそれぞれのメソッドをマークする必要があり、また、Linux などのプラットフォームでそれを展開したい場合にコードの移植性が低くなる可能性があります。

次に、与えられたテストケースを (そのメソッドをすべて列挙してそれぞれを呼び出すことにより) 実行できるメソッドと、setUp および tearDown の空のデフォルト実装で XCTestCase プロトコルを拡張しましょう：

以上のようにして、テストケースを定義できましたが、実際のテスト ロジックを記述しながら検証および主張を行う方法も必要です。 そのために、まずはXCTFail関数を実装しましょう。この関数を使うと、特定の条件が満たされなかった場合にテストを失敗させることができます。 この関数にはオプションの reason 引数を与え、それが呼び出されたテスト関数の名前と行番号を自動的に記録します (例:

上記を使用して、今度は XCTAssertEqual 関数を実装します。 たとえば、Playlist 型がその曲を正しく追跡していることを検証し、そのシリアライズ コードが期待どおりに動作することを確認する方法は次のとおりです：

上記のテストを実行するには、テスト ケースの型に対して run() を呼び出すだけでよい。

try PlaylistTests.run()

これは、XCTest の完全な再実装ではないかもしれませんし、必要なアサーション関数やテスト機能を手動で追加し続けなければなりません。

Swift by Sundell をサポートするには、このスポンサーをチェックしてください:

Instabug: Instabug が各バグ レポートに自動的に添付する詳細なスタック トレース、ネットワーク ログ、および UI イベントを使用して、バグ、クラッシュ、その他の問題をより迅速に解決します。 私と世界中の何千もの iOS 開発チームの両方によって使用されます。 3663>

Conclusion

iPad 用 Swift Playgrounds の 3.0 バージョンは、使いやすさと教育的コンテンツに焦点を当てながら、強力な新機能を追加し、エラー報告などのコア開発機能をより高性能にした、すでに楽しいアプリのすばらしいアップデートです。

Swift 5、モジュール、タブ編集、およびソース ファイル管理はすべて、このバージョンの Swift Playgrounds をこれまでで最も高性能にする素晴らしい機能であり、iPad でより多くの Swift 開発タスクを実行可能にするための大きな一歩となりました。 一般的な iPad での作業と同様に、Swift Playgrounds を使用することは、時には特別な忍耐と回避策を必要としますが、その結果、非常にポータブルなデバイス上で強力な開発環境を実現することができます。 Xcode とのより良い相互運用性 (特にファイル形式とプロジェクト構造の面で) とより高度なエディター機能 (リファクタリングやテキスト置換ツールなど) は間違いなく大歓迎ですが、移動中に素早く Swift コードを書くことができる限り、私はより満足するでしょう – 少なくとも「Xcode for iPad」の到着を待つ間は。