ここ数年で最も緊迫したニュース満載のWWDC の 1 つで、私たちが知っているすべてのことを明らかにする作業がまだ終わっていません。
しかし、プレゼンテーションの最後の 20 分でトーンが完全に変わったことに気付いた人も多いと思います。ユーザーの問題に焦点を当てた祝賀会から、私たちは純粋でシンプルな開発についての話に移りました。このパートでは、Apple システムでのネイティブ アプリ開発の将来に向けた革命的な第一歩となる SwiftUI を紹介しました。
その重要性とそれが Apple にとってどれほど大きな一歩であるかを理解できるように説明しましょう。これは、今後数年間で私たちが日常的に使用するアプリに影響を与えることになるでしょう。
古代ギリシャの静かな夜でした…
1979 年に遡ると、Steve Jobs、Jef Raskin、その他数人の幸運な Apple エンジニアは、マイクロコンピューティングの世界にまだ到来していない進化を求めてXerox PARC を訪れました。コンピュータは人々の家庭に届き始めていましたが、それが当時 Apple II に搭載されていたプログラミング言語 BASIC によるテキスト インターフェイスであったため、普及には役立ちませんでした。さらに前進する必要がありました。
その旅行中に、彼らは Xerox Alto を発見しました。これは、グラフィカル ユーザー インターフェイス(誰も見たことのないもの) と、マウスと呼ばれる矢印を制御する奇妙なデバイスを備えたポートレートモード モニターを備えたコンピューターです。
アラン・ケイ率いるゼロックスのエンジニアたちは、私が会社について理解していなかった破棄されたプロジェクトに基づいて、知らず知らずのうちにコンピューティングの未来を築いていました。しかし、彼らは単にコンピューターを作成しただけではありません。グラフィカル ユーザー インターフェイス用のアプリケーションの作成が非常に複雑になることを知っていたため、プログラミングの世界にも革命をもたらす独自の開発パラダイム、つまりMVC モデル (モデル )も考案しました。 -view-controller ) がオブジェクト指向に適用されます。
1983 年に Apple は Lisa を、ゼロックスは Alto を発売しましたが、価格が高かったため (18,000 ドル以上)、1984 年に Macintosh が登場するまで両方の製品は失敗に終わりました。これは 2 つの点で優れています。1 つ目は、より手頃な価格であることです (比較すると、2,495 ドルでした)。 2 番目のものには、学習ガイドとカセットテープ (はい、はい、テープ)が含まれた一連のディスクが付属しており、デッキに入れて [再生] を押すと、その仕組みと操作方法について段階的にガイドされる様子を聞くことができます。 . Macintosh のグラフィカル ユーザー インターフェイスと、ディスクに収録されているさまざまなアプリ。
そのコンピューターでの開発はまさに地獄でした。 Steve Jobs のチームは製品をリリースすることだけに専念し、その製品用のソフトウェアを作成する方法には専念していませんでした。グラフィカル インターフェイス用のアプリケーションの作成は、画面に表示される各ボタン、フィールド、または要素の各行をグラフィカルにプログラミングすることによって行われていました。コードは再利用できず、ライブラリ (またはフレームワーク) は存在せず、要素は何百、何千もありませんでした。線。ソフトウェアの開発を容易にすることは、Macintosh の発売後にジョブズがとるべき次のステップでしたが、すでに知られているように、ジョブズは共同設立した会社を辞めるよう誘われました。
そこで彼は NeXT を設立し、ゼロックス PARC で得た偉大な発見の残りの 50% を応用しました。それは、アラン ケイによるグラフィカル ユーザー インターフェイス用のアプリケーション作成の背後にあるテクノロジーの開発でした。 NeXT チーム全体の取り組みは 1988 年に開始され、革命でした。新しい Interface Builder アプリケーションと Objective-C 言語を使用すると、キャンバスを取得し、ボタン、テキスト フィールド、ラベル、チェックボックスなど、あらゆる要素をドラッグ アンド ドロップできます。ドラッグアンドドロップします。次に、コードとグラフィック要素 (コンセント) の間に接続が作成され、その要素のオブジェクトを操作できるようになりました。
それだけではありません。NeXT がリリースした 2 つのライブラリと、アプリを構築してそれらのコンポーネントを使用するために必要なすべてのコードを備えた 2 つのライブラリ、および文字列、日付、またはさまざまな種類のデータを操作するための基本ライブラリ(AppKit ライブラリと FoundationKit ライブラリ)ですべてが動作しました。それは開発が永遠に変わった瞬間であり、コンピューティングの歴史におけるもう一つの破壊的な変化を主導したのは再びスティーブ・ジョブズでした。それまではフレームワークも存在していなかったので。
スティーブ ジョブズが 1996 年に Apple に復帰したのは、このテクノロジーのおかげでした。彼が共同設立した会社は、macOS 用アプリの作成に使用される主要ツールをボーランドが購入した後、開発アーキテクチャ (Pascal ベース) を持たないまま放置されていたからです。そしてそこからOS
それ以来、アーキテクチャの点では何も変わっていません。Swift のような新しい言語を使用しても、より多くのことをより速く、より良く実行できるようになりました。ただし、開発アーキテクチャ、つまり要素をキャンバスにドラッグし、コードに接続するアウトレットを作成することでアプリを作成する方法は同じです。その基盤は30年以上変わっていない…今に至る。
UIKit、命令型インターフェイス
これまで使用されてきたアーキテクチャは、今日では命令型インターフェイスの構築として知られているものに基づいています。関数を作成し、それをボタンに関連付けるビルド (たとえば)。アクションを作成します。誰かがボタンに触れると、ボタン上にある行が実行されます。これ以上にシンプルなものはありません。
しかし、命令型インターフェイスには、効率を低下させる問題、つまり「状態」と呼ばれるものがあります。基本的に、コード内にあるこれらの値は、タッチしたときに、タッチした内容に反映される必要があります。ボタンを押すと、ボタン自体である変数 (データ) を受け取ります。たとえば、このボタンが押されたので、色やテキストを変更できます。ボタンである変数のプロパティを変更するとき、インターフェイスは即座に反応して、その色またはテキストを変更する必要があります。その「状態」を変更しています。
インターフェース内の要素に与えることができる値はすべて状態です。アクティブまたは非アクティブにできるフィールドがある場合、true または false になるBool型のプロパティがあります (この 2 つの可能な値のみが含まれます)。 true はアクティブ、false はアクティブではありません。 2 つの州。ただし、フィールドが非表示かどうかを示すBool型の別のプロパティもあります。インターフェースから管理できる状態はすでに 4 つあります。
- 非表示 はい、アクティブ はい
- 非表示 いいえ、アクティブ はい
- 非表示はい、アクティブいいえ
- 非表示のいいえ、アクティブないいえ
どのインターフェイス要素にも、色、テキスト、境界線の色、影、タッチされたかどうかなど、要素ごとに数百以上の可能な状態があります。複雑さは非常に大きく、複雑さが増すほど、システムが要素でいっぱいのインターフェイスを管理することが難しくなります。基本的に、これらの考えられるすべての状態変化とその組み合わせに「注意」して対応する必要があるからです。非効率的でエラーが発生しやすいものです。
インターフェイスをより効率的にするための答えは、HTML などのレイアウト言語が使用され始めた 90 年代に現れました。そこでは、宣言型インターフェイスの完璧な例が得られました。そのまま定義され、ユーザーが操作して別のページに切り替えるまで変更されないインターフェース。しかし、私たちが見る HTML ページ自体は決して変わりません。それは不変です。
SwiftUI、宣言型インターフェイス
明らかに、HTML のような完全に不変の宣言型インターフェイスを使用するのは非現実的です。そこで開発者は、状態と連携する方法を見つけるために作業を開始しましたが、状態に加えられる可能性のある変更は事前に宣言する必要がありました。こうすることで、ユーザーの操作によって状態が変化した場合、インターフェイスは何をすべきかを認識しますが、コードを使用して状態を変更することはありません。私たちはそれを宣言したときに何が起こるべきかを彼にすでに話しました。
さらに明確にしましょう。インターフェイスに何が起こるかを認識していない場合、インターフェイスは、起こり得る変更の何百万もの組み合わせを常に認識しておく必要があります。彼らは、イベントを待っている観察者の集団です。色が変わること、フィールドが移動すること、フォントが変更されること、画像が移動すること…インターフェイスが持つ可能性のあるすべての変更（そのすべて）ステータス) は常にリッスンしており、インターフェイスはそれらを表すように準備されている必要があります。
しかし、宣言型インターフェイスを作成する場合、どのような状態を観察する必要があるか、またその状態が発生したときに何をしなければならないかを (ペイントされる前に) 定義することになります。他はすべて不変であるため、これらにのみ注意する必要があります。また、すべての組み合わせを事前に処理することもできます。したがって、そのユーザー インターフェイスを管理するプロセス コストは限りなく低くなります。なぜなら、インターフェイスを構築するときに、インターフェイスで何ができるのか、何ができないのか、つまりすべてのルールをすでに宣言しているからです。したがって、これらに注意を払い、遵守し、実行する前にそのインターフェイスで可能な組み合わせがいくつあるかを知っておく必要があります。他には何もありません。
現在、Google の Flutter や Facebook の React など、多くのライブラリがすでに宣言型インターフェイスを使用しており、 Apple は SwiftUI を備えた Swift 言語と手を携えて、この開発トレンドの波に乗りました。
SwiftUI のおかげで、インターフェイスを宣言するコードとその結果の間のリアルタイムの対応も確認できます。さまざまなコンポーネントを使用して、このインターフェイスは iPhone、iPad、macOS、watchOS、tvOS 用に自動的に構築および描画されます。恐ろしい制約、つまりインターフェイスがサイズに関係なくあらゆるデバイス上で描画できるようにするために与えられなければならなかったルールに別れを告げます。現在は、HTML を備えたブラウザと同様に、これらすべてがシステムによって自動的に制御されます。
もちろん、必要なものを問題なく描画できる、使用するプロパティが十分にあります。アニメーションも含まれており、インターフェースに関連付けられた動的データ ソース、イベントなど、必要なものはすべて揃っています。
構造の小さな例
Xcode 11 で新しいプロジェクトを作成するとき、最初に表示されるのは、 SwiftUI でプロジェクトを作成するかどうかを示す新しいチェックです。これにより、新しいシーン デリゲート (特に使用される) を持つプロジェクトが作成されます。 、同じアプリの複数のコピーを同時に開くという新しい機能用) ですが、通常のように、インターフェイスの作成を開始する Start Storyboard はありません。
代わりに、コードを含むホーム画面を生成するためにシーンから使用されるContentViewというファイルがあります。技術的な詳細にはあまり触れずに、その動作方法は Swift struct (構造体) に基づいており、これがView型であると説明します。これにより、さまざまなコンストラクター (画面の本体) を返すBody変数が強制的に組み込まれます。
struct ContentView : View {
var body: some View {
Text("Hello World")
}
}
body中にあるのは、テキストを作成して画面の中央に配置するコンストラクターです。それはとても簡単です。テキストを太字にしたい場合は、括弧の後にピリオドを入れて、 bold()関数を呼び出します。
Text("Hello World").bold()
複数の要素を配置したい場合は、積み上げビューなどのグループ化を使用する必要があります。 Vstack使用して Vstack を作成し、その中に必要なものを入れます。
struct ContentView : View {
var body: some View {
VStack {
Text("Hello World").bold()
Image(systemName: "book")
}
}
}
このようにして、テキストを上部に配置し、本を表す新しい San Francisco Symbols 文字セットの画像を垂直方向に積み上げたビューを配置しました。今度はボタンを付けてみます。
struct ContentView : View {
var body: some View {
VStack {
Text("Hello World").bold()
Image(systemName: "book")
Button(action: {
print("Toqué")
}, label: {
Text("Soy un botón")
})
}
}
}
ここでは、ボタンが必要であることを伝え、コード ブロック (またはクロージャ) として 2 つのパラメータを渡します。 actionボタンが押されたときに実行される内容であり、 labelボタンに表示される内容です。テキスト。画像を送信し、その画像からボタンを作成することもできました。
明らかに、これが最も単純で単純です。インターフェイスの構築に関するあらゆる可能性を少しだけ垣間見てみましょう。 macOS Catalina を使用している場合は、コードの横にあるキャンバスを表示し、インターフェースにドラッグ アンド ドロップすることで要素を追加し、見た目を確認し、コンストラクターに変更を加えるとリアルタイムでコードが変更されます。コードを変更すると、インターフェイスが即座に変更されます。
最初の一歩
このテクノロジーは前例のない前進であり、現在、言語とその機能を最大限に活用する Swift のネイティブ ライブラリとして機能し、 Combineと呼ばれる別のリアクティブ プログラミング ライブラリ (非同期イベント用) に結合します。これについては、後で説明します。興味があります。
ただし、現実的になる必要があるので注意してください。インターフェース構築ライブラリをゼロから作成するのは壮大な作業ですが、 Apple はまだスタートしたばかりで、インターフェースを作成する新しい方法を (ほぼゼロから学ばなければならないため) 私たちに使用および学習させてくれています。しかし、現時点では、以前の UIKit 上のレイヤーとして機能しており、インフラストラクチャ レベルでは独立していません。いつもこうなるのだろうか？いいえ、Apple はエンジンを独立させるでしょう。 Swift 言語自体もそのプロセスに従いました。最初のバージョンでは、Swift は異なる方法で Objective-C を記述し、多くの要素とデータ型に変換されました。そして現在、そのアーキテクチャは完全に独立しています。
現在は古い UIKit ライブラリのレイヤーですが、これにより別のより実用的なアプリ作成方法が可能になり、完全に UIKit となり新しいライブラリが作成されるまで、徐々に独自の独立したアーキテクチャになると私たちは確信しています。すべての Apple システムと互換性があります。
2014 年にリリースされた Swift と同様に、私たちは将来を見据えて、Swift を使い始めることができるようになりました。そして私たちはいつものことに戻ります。Apple は何も発明していません。これらすべてはすでに発明されています。しかし、彼らは明確な目的を持って独自のバージョンを作成します。それは、それを最もよく行う人になるということです。今のところ、彼らは正しい軌道に乗っているようだ。