個人的なメモ

Tomohiro Suzuki @hiro128_777 のブログです。Microsoft MVP for Developer Technologies 2017- 本ブログと所属組織の公式見解は関係ございません。

Xamarin iOS + Azure Mobile Apps の利用方法 (4) View の代わりとなるカスタム API の作成 (Easy Tables, Easy API)

今回は、View の代わりとなる API を作成します。

Easy Tables は簡単で素晴らしいんですが、簡便さを追求してるが故、JOIN したクエリの結果セットが欲しいというようなシナリオには対応していません。
さらに、Xamarin対応の Microsoft.WindowsAzure.MobileServices.IMobileServiceSyncTable インターフェースにも Join メソッドが無いため、自前でどうにかする必要があります。

結論として、カスタム API を作成し、その API で JOIN したクエリの結果セットを返すようにしました。

カスタム API では任意のクエリが利用できるので、IMobileServiceTable インターフェースがサポートしていない機能を実装したいときには、カスタム API を作成するのが良さそうです。

まずは Azure ポータルにログインします。

すべてのリソース → あなたが作成したWebApp → すべての設定 → Easy API をクリック。

f:id:hiro128:20160622163147p:plain

Add をクリック

f:id:hiro128:20160622163410p:plain

作成するカスタム API の名前を入力し、OK をクリック。

f:id:hiro128:20160622163430p:plain

作成された API、ExtendedTestItem をクリックし、
Edit Script をクリックします。

f:id:hiro128:20160622163812p:plain

Visual Studio Online で、当該 API の Node.js 編集画面が開きますので、
JOIN したクエリの結果セットを返す、スクリプトを記述します。

※SQLさえ書き換えれば、どんな結果セットでも返せます。

f:id:hiro128:20160622163959p:plain

スクリプトは入力と同時に保存されているので、これで API の作成が完了しました。

次に、API が正しく動作しているか確認するため、API に直接リクエストを投げて確認します。

今回は、Postman という Chrome アプリを使用しました。
アプリのインストールはこちらから

URL に API の URL (http://(アプリのURL)/api/(API名)) を入力、
ヘッダに、zumo-api-version : 2.0.0 と Content-Type : application/json をセットした上、
GETでリクエストします。

f:id:hiro128:20160622164944p:plain

下記のように結果セットを json で取得できれば API 作成成功です。

f:id:hiro128:20160622172132p:plain

これを Xamarin のアプリ側から InvokeApiAsync で叩けばエンティティを取得できます。
(この部分は後ほど詳しく述べます)

今回はここまでです。

Xamarin iOS + Azure Mobile Apps の利用方法 (3) テスト用データの登録 (Easy Tables)

今回は、後に View の代わりとなる API 作成のための準備として、Easy Tables でリレーション用のテーブルを作成し、作成したテーブルにテスト用データを登録します。

まずは Azure ポータルにログインします。

すべてのリソースからあなたの作成したWebAppをクリックします。

f:id:hiro128:20160621170007p:plain

Easy Tables をクリックします。

f:id:hiro128:20160621170106p:plain

リレーション用のテーブル RelatedItem を作成します。

f:id:hiro128:20160621170357p:plain

前回作成したテーブル TestItem とあわせて、テーブルが2つ作成されました。

f:id:hiro128:20160621170446p:plain

RelatedItem にカラムを追加します。

f:id:hiro128:20160621170511p:plain

次に、Easy Tables で作成したテーブルに SQL Server Management Studio から接続できるように、Fierwall の設定をします。

すべてのリソースからあなたの作成した SQL Server をクリックします。

f:id:hiro128:20160621172534p:plain

ファイアウォールをクリックします。

f:id:hiro128:20160621170847p:plain

「クライアントIPの追加」をクリックします。

f:id:hiro128:20160621170935p:plain

自分のIPが追加されたのを確認したら、「保存」をクリックします。

f:id:hiro128:20160621171039p:plain

保存されると下記の表示が出ます。

f:id:hiro128:20160621171109p:plain

次に SQL Server Management Studio を立ち上げます。
SQL Server のサーバ名(xxx.database.windows.net)、ログインアカウント、パスワード(共にEasy Tables 作成時に設定したもの)を入力します。

f:id:hiro128:20160621171543p:plain

データベースに接続できました。

f:id:hiro128:20160621171805p:plain

テスト用データを登録します。

TestItem
f:id:hiro128:20160621171929p:plain]

