.NET開発者として基幹業務のタブレットアプリを開発するにはどうすればよいですか？[閉まっている]

私の会社は.NET開発に多くの経験があり、ERPシステムの製品の1つです。最近、顧客から、そのシステムにタブレットインターフェイス、つまり、顧客が製品情報を表示してタブレットで注文を作成できるソフトウェアを提供できるかどうか尋ねられました。

もちろん、Objective-Cの学習、Mac開発ワークステーションの購入、Appleへの料金の支払いなどに多くの時間とお金を投資するという考えにわくわくすることはありません（この1つのプロジェクトのためだけにアプリを販売できるかもしれません）。その後、数人の追加の顧客に提供しますが、ERPシステムの既存の顧客にのみ有用であるため、市場は非常に小さいです。

だから何をすべきか？私の知る限り、次のオプションがあります。

• 「プレーンな古いWindowsアプリケーション」（WPF）を作成し、Samsung SlateやAcer IconiaなどのWindows 7タブレットで実行します。

  欠点：実行時間が短い（「実際の」タブレットと比較して）重くて高価なデバイス。

• Windows 8 ARMベースのタブレットを待ち、Metro（WinRT）アプリを作成します。

  欠点：少なくとも1年は待ちます。Windows 8 ARMがアプリストアを経由せずにカスタムB2Bアプリのインストールをサポートするかどうかは不明です。

• Android用のモノを使用して、Android用の.NETアプリを作成します。

  欠点：さらに別のUIライブラリ（WPFやSilverlightとは異なります）。一部のプロバイダーは、アプリのサイドローディングを許可していません。

これまでのところ、オプション1と3が最も現実的です。明らかな欠点や利点を見逃しましたか？まだ検討していない別のオプションはありますか？あなたは同じような状況にあり、（成功した）1つの特定のオプションを選択しましたか？

jQuery Mobile + Phone Gap Build。

これは基本的には、「HTML5とJavaScriptを使用してアプリをビルドする」と言っていますが、これまでに述べたように重要なひねりを加えています。

NitobiのPhone Gap Buildサービス（現在はAdobeが所有）を使用すると、開発者はHTML5 / JavaScriptアプリを、デバイスにローカルにデプロイできる「ネイティブ」アプリ（実際にはハイブリッドアプリ）に変換できます。基本的に内部で起こっていることは、ネイティブブラウザーを呼び出してfile：// URLからサイトをロードする小さなネイティブバイナリをパッケージ化することであると私は理解しています。

特定のJavaScriptフレームワークをターゲットにする必要はありません。モバイルWebアプリで非常にうまく機能するのと同じHTMLとJavaScriptが正常に機能します。

オフラインサポートも難しくありません。多くのモバイルデバイスでサポートされているローカルブラウザストレージを使用すると、このようにして本当に強力なオフラインアプリを構築できます。アプリがオフラインで適切に機能するように、CDNを使用するのではなく、外部依存関係をローカルにパッケージ化することがベストプラクティスです。

KnockoutJSやBackboneJSのようなフレームワークは、巧みに設計されたJavaScriptアプリをビルドするのに非常に役立ち、Phone Gapのビルドサービスで問題なく機能します。

デバイスがオンラインのとき、ASP.NET / MVC、WebAPI、またはWCFサービスのバックエンドに簡単にアクセスして、データを更新できます。

作成されたアプリは非常に優れており、AppleおよびAndroid市場で配布できます。Phone Gap Buildやその他の同様の製品で構築された市場にはすでに多くのアプリがあり、99％の人々（ほとんどの開発者を含む）は違いを理解できません。

もちろん、この方法でAngry Birdsを構築するつもりはありません（ただし、Canvasでは、試してみるかもしれませんが）。

それを私の言葉にしないでください。PhoneGapはPodCastサーキットでラウンドを行っており、最近はHanselminutes、DotNetRocks、Tablet Showに出演しています。また、私は最近のブログ投稿でそれについて書きました。

製品情報を表示して注文を作成する

HTML 5の機能（および通常は一気に言及される関連テクノロジー）の機能の範囲内にあるもののように聞こえます。リッチなWebアプリケーションを作成すれば、ブラウザーを備えたあらゆるデバイスをすぐにサポートできます。

MVC Webアプリとして開発することをお勧めします。これにより、適切に設計されていれば、デスクトップからスマートフォンまで、ほとんどすべてのデバイスで実行できます。HTML5は機能するかもしれませんが、サポートする必要があるデバイス/ブラウザーの種類によって異なります。あなたがそれを使うことで逃れることができればそれは素晴らしいです。将来的には、その一部をMetroアプリのWCFバックエンドとして適応できるように設計するようにしてください。

既存の.NETの知識を活用したい場合は、SOAアプローチを採用し、できるだけ多くの機能をWebサービス（SOAPまたはREST、より適切な方を選択）に組み込む必要があります。そうすれば、デバイスに小さなクライアントアプリが必要になるだけで、Webサービス機能を呼び出して結果を表示するだけになります。これは、どのクライアントを選択しても、ビジネスロジックを実装する本格的なクライアントよりも開発がはるかに簡単です。

また、後でさまざまなデバイスのサポートを追加することもできます。必要なのは、新しいデバイス用の小さなクライアントアプリだけです。

デバイスを選択するには、2つの基準があります。

1. あなたの現在の顧客が好むものを選んでください（彼らがタブレットアプリを求めた場合、彼らはそれについていくつかの考えを与えているでしょう）
2. 他の顧客にも受け入れられる可能性が最も高いものを選択してください。これはiPadかもしれないし、おそらくKindle Fireかもしれない。

いずれにせよ、まだ市場に出ていないデバイスを待つ必要はありません。オプション2（ARMタブレットのWindows 8）は除外されます。

すべてのWindowsアプリケーションは、MSに関連付けられていることを意味します。また、SilverlightとiOS / IE 10はうまく連動しません。WebサービスやJQueryでHTML 5とJavaScriptを使用してください。Telerik-Kendo UIなどのサードパーティツールを使用すると、GUIがLOBアプリに十分対応できるようになります。Dot Netはサーバー側でのみ価値があります。

その最後のコメントはそれをすべて本当に言います：「ドットネットはサーバー側でのみ価値がある可能性があります」-おそらくMicrosoftはそれを呼び出すべきだったでしょうか？または.WindowsOnly？

.NetでWindows RTクライアント側アプリを作成することもできません。

クロスプラットフォームゲームでプレイするには、.Netで記述されたビジネスロジックとデータサービスがWindowsサーバー上に存在し、Web対応のAPIを公開する必要があることは事実です。最新のASP.Net Web APIは、2013年4月にほぼ産業上の強みを発揮します。これにより、.NetオブジェクトをJSONとして公開できるため、JQuery / JSクライアント側アプリを簡単に統合できます。

クライアント側では、.Netを使用できません。すべてのUIコードをHTML / CSS / JQueryで記述し、データ指向バインディングのKnockoutでJSを使用してロジックを記述する必要があります。

.Net開発者にとって、書き込みを行わずにユーザーインターフェイスを描画するだけで、LOBアプリを開発できます。VS / .Net / WinForms / C＃/ VB.Netと同様に機能するクライアント側の.Netフレームワークを思いついた人は誰でも世界を支配します-そして私は-私の意見ではMonoはどこにもありません（サードパーティのコンポーネントベンダーからのサポートはありません） VS / .Net / WinFormsの近く。