Microsoft AzureとXamarin.Formsに基づいたMVP(最小限の実行可能な製品)の迅速な作成

友達! Xamarinでのモバイルアプリケーションの開発のトピックに関するブログのコラムを開きます。 また、ビンウェル開発部門の責任者であるVyacheslav Chernikovによる最初の出版物では、クロスプラットフォーム開発の微妙な違いと、Xamarin.FormsおよびAzure Mobile Servicesに基づくMVP(最小実行可能製品)モバイルサービスの迅速な作成について触れています このコラムのすべての記事は、 #xamarincolumnご覧いただけます。


QtからXamarin.Formsへのパス、またはクロスプラットフォーム開発機能



2008年、モバイルアプリケーションの販売から開発に移行することを決定しました。Qtが開始点として選択されました。仕様により、Symbian、Maemo(後のNokia MeeGo)、およびWindows Mobileが対象でした。 利点は、Linuxで直接開発できること、フレームワーク自体の成熟度、ソースコードの可用性でした。 アーキテクチャ、フレームワーク自体とそのコンポーネントのロジック、便利な開発環境であるC ++など、Qtで書くのはいいことでした。 しかし、さまざまなモバイルOSでの起動に関しては、ニュアンスを扱うのに非常に長い時間がかかりました。 Windows Mobileの場合、ライブラリをアセンブルおよび再構築し、Symbian APIを理解し、Maemo / Meegoの依存関係と構成を記述します。







一般に、最終結果は非常に良好でしたが、それでもクロスプラットフォーム開発に参加するためのしきい値は予想よりもはるかに高いと確信していました。















その後、HTML5を選択しました。 結果はそれほど悪くはありませんでしたが、明らかにカスタムアプリケーションを作成するには不十分です。 次に、iOS向けのObjective-CとAndroid向けのJavaの開発に進みました。 結果は優れていましたが、同じ機能を2回実装する必要がありました。







次のステップは、 Xamarin iOSおよびXamarin Androidへの移行と、一般的なビジネスロジックの使用でした。 その後、長い間Xamarinが私たちの主な開発フレームワークになり、やがて作成者が残した落とし穴を回避することに慣れました。 気にする人は、他のフレームワークに対するXamarinのベンチマークテストです: リンク







2014年、Xamarin.Forms(以降XF)が登場しました。 実際のプロジェクトでXFを2年間継続して使用した後、XF 2.0の後、ビジネスアプリケーションの作成で製品が大量に使用されるようになったと自信を持って言えます。 それが、MVPサービスOrder Kingの作成の基礎としてそれを選択した理由です。







2年の使用後のXamarin.Formsの外観



ハブには既にXamarin.Formsに関する有用な記事がありましたので、詳細は説明しません。 つまり、Xamarin.Formsを使用すると、iOS / AndroidおよびWindows(電話、ストア、ユニバーサル)向けのモバイルアプリケーションを作成できます。 これは、古典的なXamarin.iOSおよびXamarin.Androidに基づいており、モバイルアプリケーションの開発時に抽象化のレベルを追加します。













ユーザーインターフェイスは、XAML(推奨)またはC#コード(必要な場合)で説明されています。 そして、バージョンXF 1.xで時々微妙なニュアンスが発生し、努力で排除された場合、2.xではすべてが安定してすぐに動作するようになりました。







XF 2.xと1.xの主な違いは、XAMLをコンパイルする機能です(1.xでは、その場で解析と解釈が行われました)。これにより、インターフェイスが大幅に高速化され、Swift / Javaを使用するときと同じくらい速くなりました。 すぐに「すぐに使える」このような優れた結果を達成することはできず、多くの微妙な点を知る必要があります。これについては、今後の記事で説明します。







Xamarin.Formsを使用しても、ターゲットプラットフォーム(iOS / Android)を勉強する必要はありませんが、逆に、XF <->ターゲットOSのジャンクションには多くの興味深い点があるため、スペシャリストレベルの要件が増加します。 さらに、XFへの移行は、Objective-C / SwiftおよびJavaでアプリケーションを開発した経験が豊富な場合にのみ正しくなります。







私たちの実践から、プロジェクトに応じて、Xamarin.iOS / Xamarin.Androidレベルまで下げて機能の10%を実装する必要が生じ、Objective C / Java-1%-2%(通常、これはサードパーティライブラリの適応と接続です)です。







迅速なAPIサービス開発のためのAzureモバイルサービス



最新のモバイルサービスはサーバーインフラストラクチャなしでは実行できないため、バックエンド(APIサービス)の開発から始めます。 Azureプラットフォームはすべての要件(開発と展開の速度、スケーラビリティ、低メンテナンスコスト)を満たしているため、ここで長い間選択する必要はありませんでした。 不要なコメントなしで、私たちのタスクのためにそれが完全に現れ、多くの既製のモジュールを提供することに注意します。







次の図は、バックエンドサービスの最上位アーキテクチャを示しています。













モバイルアプリケーション用の最新のバックエンドが持つ可能性を考慮すると、データと承認メカニズムの提供に加えて、プッシュ通知の送信、電子メール通知の送信、SMSメッセージの送信(重要な通知とタイムコード/パスワード)も強調表示できます。







Android上のAzure Mobile Servicesにプッシュ通知を簡単かつ簡単に送信する方法は次のとおりです(iOSおよびWindowsと同様)。