RelatedItem
f:id:hiro128:20160621171953p:plain

以上でテスト用データが登録されました。

今回はここまでです。

Xamarinを始める前に知っておきたいこと。 Xamarin Native と Xamarin.Forms どちらで開発すべきなのか?

JXUGC #13 東京 緊急開催 Xamarin のすべて!でお話した内容ですが、限られた時間でうまくお伝えできたか不安な部分を再度ご説明したいと思います。

セッションのスライドはここです。

今回は Xamarin Native と Xamarin.Forms どちらで開発すべきなのかを5つの観点から考えていきます。

まずは、下の図をご覧ください。


f:id:hiro128:20160602102352p:plain


1. UI の作りこみが"理論的に"可能か。
「UI の作りこみ」とは、クライアントの要求に応えられるかということです。クライアントは当然の事ながら、「この隙間を1ドット広げて欲しい」「この見出しの文字は1文字目だけ大きくし、色も変えて欲しい」など、プログラムの仕様を考慮しない要求を出します。それに対して「プログラムの仕様上無理です」とは決して言えません。そういう意味で、どのくらい細かくUIデザインをコントロールできるかということです。

Xamarin Native の場合、UI は個別で作成しなければいけませんので、iOS, Android でできることは100%全てできます。そして、難易度的には一番簡単です。
ただし、製品の開発では、Mvvm フレームワークを使用する場合がほとんどです。その場合、ネイティブ UI の機能を100%使用できないこともあります。例えば、Xamarin Native 用の クロスプラットフォーム Mvvm フレームワークである Mvvm Cross を使う場合、ViewModelが iOS, Android 共通となるため、UI の設計が、ViewModel に依存してしまい、100%自由に UI が設計できなくなってしまいます。

Xamarin.Forms の場合、XALM の記述だけでは、上記の「この隙間を1ドット広げて欲しい」といったような細かいクライアントの要望に応えるのは不可能です。よって、Xamarin.Forms で製品レベルのアプリを作成するには、Custom Renderer, Effect, Trigger, Behavior といった機能で、プラットフォームごとの UI や動作を細かくコントロールする事が必須となります。これらの機能を自由自在に利用するには、iOS, Android のネイティブ UI 自体の理解と、Xamarin.Forms がネイティブ UI をどのようにレンダリングしているのかを理解することが必須となりますので、 難易度は Xamarin Native よりも高くなり、どうしても"頑張る"必要があります。


2. UI の作りこみに必要な知識
Xamarin Native の場合、iOS, Android のネイティブ UI の知識が必要です。また、Mvvm Cross などのフレームワークを利用する場合は、フレームワークの知識が必要です。

Xamarin.Forms の場合、iOS, Android のネイティブ UI の知識および、Xamarin.Forms の XAML の文法と Xamarin.Forms がネイティブ UI をどのようにレンダリングしているのかを理解することが必須となり、覚える知識の量は Xamarin Native よりも確実に多くなります。


3. プラットフォーム固有機能の利用
Xamarin Native の場合、ネイティブと同様に可能です。ネイティブの機能をそのまま使うのでトラブル時の解析も容易です。

Xamarin.Forms の場合、Plugins for Xamarin や DependencyService でプラットフォーム固有機能を利用できますが、コードを共有するためのギミックを噛ませてあるので、トラブル時の解析を行なうには、Plugins for Xamarin や DependencyService がどのような仕組みで動いているかを理解することが必須となり、難易度がその分アップします。


