同様にしてください！
私たちが対処しなければならなかった問題の最も一般的な声明は次のように聞こえます：ここにAndroid / iOS用のクライアントがあり、同じことをします。
これは最も一般的な間違いであり、長期的には開発者に大きな頭痛をもたらし、顧客には予期せぬ費用がかかります。
一般的に、（良い）モバイルアプリケーションの開発は、いくつかの重要なステップで構成されている必要があります。
- 問題の声明;
- プロトタイプ作成。 インタラクションダイアグラムの形式の紙版またはテストデータを使用したスタブアプリケーションのいずれでもかまいません。重要ではありません。 プロトタイプを作成するプロセスで、作業の主なシナリオを実装するための最適なオプションを見つけ、構造的および論理的な問題を見つけ、アプリケーションの使いやすさを議論するプロセス。
- アプリケーションのグラフィックスと設計に取り組みます。
- アプリケーション開発;
- アプリケーションの速度の最適化に取り組みます。
- テスト;
- ストアでアプリケーションを公開する準備。
- アプリケーションを公開する
- 分析の収集とフィードバックの取得。
- 欠陥の修正とアップデートのリリース。
奇妙なことに、開発は重要ですが、重要ではありません。 また、外観も常に重要な要素ではないことを自信を持って言えます。 さらに重要なのは、使いやすさ、ガイドラインへの準拠、および基本的なスクリプトを実行することの利便性です（平均的なアプリケーションは5つ以下でなければなりません）。
主なアドバイス：特定のプラットフォーム用にアプリケーションを設計します。 「ネイティブ」インターフェースを設計するためのリソースの節約は、作成者や顧客にとってマイナスになる可能性があることを理解することが非常に重要です。 あるプラットフォームの標準ソリューションは、別のプラットフォームでは完全に非標準です。
いくつかの例を見てみましょう。 たとえば、Windows Phoneの対応アプリケーション：
これらのスクリーンショットをiOSおよびAndroidのスクリーンショットと比較してみましょう。
スクリーンショットからトップパネルを削除すると、経験の浅いユーザーがアプリケーションの開発プラットフォームを区別できなくなる可能性が高いと思います。
企業のブランド認知度を高めたいという願望は理解できる。 しかし、エンドユーザーにとってアプリケーションの使いやすさは犠牲になりません。 したがって、特定のプラットフォーム用のネイティブアプリケーションをユーザーに提供することをお勧めします。
LinkedInアプリと比較してください：
ブランディングが存在し、どのプラットフォームでアプリケーションが作成されているかがすぐにわかります。
同じことは、「他の人とは違って」それを行う大きな誘惑があるにもかかわらず、標準コントロールを使用する必要性に起因する可能性があります。
たとえば、UC Browserアプリケーションにはかなり興味深いナビゲーションソリューションが含まれていますが、一般的なアプローチには適合しません。 ボタンをクリックしてメニューを開くと、アプリケーションバー内にタブ付きのパネルが表示されます。
（開発者とユーザーの観点から）これが正当化されるかどうかはまだ決定していませんが、それについて考えなければならなかったという事実は、設計を異なる方法で行う必要があることを示唆しています。
Modern UI（Metroインターフェース）について知っておくべき重要なこと
Windows PhoneとWindows 8は、たとえばiOSとは異なり、本物のデジタルプラットフォームです。 これが意味することは、iOS向けの本屋の例で説明するのは簡単です。雑誌や本を読んでいるときの人の行動は、実際の生活から「模倣」されます。 Windows Phoneの場合、このプロセスは「実際の」生活から完全に離婚したように見え、最初は「本棚」のようなものがないデジタルの世界に焦点を当てています。
iOS / Andoidとの2番目の違いは、コンテンツの重視とアクションの重視です。 Windows PhoneおよびWindows 8では、電話番号と電子メールアドレスは小さなフォントで記述され、「呼び出し」または「電子メールの送信」アクションは大きくなります。 大きなフォントとパディングは、Metroのもう1つの機能です。 これは、インターフェイスを設計する際にも考慮する必要があります。
その他のプラットフォーム機能
Windows PhoneおよびWindows 8でアプリケーションを計画する前に、考慮すべきいくつかの側面があります。
1. Androidは、Google、iOSのエコシステム、Apple、Windows Phone、およびWindows 8のエコシステム、つまりMicrosoftのエコシステムに大きく結びついています。 これは、長所と短所の両方になります。 たとえば、オフィスドキュメントで作業する方が簡単ですが、Dropboxと緊密に統合する代わりに、skydriveを使用するように提案されます。
2.プラットフォームの制限。 Windows Phoneはかなり厳しいプラットフォームです。 インターネット接続の種類、バックグラウンド操作の数などに応じて、アプリケーションの起動時間、ダウンロードしたファイルのサイズには明確な制限があります。 このような制限のため、Windows Phone Skypeの「ネイティブ」でさえ、本格的なメッセンジャーの期待どおりに動作するとは限りません。
3. Windows 8のスクリプトの特定の要件。Windows8には、検索、共有などのいわゆる契約があり、「アプリケーションで検索」、「ソーシャルネットワークで何かを共有、または別のファイルを開く」などのスクリプトアプリケーション。」 それとは別に、設定と共有について説明する必要があります-Windows 8では、サイドバーのみに存在する必要があります。 アプリケーション内の機能の重複は非常に望ましくありません。
4. Windows PhoneとWindows 8のナビゲーションモデルは異なります。 Windows Phoneのナビゲーションがほとんど線形である場合（例外的な場合にのみ非線形ナビゲーションが許可され、徹底的にテストされている場合）、Windows 8はナビゲーションモデルにより忠実です。 さらに、どの画面からでもアプリケーションのメイン画面にすばやくアクセスできる可能性について考える必要があります。
5. Windows Phone 7.5と Windows Phone8。WindowsPhoneにはいくつかのメジャーバージョンがあることを覚えておく必要があります。
- マンゴー-Windows Phone 7.5（512 MBのメモリー）;
- Mango-Windows Phone 7.8（512 MBのメモリ）-更新プログラムはまだリリースされていません。
- タンゴ-Windows Phone 7.5（256 MBのメモリ）;
- Apollo-Windows Phone 8。
7.xプラットフォームをサポートすることに決めた場合、アプリケーションが消費するメモリにより敏感なTangoデバイス（予算）をサポートするかどうかを考える必要があります。 NFCまたはアプリ内購入（IAP）が必要な場合は、すぐにWindows Phone 8.0に集中するか、アプリケーションの2つのバージョン（7.xおよび8.x）をサポートする必要があります。
Windows Phone 8とWindows 8の間のクロスプラットフォーム
Windows PhoneがNDKをサポートしているという事実にもかかわらず、C ++でアプリケーションを作成することは完全に不可能です。 コンポーネントを作成し、Direct-Xで作業し、外部ライブラリを接続できますが、ゲーム以外のアプリケーションはC＃/ VB.NETで記述する必要があります（XAMLでの作業はこれらの言語の助けを借りてのみ可能です）。
Windows 8アプリケーションは、C ++で作成することもできます。 Windows 8では、x32、x64、ARMなど、さまざまなアーキテクチャのコンパイルの問題も重要です。 この質問は非常に膨大で、おそらくそれについての記事を別に書くでしょう。
共通のコアを持っているという事実にもかかわらず、Windows PhoneとWindows 8用の100％クロスプラットフォームアプリケーションを作成することは不可能です。 ナビゲーション、UIコンポーネント、カメラの操作、音声SDK、ナビゲーションモデル-これらは異なります。 サードパーティのライブラリも特定のプラットフォーム用にコンパイルする必要があります。そのため、Windows 8ですべての使い慣れたライブラリが利用できるわけではありません。
また、Windows PhoneとWindows 8の違いは、ローカルストレージの操作がWindows 8でわずかに異なることです+ SQL CE（データベースエンジン）がないため、データレイヤーも書き換える必要があり、具体的な実装から抽象化するのが最善ですデータストレージエンジン。
ご清聴ありがとうございました！
PS次の出版物のトピックについて興味深い提案がある場合は、便利な方法でお知らせください。