完全にこのタイトルを書きたかっただけです。本記事はXamarin Advent Calendar 17日目のものです。
Xamarin.FormsをUWPで利用する方法はXamarin本家のチュートリアルページに記載されています(参照: https://developer.xamarin.com/guides/cross-platform/xamarin-forms/windows/getting-started/universal/)。
Visual Studio 2015上からXamarinプロジェクトを作成して手順に従います。
Windows 10 IoT Core上でXamarin.Forms利用プロジェクトを最低限動作させるまではとても簡単です。適当にUWPプロジェクトを生やしてXamarin.Formsをパッケージ追加し、メインのXamarinプロジェクト(PCLのもの)への参照も追加し、あとはチュートリアルどおりにいくつか.xamlファイルなどへ変更を加えるだけです。
このスクリーンショットでは少々フォントサイズをいじって見やすく(図3)していますが、ともかく普通に動作します。
このUIはキーボードやマウスを利用して操作できます。もちろんボタンやラベルといったXamarin.Formsが提供する各種UIコンポーネントを利用できますし、データバインディングを活用したプログラミングも可能です。
Windows 10 IoT Coreはその名前のとおりIoTを中心とした組み込み向け(そのなかでも、とりわけ簡易的なユーザインタラクションを伴うのがせいぜいというエリア)のOSです。このため、ユーザとのインタラクションに関する厳密な規定を持ちません。当然、タッチスクリーンインタフェースの存在を前提とすることもできません。
いっぽうでXamarinが得意とするプラットフォームはタッチスクリーンインタフェースを前提とするものたち(iOS/Android/Windows 10 Mobile)です。いくらUWPなアプリがWindows 10 MobileとWindows 10 IoT Coreの間で垣根なく動作するといっても、用途の根幹が違うものを混ぜるのは基本的に悪手です。
Raspberry Pi2 + Windows 10 IoT Coreの用途自体がもう少しタッチスクリーンUIへと寄っていく*1ようなイベントが発生すればXamarin.Formsを活用できる場面が増えそうですが、それまでの間は残念ながら
この場合、用途としては50-80インチ程度のディスプレイとタッチパネルモジュールとの組み合わせを前提とするサイネージで、インタラクションはさほど発生させない前提(メインメニューからの階層をタップでたどっていく程度)がしっくりきます。商業施設内の簡易案内用システムなどで見かけるエリアですね。サイネージから手元スマフォでのアプリ利用へと誘導できるような仕掛けになっていれば一定回りそうではあります。
そこにXamarinを足してそこから一旦GUIでのインタラクションを引いてみようと考えてみます。
ええと、UWP環境には元々C#コードの十分な実行環境が整っています。つまり、Xamarinの中ではメインのx-platコード実行基盤及び大半のBCLの出番がありません。そうなるとXamarinシリーズの中ではFormsコンポーネントやTest Cloudあたりが絡めそうなポイントです。
Test Cloudはさておき、GUIインタラクションを差し引くとFormsコンポーネントを追い出すことになります。結果、Xamarinらしいポイントは一切残らないということになってしまいます。
なんだか悲しいですね。そう思っているうちになんとなく「Xamarin.IoT」というフレーズを思いつきました。なんかかっこいいですね。せっかくなのでXamarin.IoTがどういうものであってほしいかを想像して書いてみることにしました。
その担当するレイヤ境界は従来のXamarinの区切りと少々異なるはずで、「サービスの構築に直結する部分よりも下をごっそり抽象化した各種のcommon APIs」と「必要ならば自らそのサービスプロバイダを書いて拡張できる仕組み」となってほしいところです。
各種のcommon APIsというのは次のような感じでしょうか。
きっとXamarinならこういう絵を描いて未来を見せてくれるはずだ! というわけで、なんというかAdvent Calendarというよりも「初夢Xamarin 2016」みたいな話になりました。
明日の担当はMasaakiYoshidaさんです。
Xamarin.Forms + Windows 10 IoT Coreの可能性
まずはRaspberry Pi2 + Windows 10 IoT Core + Xamarin.Forms でIoT向けのUWPアプリをサクサク書いてみようという話をします。Xamarin.FormsをUWPで利用する方法はXamarin本家のチュートリアルページに記載されています(参照: https://developer.xamarin.com/guides/cross-platform/xamarin-forms/windows/getting-started/universal/)。
Visual Studio 2015上からXamarinプロジェクトを作成して手順に従います。
図1 Xamarin.Forms+UWPのチュートリアル
図2 Xamarin.Forms on RPi2+Win10IoTCore
図3 VS上でXAMLを開いたところ
まあつらいよね
実際にRaspberry Pi 2へWindows 10 IoT Core環境を作ってわざわざVisual Studioからデプロイするまでもなく、Xamarin.FormsをWindows 10 IoT Coreと組み合わせることの厳しさは明らかです。Windows 10 IoT Coreはその名前のとおりIoTを中心とした組み込み向け(そのなかでも、とりわけ簡易的なユーザインタラクションを伴うのがせいぜいというエリア)のOSです。このため、ユーザとのインタラクションに関する厳密な規定を持ちません。当然、タッチスクリーンインタフェースの存在を前提とすることもできません。
いっぽうでXamarinが得意とするプラットフォームはタッチスクリーンインタフェースを前提とするものたち(iOS/Android/Windows 10 Mobile)です。いくらUWPなアプリがWindows 10 MobileとWindows 10 IoT Coreの間で垣根なく動作するといっても、用途の根幹が違うものを混ぜるのは基本的に悪手です。
Raspberry Pi2 + Windows 10 IoT Coreの用途自体がもう少しタッチスクリーンUIへと寄っていく*1ようなイベントが発生すればXamarin.Formsを活用できる場面が増えそうですが、それまでの間は残念ながら
- iOS/Android向けにXamarin.Formsベースで構築した(さほどビューをゴリゴリ作りこんでいない)ものを大画面でのサイネージ表示用へと安価に転用する
この場合、用途としては50-80インチ程度のディスプレイとタッチパネルモジュールとの組み合わせを前提とするサイネージで、インタラクションはさほど発生させない前提(メインメニューからの階層をタップでたどっていく程度)がしっくりきます。商業施設内の簡易案内用システムなどで見かけるエリアですね。サイネージから手元スマフォでのアプリ利用へと誘導できるような仕掛けになっていれば一定回りそうではあります。
[*1] $20程度の安価なタッチパネル付きディスプレイモジュールがデファクト・スタンダードとして普及すればこれはあり得ます。現状の7"ディスプレイ単体で$50近くかかる状況では無理そうですね。
Raspberry Pi 2 + Windows 10 IoT Core + Xamarin - GUIでのインタラクション = ?
Raspberry Pi 2 + Windows 10 IoT Coreはとても良い組み合わせです。ハードウェアの持つ力を十分に発揮しうる組み合わせといえます。そこにXamarinを足してそこから一旦GUIでのインタラクションを引いてみようと考えてみます。
ええと、UWP環境には元々C#コードの十分な実行環境が整っています。つまり、Xamarinの中ではメインのx-platコード実行基盤及び大半のBCLの出番がありません。そうなるとXamarinシリーズの中ではFormsコンポーネントやTest Cloudあたりが絡めそうなポイントです。
Test Cloudはさておき、GUIインタラクションを差し引くとFormsコンポーネントを追い出すことになります。結果、Xamarinらしいポイントは一切残らないということになってしまいます。
なんだか悲しいですね。そう思っているうちになんとなく「Xamarin.IoT」というフレーズを思いつきました。なんかかっこいいですね。せっかくなのでXamarin.IoTがどういうものであってほしいかを想像して書いてみることにしました。
Xamarin.IoTを想像してみる
Xamarinシリーズということは、きっとXamarin.IoTというのは「C#やF#といった言語で開発できてサーバとも連携させやすい、クロスプラットフォーム(x-plat)IoT開発をめっちゃ楽にしてくれるなにものか」でしょう*2。その担当するレイヤ境界は従来のXamarinの区切りと少々異なるはずで、「サービスの構築に直結する部分よりも下をごっそり抽象化した各種のcommon APIs」と「必要ならば自らそのサービスプロバイダを書いて拡張できる仕組み」となってほしいところです。
各種のcommon APIsというのは次のような感じでしょうか。
- BLE足回りのx-plat基盤
- 猫も杓子もBLE時代
- まあ普通に需要ありそう、というかXamarinの追加コンポーネントとして既に売っているところある気がする
- x-platなGPIO基盤
- え、それSystem.IO.Ports.SerialPortじゃダメなの?→どっちかというとGpioClx系では
- シリアルポート抽象化は何かと嬉しい。たとえばそのプロバイダとしてBTなどを透過的に扱える形だと嬉しいのかも
- あるいは、BT/ADK/USB-Hostなどを適宜下回りとして利用できるデジタル信号送受信の仕組み
- え、それSystem.IO.Ports.SerialPortじゃダメなの?→どっちかというとGpioClx系では
きっとXamarinならこういう絵を描いて未来を見せてくれるはずだ! というわけで、なんというかAdvent Calendarというよりも「初夢Xamarin 2016」みたいな話になりました。
[*2] あれ、なんだかWCFの雰囲気を感じますね。気のせいでしょうか。
[*3] ARM Cortex-A9 Quad Core CPU + 1GBメモリなんてリッチに載っていない、Cortex-M0〜M3 CPU + 64 KBメモリ的環境を想定しています。
まとめ
Raspberry Pi 2 + Windows 10 IoT CoreにXamarin.Formsを持ち込んでも(今のところ)個人利用で嬉しいケースは少ないという話と、Xamarin.IoTという語感からその用途やあり方を想像してみると割と面白い気がしたという話でした。明日の担当はMasaakiYoshidaさんです。
0 件のコメント:
コメントを投稿