Xamarin Dev days 2 xamarin.forms ja

Editor's Notes

• #2: それでは、第二部を始めさせていただきます。
• #3: リコージャパンの中村と申します。 よろしくお願いいたします。
• #4: さて第二部はXamarin.Formsについてお話しさせていただきます。 というわけで、すこし皆さんにお聞きしたいことがあります。 Xamarin.Forms、今日初めて聞いたという方 いらっしゃったら、もしよかったら挙手をお願いします。
• #5: Xamarin.Formsとは、端的に言うとXamarin上で動作する クロスプラットフォーム対応のUIフレームワークです。 従来のアプローチでは バックエンドのコードが共有可能でした。 しかし、UIはプラットフォーム別に実装する必要がありました。 これに対し、Xamarin.Formsを使用した場合 UIのコードも大部分が共有可能となります。 ところでこの図、一部おかしな点があります。 気がついた方はいらっしゃいますでしょうか？
• #6: おかしいのはここです。 なんでバックエンドのコードが減ってるの？って話です。 この資料 Xamarinのヘッドクォーターから送られてきた資料なんですが あっちのひとは大雑把で困ります
• #7: というわけで直しときました。 これできっと夜もぐっすりです。 我ながらいい仕事をしたと思います。
• #8: さて、Xamarin.Formsはクロスプラットフォームの UIフレームワークだとお話ししました。 Xamarin.Formsは次のものを皆さんに提供します。 ・40以上のPage、Layout、コントロール ・双方向のデータバインディング ・共通化された画面遷移インターフェース ・アニメーションAPI ・Dependency Service ・Messaging Center などなど、です。
• #9: もう少し詳しく見てみましょう。 Xamarin.FormsではMasterDetailやTabといった画面構成を定義するPageや そのPage内にコントロールを、どう配置するか といった、レイアウトが複数提供されています。
• #10: そしてこれらのレイアウト上に、自由に配置可能な多数のコントロールが提供されています。 もちろんユーザー定義のコントロールを作成することも可能です。 Xamarin.Formsのアプローチのユニークな点は これらのコントロールのすべてが、実行時にはネイティブコントロールとして動作するという点にあります。 例えば、Xamarin.FormsではテキストボックスはEntryコントロールとして提供されています。 しかし、実際の動作時には、iOSではUITextFieldに、AndroidではEditTextにといった形でネイティブのコントロールとして動作します。 Formsを利用しない場合も同様ですが、Xamarinの特徴は一貫して、ネイティブの見た目・ネイティブの使用感・ネイティブの実装が徹底されている点にあります。
• #11: またすでにXamarin.Formsには多数の有償コンポーネントも提供されています。 日本人の大好きなデータグリッドやチャートなど 非常に優れたコンポーネントも多数ありますので、ぜひ一度目を通してみることをお勧めします。
• #12: さて、Xamarin.Formsでは多数のコントロールが提供されています。 そしてその中には、同じくXAMLアーキテクチャを採用しているWPFやUWPと類似するコントロールもあります。 ただ、部分的に名称が同じだったり異なったりしますので、注意が必要です。 このあたり、どういったコントロールが存在するのかは、Xamarin公式ページに網羅されているので そちらを参照するといいと思います。
• #13: また、FormsはXAMLベースアーキテクチャであって、双方向バインドに対応しています。 しかし、バインドの記述やサポートしているレベルがWPFなどとは異なります。 例えば、WPFのDataContextは、 Xamarin.FormsではBindingContextという名前で存在しますし ここには書かれていませんが、EventTriggerに対応するActionが バインディングに対応していなかったり 細かい点が異なります。 WPFやUWPでXAMLに慣れている方こそ戸惑う面もありますので ご注意ください。
• #14: では実際のソースと各プラットフォームでの表示の対比を見ていただきましょう。 この例では、TabbedPageの中にStackLayoutを配置して、上から二つのテキストボックスと一つのボタンを配置しています。 一番わかりやすい違いは、タブの表示です。 同一のソースコードでありながら、タブの配置が、iOSでは下部に それ以外は上部に表示されています。 各プラットフォームのネイティブの表現が忠実に再現してされているのが見て取れるかと思います。 たまにネット上で、同じソースで同一の画面にしたいの、X amarinにしてしまうと表示が異なってしまう という意見を見かけることがあります。しかしそれは誤った解釈です。 Xamarinはあくまでネイティブのコントロールで、そのプラットフォームにとって一番自然なUIを提供する、ことに重きを置いています。 もちろん、カスタマイズして完全に共通化を図ること自体は可能です。
• #15: さて、ここからは、共通化できない この部分 の話をしたいと思います。
• #16: 共通化できない部分の多くは次のいずれかです。 Formsで共通化されていないUIコントロール デバイスやセンサーといったプラットフォーム固有部分
• #17: 先ほど多数のコントロールが 提供されていると、述べました。 しかし、Xamarin.Formsで提供されている物は 各プラットフォームの最大公約数的なコントロールに限られます。 また、存在するコントロールであっても 扱えるプロパティや振る舞いに制限があるケースも存在します。 もっと狭いだろって突っ込みを受信した気もしますけど 文句があるならPR送ればいいのです。 This is OpenSource! って誰かさんならいいそうです。 そして、XamarinのContributingドキュメントみて、莫大なプラットフォームで 正しく動くコードを書くことの困難さに打ちひしがれてみるといいと思います。 なんだかんだいって、Xamarinのバランス感覚は神がかってると私は思っています。
• #18: そういった場合に有効なのが、カスタムレンダラーです。 Formsにない、ネイティブのコントロールを利用したいといった場合や Formsで制御できない範囲をコントロールしたい といった場合に利用できます。 こちらは公式のドキュメントです。 赤枠で囲った範囲を見てください。 Entryというコントロールレベルのものから ListViewやMap、Pageといった大き目のコントロール。 そしてViewそのものも実装可能です。
• #19: そもそも標準で存在するボタンなども、実は同じ仕組みで実装されています。 公式コンポーネントと同等もしくはそれ以上のコントロールを 実装可能な手段は誰にでも提供されています。 またFormsのソースコードはGithub上に公開されていますので ぜひこの辺りのコードは参考にしていただけたらと思います。
• #20: もう一つ、Dependency Serviceです。 これは、位置情報・加速度・カメラといったセンサーや デバイス固有の機能を利用するための仕組みです。 Xamarin.Formsは最初に説明した通り、基本的にはUIフレームワークの側面が強いです。 このため、センサーやデバイスの制御について 統一した利用方法はほぼ提供されていません。 そこで、Dependency Serviceを利用することでこういった部分の実装を 解決することが可能になります。 この図はTextToSpeechという、テキストを音声として読み上げる機能を Dependency Serviceで実現するケースのモデルです。 まず、共通コードにインターフェースを定義します。 その上で、各プラットフォーム側に実装クラスを作成します。 これらの実装クラスを実行時にプラットフォームに合わせて 適切なものを、自動的に適用してくれるのがDependency Serviceです。
• #21: Forms単独で解決できない問題は、 カスタムレンダラーとDependency Serviceで 多くが解決されますので、ぜひ覚えておいてください。 それではここで実際にデモを見ていただきましょう。 [ここまで10分程度]
• #24: ハードウェアはMacBook Proでメモリ16Gの人権のあるPCです。 その上のOS Xの上の仮想環境でWindows 10が動作し、Visual Studioで開発しています。 ビルドはハードウェア的にはローカルのMac上のMac Agentを通してOS X側でビルドし 実行時はiOS Simulator for Windows越しにOS X上のiOS Simulatorでデバッグ実行します。 iOS simulator for Windowsはただのリモートクライアントで実態はOS X上にあるわけです。 そしてWindows 10上にはHyper-Vが動いているのでAndroidもWin10mも動かせると 一見完璧なんですが、ドヤ顔するためだけの環境です。
• #25: で実はあんまりよろしくない点があります。 というのは、Hyper-Vを動かすために 仮想マシンの通常はOFFになっている CPU仮想化支援をONにせざるを得ず 結果的に仮想マシン上のWindows10全体がもっさりになるという。。。 いまいちな感じになります。
• #26: なので実用上は、モバイル & Visual Studio & iOSで開発したい場合は Hype-Vはさっくり諦めてAndroidとWindows10mobileは実機を利用するのが ベストだと思います。
• #27: さて、ここからは比較的新しく追加された機能を紹介していきたいと思います。 Formsは現在も、活発に開発が継続されていて、頻繁にバージョンアップが行われています。 スライドに記載している2.0というバージョンは、去年の年末か、今年の初頭にリリースされたと記憶しています。 そして、現時点では2.3.1がリリースされています。 この間にリリースされた機能をピックアップしてご紹介します。
• #28: バージョンアップでは、新しい機能の追加とあわせてパフォーマンスの向上も図られています。
• #29: 例えば、リストビューの仮想化機能です。 リストビューのアイテムを仮想化し、再利用することで スクロールパフォーマンスが大幅に向上しました。 ただし、現在の標準の設定では仮想化は無効になっています。 リストビューを利用する場合、まずは仮想化を有効にすることをお勧めします。
• #30: またコンパイル時にXAMLをプリコンパイルする XAMLCというものが追加されました
• #31: これはアプリケーションの起動の高速化やアプリサイズの縮小に貢献します。 さらに、ビルド時にXAMLのエラーを検知できるようになるため 可能な状況であれば利用した方が好ましいでしょう ただし、コンパイルの時間が長くなる点と、一部の状況ではうまく機能しないケースもあるようなので注意が必要です。
• #32: さて、もちろんパフォーマンスの改善だけではありません。 デザイン性やコントロールなどにも大幅な機能の追加が行われています。
• #33: Formsの2.1ではCotent Template という機能が追加されました。 WPFのユーザコントロールに類する機能です。 右側に表示されているコード側をごらんください。 コード上ではLoginViewというコントロール一つのみが配置されています。 しかし左の実際の画面上では、二つのテキストボックスと、一つのボタンが表示されており 複合コントロールが実装されていることが、見て取れます。
• #34: また同時期に、Data Template Selectorもリリースされています。 これは条件によってDataTemplateを切り替える仕組みです。 ちょっと見にくいかもしれませんが生年月日が1980年以前の人は 赤く表示するテンプレートに切り替え それ以外は緑に表示するテンプレートに切り替える という、大変すばらしいくて、大きなお世話なサンプルです。 もうちょっといい例が絶対にあったと思います。
• #35: そしてカルーセルビューも提供されました。 これまでスワイプでのコンテンツの切り替えは 全画面切り替えるカルーセルページのみが提供されていました。 カルーセルビューを利用することで、ご覧のように画面の一部を切り替えることが可能となっています。
• #36: そしてEffectsです。 Xamarin.Formsでは、これまでもカスタムレンダラーを利用することで ネイティブで実現可能な、あらゆるUIを実装することができました。 しかしカスタムレンダラーはテキストボックス、ボタンといった、 対象とするインターフェース単位で実装する必要があります。 このため、もともとXamarin.Formsで提供されるコントロールをほんのちょっとカスタムしたい といった場合には、カスタムレンダラーは大げさすぎる手段でした。 そこでEffectsの出番です。 例えば、コントロールに影を付けたい といった場合に、個別にコントロールを実装するのではなく 影を提供するEffectsを作り、コントロールに添付することで 既存のコントロールをカスタマイズすることが可能です。
• #37: これが実装サンプルです。 Effectsとカスタムレンダラーを比較した場合、実現可能性という意味では カスタムレンダラーの方が自由度が高くなります。 それに対してEffectsのストロングポイントは 既存のコントロールに対して、カスタマイズしたい要素を再利用して適用できる という点があげられます。 先ほどの影を付けるカスタマイズを考えてみましょう。 カスタムレンダラーで実装した場合、影付きのテキストボックス、影付きのボタン のように個別に実装する必要があります。 これに対してEffectsであれば、影をつけるEffectsを一つ作ることで 異なるコントロールに共通して適用できる点が大きなメリットです。 ただし、実現できる幅はカスタムレンダラーと比較すると低くなります。
• #38: まだまだあります。
• #39: 来ました！我らが待望のXAML　Previewerです! MacのXamarin.Studio向けにはしばらく前から提供されていました。 そして、つい先日、ついにVisual Studioにも提供が開始されました。 Xamarinの神である、ミゲル氏は6月8日に行われた.NET ConfのKeynoteで Visual Studioにも来週くらいにはリリースするよって言ってたのに つい最近、やっと！やっと！VSにもやってきました。 これまでFormsの開発者はXAMLを脳内でビジュアライズするエアXAMLという 特殊能力の習得が求められてきました。 しかし、プレビューワーの登場で、皆さんは、その修行から解放されます。 解放される可能性があります。解放されることもあるかもしれません。 ただし、ポトペタデザイナーではなく、あくまでプレビューワーであることに注意が必要です。 WPFでもUWPでも、どうせ慣れたらXAMLなんて手書きじゃん？いらなくね？ という判断があったのか、無かったのか、少なくとも今のところデザイナー開発の噂は聞いたことがありません。 ちょっと残念ですね。
• #40: そしてURL Navigationも提供されました。 これはアプリケーション外からURLスキームでディープリンクを提供する機能です。 NSUserActivityやGoogle App Indexingを実現する手段。。。らしいです。 使ったことないのでちょっとよくわかりません。ごめんなさい。
• #41: そして、Xamarin.Forms最大の謎技術、DataPagesです。 サーバーサイドに置かれたJSONファイルをダウンロードし、 一覧画面と選択後の詳細画面がなぜか自動生成されるという神秘にあふれた技術です。 ただし、神秘にあふれすぎていて、現状開発が進んでいるかどうかも謎に包まれています。 Formsはオープンソースなのですが、DataPagesのソースは公開もされていない？ようです。本当？ 一説によると、Xamarinイベントで視聴者の受けを取るためだけに作られたのではないかと 全私のなかでささやかれています。
• #42: そしてテーマです。 これを利用することで、DarkやLightといったテーマが適用された アプリケーションを簡単に作ることができます。 と、ぴーさんログに書いてありました。 ただこれもプレビューのまま半年間、進展が見られません。 どうやらDataPagesの黒魔術の基礎をなしているとの噂です。 いや事実ですけどね。
• #43: そしてネイティブ　エンベディングです。 これは画面の中に、特定のプラットフォームの場合だけ、そのプラットフォームのネイティブコントロールを埋め込むという技術です。
• #44: 例えばAndroidではFloating Action Buttonがよくつかわれたりしますが、iOSでは利用されません。 こういった、共通の画面中に 特定のプラットフォームでの動作時にだけ、ネイティブコントロールを埋め込む といった形で利用することができます。 ちなみに現在のステーブル版のFormsではXAMLからは利用できない制約があります。
• #45: しかし、プレビュー版の2.3.3では、同様のことがXAML上で利用可能になります。 しかもバインディングに対応した形で！です。 すばらしい！んですが、XAMLCを使ったプリコンパイルに 現在非対応です。 しかも、仕組み上将来的にも難しいかもしれません。 ということで扱いどころが難しい機能になる可能性があります。 さて、ここまで駆け足で詰め込んできてしまいましたが、おそらくお分かりいただけた通り Formsは現在進行形で発展中の技術です。 そして、ネイティブユーザインターフェースをワンソースで構築しようという、奥深い試みでもあります。 この後のハンズオンでは実際に皆さんにも触れていただきますので、ぜひFormsの一端を体験していっていただけたらと思います。
• #46: しかし、プレビュー版の2.3.3では、同様のことがXAML上で利用可能になります。 しかもバインディングに対応した形で！です。 すばらしい！んですが、XAMLCを使ったプリコンパイルに 現在非対応です。 しかも、仕組み上将来的にも難しいかもしれません。 ということで扱いどころが難しい機能になる可能性があります。 さて、ここまで駆け足で詰め込んできてしまいましたが、おそらくお分かりいただけた通り Formsは現在進行形で発展中の技術です。 そして、ネイティブユーザインターフェースをワンソースで構築しようという、奥深い試みでもあります。 この後のハンズオンでは実際に皆さんにも触れていただきますので、ぜひFormsの一端を体験していっていただけたらと思います。
• #47: というわけで、本セッションは終了となります。 ご清聴ありがとうございました。 あと、ブログ見てください。ツイッターフォローしてください。 よろしくお願いします。 以上です。