4. 実戦での開発工数
基本的に Xamarin.Forms に一番求めるのは工数低減効果だと思います。
これまで述べたことを総合すると、基本的な機能の作成は Xamarin.Forms を利用することでで工数を低減できますが、Xamarin.Forms は製品レベルに仕上げる際の細かい調整で非常に時間を取られてしまうので、アプリの開発全体で見た場合の工数は、Xamarin Native, Xamarin.Forms どちらを利用した場合でも大差ないというのが私の感触です。よって、工数低減効果だけを狙って Xamarin.Forms を利用しても期待したような効果は得られないことが多いと思われます。


5. 技術的投資価値
では、Xamarin.Forms を利用する価値は無いのかというとそうでは無いと思っています。Xamarin Native は結局のところ iOS, Android のネイティブ API のラッパーです。よって、今後、新しい API のサポートは継続されますが、革新的な発展は見込めません。ただし、技術的は枯れているため、非常に安定しています。

Xamarin.Forms は、現在進行形で鋭意進化中です。実際に1年前と比べてもかなりの機能追加が行なわれており、その進化は目覚しいものがあります。今後のバージョンアップまで加味すると明らかに Xamarin.Forms に技術的投資価値があると私は思っています。ただし、進化中のためバグなども時々あったりします。(すぐバージョンアップで解消されますが)


まとめますと、
今、この瞬間にスポットでアプリを開発したいなら、Xamarin Native が最適
今後、Xamarin で継続して開発を行なたいなら Xamarin.Forms が最適

というのが私の見解です。


以上です。


前の記事、「Xamarinを始める前に知っておきたいこと。 Xamarinで何が時短できるのか? ②開発工数を時短!」はこちらです。

Xamarinを始める前に知っておきたいこと。 Xamarinで何が時短できるのか? ②開発工数を時短!

JXUGC #13 東京 緊急開催 Xamarin のすべて!でお話した内容ですが、限られた時間でうまくお伝えできたか不安な部分を再度ご説明したいと思います。

セッションのスライドはここです。

今回は開発工数の時短についてご説明します。

まずは、下の図をご覧ください。

f:id:hiro128:20160516210718p:plain

時短ポイント 1 Visual Studio 上で C# で開発できる

使い慣れた Visual Studio 上で、使い慣れた C# で開発できることが最大のアドバンテージです。
また、ReSarper などのアドインもそのまま使えるものが多いのもポイントです。

もちろん各プラットフォームのAPIの知識が必要なので、WPF や ASP.NET の開発のようにスムーズには行きませんが
C#しか知らない開発者が Xcode + Objective-C で慣れない環境や言語で開発する場合に発生してしまう時間のロスは無くなりますので、
確実にその分は時短できます。


時短ポイント 2 App Logic 部分をワンソースで共通化できる

Xamarin Native, Xamarin Forms どちらの場合でも PCL の App Logic 部分をワンソースで共通化できます。
ロジック部分はプラットフォーム依存度が少ないため、iOS, Android に不慣れなことによる時間のロスも少なく比較的スムーズに開発できます。

初回の開発時の工数はおおよそ半分となる上、改修時の管理も集約できるため、時短効果も非常に大きいです。
また、ロジック部分の単体テスト工数もほぼ半分になります。

各プラットフォーム個別で同じロジックを違う言語で2つ、3つ書くのは非常に手間も掛かる上、
どれだけ努力してもそれぞれのプラットフォームごとで微妙にプログラムの構造が違ってしまうためテストの工数もそれぞれ2倍、3倍以上になってしまいます。
また、改修部分の管理も非常にデリケートとなり、iOSでは簡単だった改修が、Android では非常に手間が掛かってしまうような事態も珍しくありません。
Xamarin を利用すればそのようなリスクをすべて回避できます。この時短効果も非常に大きいと言えるでしょう。


時短ポイント 3 ラムダ式, async/await, LINQ などが使える

PCL は .NET Framework のサブセットであるため、かなりのレベルで .NET の資産が使えます。
例えば、ラムダ式, async/await, LINQ など C#の便利な機能が Windows 開発と同様に使えます。

さらに Azure との連携も簡単で Azure Easy Tables 等が簡単に利用できるため、
ソーシャルゲームのように膨大なトランザクションの処理が必要で AWS が必須なシナリオで無ければ、バックエンドの構築も大幅な工数削減が可能です。