var gcmMessage = new GooglePushMessage(new Dictionary {{ "message", "You got a new message"}}, TimeSpan.FromHours(1)); var result = await Services.Push.SendAsync(gcmMessage);
      
      





続きを読む: リンク







そして、これがSendGridを介した電子メール通知の送信です。









 var message = new SendGridMessage(); message.AddTo("Customer <customer@example.com>"); message.From = new MailAddress("no-reply@yourservice.com", "Notification Service"); message.Subject = emailSubject; message.Html = "<b>You got a new message</b>"; message.Text = "You got a new message"; var credentials = new NetworkCredential(SENDGRID_USERNAME, SENDGRID_PASSWORD); var transportWeb = new Web(credentials); await transportWeb.DeliverAsync(message);
      
      





続きを読む: リンク







また、必要に応じて、 Twilioを接続してSMSを送信できます。









 var client = new TwilioRestClient(TWILIO_SID, TWILIO_TOKEN); var result = client.SendMessage("YourSender", "+71234567890", "New message for you");
      
      





続きを読む: リンク







Twilioの代わりに、便利なRESTインターフェースを提供するロシアのSMSプロバイダーを使用できます。また、時には.NET用の既製ライブラリーも使用できます。







バックエンド(MVPに関連)を迅速に展開するには、次のアプローチを使用します。







データクラスの記述(コードファースト)













MobileServiceContextの更新













データと認証を操作するコントローラーを作成します













Azure Mobile Servicesに発行する







データベース構造が自動的に作成され、クライアントが既に接続可能なバックエンドが起動されます。 一般に、必要な機能に応じて、典型的なバックエンドの作成と展開(データ、承認、通知の操作)には数時間から数日かかることがあります。







コンポーネント(SQLデータベース、モバイルサービス、Webサイト、BLOBストレージ)間の相互作用の遅延を最小限に抑えるには、コンシューマとサプライヤを同じデータセンターに配置する必要があります。







モバイルアプリケーションアーキテクチャ



モバイルアプリケーションを開発する場合、バグをキャッチしてシステムを開発する可能性はモジュールとその接続の正しい実装に依存するため、アーキテクチャは重要な役割を果たします。 モジュール間の通信を最小限に抑え、従来のMVVMモデルに準拠しようとします。 ここで使用するアプローチは次のとおりです。













クライアントとサーバーの相互作用を加速します



本日は、XamarinモバイルアプリケーションとAzure Mobile Serivcesクラウドサービスでのデータ転送を高速化する方法についての小さな実用的な調整で記事を締めくくります。







既定では、.NETを使用する場合のAzure Mobile Servicesは、送信データのGZIP圧縮をサポートしません。 有効にするには、 Microsoft.AspNet.WebApi.MessageHandlers.Compressionライブラリを使用できます。







Nugetから入れます













ファイル\ App_Start \ WebApiConfig.csで圧縮を有効にします









  public static class WebApiConfig { public static void Register() { var options = new ConfigOptions(); var config = ServiceConfig.Initialize(new ConfigBuilder(options)); config.MessageHandlers.Insert(0, new ServerCompressionHandler(new GZipCompressor(), new DeflateCompressor())); } }
      
      





サーバーで変更を公開します







クライアント側では、Azure Mobile Services Librariesのデフォルトは標準の.NETクライアントHttpClientです。 もちろん、これはすばらしいソフトウェアモジュールですが、iOSとAndroidの場合は、 NSURLSessionOkHttpのはるかに効果的なソリューションがあります 。 Xamarin.Formsでそれらを使用するには、 ModernHttpClientライブラリを接続する必要があります。





  1. ソリューションのすべてのプロジェクトのNugetからインストールします。
  2. Azure Mobile Servicesのクライアントを作成するときにアクティブ化する


 var _client = new MobileServiceClient(API_BASE_URL, API_KEY, new NativeMessageHandler());
      
      





サーバーはデータを圧縮し、クライアントは高速ライブラリを使用してデータをロードします。







結論



  1. クロスプラットフォームフレームワークを使用するには、高品質のモバイルアプリケーションを作成するために各プラットフォームの十分な知識が必要です。
  2. Azure Mobile Servicesに基づいて、必要なすべての機能を備えた完全なバックエンドを数時間でデプロイできます。
  3. Xamarin.Formsを使用すると、高品質のモバイルアプリケーションを作成して、製品の市場投入までの時間を短縮できます。


これで今日の記事は終わりです。 次の出版物では、Xamarin.Formsの主要な問題領域を回避する方法について説明します。







著者について





ヴャチェスラフ・チェルニコフ -開発部長、 ビンウェル 過去には、Nokia ChampionおよびQt認定スペシャリストの1人であり、現在はXamarinおよびAzureプラットフォームのスペシャリストです。 彼は2005年にモバイル分野に参入し、2008年からモバイルアプリケーションを開発しています。Symbian、Maemo、Meego、Windows Mobileから始め、その後iOS、Android、Windows Phoneに切り替えました。



VyacheslavがDevCon 2016カンファレンスのXamarin ワークショップでエキスパートとして行動し、Apple WatchとGoogle Wearのアプリケーション開発での経験を共有することを発表します。



著者による他の記事:





便利なリンク






All Articles