以上が、Xamarin で開発することによる、開発工数の時短ポイントです。
C#の開発者であればかなりの時短効果があることがご理解頂けたのではないでしょうか。

今回はここまでです。


次の記事、「Xamarinを始める前に知っておきたいこと。 Xamarin Native と Xamarin.Forms どちらで開発すべきなのか?」はこちらです。

前の記事、Xamarinを始める前に知っておきたいこと。 Xamarinで何が時短できるのか? ①知識の習得を時短! はこちらです。

Xamarinを始める前に知っておきたいこと。 Xamarinで何が時短できるのか? ①知識の習得を時短!

JXUGC #13 東京 緊急開催 Xamarin のすべて!でお話した内容ですが、限られた時間でうまくお伝えできたか不安な部分を再度ご説明したいと思います。

セッションのスライドはここです。

Xamarin で iOS, Android のアプリを開発しようとするとき、既に、Objective-C, Swift や Java での開発経験があれば時に問題にはなりませんが、Xamarin を使う動機自体が「モバイル開発自体が初めて!」であったり、「Objective-C, Swift や Java はよくわからないけど、モバイルでの開発をやってみたい!」である方も多くいらっしゃると思います。(実際、私自身が Xamarin を始めた理由がまさにそれでした。)

その場合、ネイティブ開発と比べて Xamarin のどこにアドバンテージがあるのかをご説明したいと思います。

最初に明言しますが、C# の経験がある方であれば、Xamarin を使うことで大幅な時短が可能です。

いくつかの観点から時短ができるのですが、最初に知識の習得における時短ポイントをご説明します。

まず、各プラットフォーム個別、Xamarin Native, Xamarin.Forms で必要となる知識をまとめました。

f:id:hiro128:20160509182356p:plain


1. プラットフォーム個別

当然ながら、各プラットフォームのAPI, 言語, 統合開発環境の知識がすべて必要となります。
すでにどれかのプラットフォームの開発を習得済みであれば、有用な選択です。
ですが、これからモバイルを始めるにはあまりに習得に時間がかかりすぎます。


2. Xamarin Native
開発は Visual Studio で行なえるので、Xcode, Android Studio の習得がほぼ不要になります。
現実には多少必要になる部分がありますが、本格的に調べなくても、ちょっとググればどうにかなる程度で済みます。
この「習得」と「ちょっとググればどうにかなる」との違いは「時短」という観点で考えた場合、とてつもなく大きな差です。

各 API の習得は必要ですが、これも、やりたいことをググれば、Objective-C や Java の情報がすぐヒットします。「え、それでは Objective-C や Java の知識は必要なのでは??」と思われるかもしれませんが、そこが Xamarin のすばらしいところです。Xamarin Native の API はすべて Objective-C や Java に「きれいに合わせてあります」つまり、Objective-C や Java の情報をそのまま文法だけ C# に変換すれば、それがXamarin Native のコードになるのです!つまり、ここも「習得」しなくても「ちょっとググればどうにかなる」のです。


3. Xamarin.Forms

Xamarin.Forms では、Xamarin Native のアドバンテージはすべて享受できます。Xamarin.Forms 自体の習得は必要ですが、UI コードの共用化によって、モックアップの作成程度でしたら、各 API の習得が不要になります。ただし、実戦投入するなら、 Xamarin.Forms がどのようにネイティブ UI をレンダリングしているのかを理解することが必須となるため、Xamarin.Forms 自体の習得に加え、各 API の習得が必要となります。


つまり、知識の習得を最小にしたいなら Xamarin Native ということになります。ですが、ここは後ほど詳しくお話しますが、技術に対する投資価値まで考慮すると、Xamarin.Forms の方がアドバンテージがあります。
どちらを選択するかは、チームが開発効率を重視するのか、技術の自体への投資も考慮するのか、といったところで判断するのがよいのではないかと思います。

今回はここまでです。


次の記事、「Xamarinを始める前に知っておきたいこと。 Xamarinで何が時短できるのか? ②開発工数を時短!」はこちらです。