完成品、非常に貴重な経験、優れたビジネスソリューションを取得して、モバイルアプリケーションの開発を節約する方法

前書き：

この記事では、米国とウクライナのアウトソーシング会社の成功したソリューションの検索の歴史について説明しています。 イベントは架空のものではなく、偶然の一致はランダムではありません。

1.最適なソリューションを検索した方法

過去数年間、モバイルプラットフォーム市場は、開発者と顧客に選択肢を残してきました。単一プラットフォーム用に開発するか、2つの人気のあるプラットフォームに焦点を合わせるか、モバイルデバイス用のすべての人気のあるソリューションをカバーしようとするかです。 そして、もちろん、顧客自身がモバイルプラットフォームの最大の市場シェアをカバーしたいことがよくあります。 ただし、この場合、iOS、Android、Blackberry、およびWindows Phone用のモバイルアプリケーションを少なくとも4つ（！）作成する必要があります。











また、プラットフォームごとに個別のネイティブアプリケーションを作成すると、開発コストが大幅に増加するため、コスト、パフォーマンス、機能の妥協点を見つける必要があります。

• 新しいプラットフォームごとに移植または開発を行うには、コードを書くのに同様の時間が必要です。
• 開発に携わる開発者の数が増えています。
• その結果、開発コストが大幅に増加します。

もちろん、ネイティブアプリケーションを作成する価値がある場合があります。

• 非常に高い生産性が必要です。
• このソリューションでは、クライアント側で大量のデータを処理する必要があります。
• ハードウェアまたはオペレーティングシステムを管理するユーティリティを作成する場合。
• ビデオまたはゲームのシナリオに基づいたソリューションを作成する場合、さらなる現実。

ただし、ハードウェア管理へのカテゴリバインドがない場合、デバイスで大量のデータを処理する必要はありません。その場合、より経済的な開発ソリューションを見つけることができます。



したがって、品質と速度を損なうことなく、すべての一般的なプラットフォームに通常のアプリケーションを実装するために、労働集約的で費用のかからないソリューションを選択するという問題に取り組んでいます。 この問題のカバレッジに関する小規模な調査を以前に行った後、 Mashable.com 、 Forbes.comなどの信頼できる情報源での考えの正確性を確認した出版物がいくつか見つかりました。 予想通り、誰も迅速でシンプルで普遍的なソリューションを提供しませんでした。私たちは分析を行い、複数のネイティブアプリケーションを一度に開発する余裕のない中小企業の代表者の高コストを恐れないソリューションを見つけることにしました。

標準として、ネイティブアプリケーションの最高の特性を採用しました。

• より良いパフォーマンス。
• ネイティブAPIによって開かれたハードウェア設定（カメラ、ローカルデータストレージ、マイク）へのアクセス。
• 開発者の想像力とプラットフォームの能力の間にギャップがないこと。

次の表1は、最適なオプションを決定するために重要な主な要因を示しています。

他の主な人気のあるソリューションの選択に直面しました：

• クリーンなクロスプラットフォームアプリケーション（たとえば、Phone Gapを使用して実装）。
• ハイブリッドクロスプラットフォームソリューション（モバイルサイト+各プラットフォームのラッパー）;
• HTML5携帯電話サイト。

私たちはすでにお客様向けの多様なプロジェクトの開発に直面しており、豊富な経験を積んでいるため、各オプションの長所と短所をすでに知っています。 たとえばPhone Gapを使用して実装された純粋なクロスプラットフォームアプリケーションでは、顧客のニーズに合わせてカスタマイズされた複雑なソリューションを実装する際に深刻なパフォーマンス上の問題がありました。

Phone Gapを使用したこのようなモバイルアプリケーションの開発における問題は、初期の段階ですでに始まっています。

• フレームワークは、最初はクイックスタートのために複雑でした。
• エントリのしきい値が高い（開発者は、設定への基本的な変更の導入に関するドキュメントの調査に多くの時間を費やす必要がありました）。
• 出力でのアプリケーションの生産性が低いことが確認されました。これは、機能自体、つまりソースモジュールの重量が重く、ニーズに合わせてカスタマイズすることが難しいためです。
• システムの既存のエラーにより、開発プロセスが遅くなる可能性があります。
• オペレーティングシステムとハードウェアデバイスへのアクセスは、ネイティブAPIではなく、Phone Gap Framework APIを介して行われました。これにより、パフォーマンスが低下し、場合によってはアプリケーションの機能が制限されました。

スマートフォン向けのクリーンなモバイルサイトでは、問題は少し異なります：統計によると、ユーザーはアプリケーションでの作業に4分の1以上の時間を費やします。たとえば、ユーザーの位置データへのアクセス）。



ネイティブアプリケーションにはグローバルな利点があることにも注意してください。各プラットフォームのネイティブアプリケーションの開発について話すとき、デフォルトではアプリケーションがクライアント側で最大の情報をキャッシュすることを意味します。 Webインターフェイス（WebサイトまたはモバイルWebアプリケーション）に基づくソリューションについて話すとき、多くの場合、開発中にデータキャッシングのレベルに十分な注意を払わないため、パフォーマンスが低下する可能性があります。



また、Webインターフェースに基づくアプリケーションの操作には、いずれの場合でも、インターネットへのアクセスが必要です。 しかし、サーバー側で膨大な量の計算を実行し、既にクライアントに結果を提供しているクライアントサーバーソリューションに基づいてアプリケーションを作成する場合、グローバルネットワークに接続する必要性は、クライアントに毎秒最も関連性の高い情報を提供する必要性と結びつく可能性があります。



すべてのオプションを分析した後、チームは、クロスプラットフォームモバイルアプリケーションを開発する場合によっては、Webサイトとアプリケーションのハイブリッドを使用してネイティブアプリケーションを使用することの実質的にすべての利点を得ることができるという結論に達しました。

• クライアント/サーバーアプリケーションの場合は、いずれにしても、インターネットにアクセスする必要があります（Web APIの呼び出しがあるため）。
• 位置データにアクセスできます。
• アプリケーションは、インストール後すぐに使用可能になります（ネイティブブラウザに移動して、行にアドレスを入力する必要はありません）。

また、クライアントが高速データ転送を提供するプロバイダーを介してデバイスを接続する場合、ネイティブソリューションのパフォーマンスと競合するようなパフォーマンスを得ることが可能になります。 もちろん、クライアントが低いデータ転送速度でネットワークに接続する場合、どのように実装されていても、クライアントサーバーアプリケーションのパフォーマンスは低くなります。

2. Google Closureに到達した方法

モバイルトラフィックのシェアの増加に伴い、Pikaba.com Webサイトでユーザーの利便性のためにモバイルソリューションを実装する必要が生じました。

2012年の初めに、jQuery Mobile Frameworkのクロスプラットフォームモバイルアプリケーションがベースに実装されました。 同時に、カスタマイズされたテンプレート、スタイル、画面間の遷移など、ブラウザーラッパーとサイトのハイブリッドが既に使用されていました。

しかし、すでに実装段階で、このフレームワークは、大量のデータを処理し、多数のカスタマイズされた機能を実装するソリューションには適さないことが明らかになりました。

• jQuery Mobileは構造（DOM）にあまりにも多くの変更を加えました。
• サーバー側で行われたAPIリクエストが多すぎます。
• サーバーとASP.NET Webアプリケーション間のデータ転送により、データの二重シリアル化と逆シリアル化が発生しました。
• サーバー側では、コードの圧縮と最適化は行われませんでした。
• クライアントでは、アプリケーションの問題の主な現れは、画面間の遷移における「思慮深さ」でした。

このすべてが、エンドデバイス上のアプリケーションの速度が望まれることを余儀なくするという事実につながり、各プラットフォーム用のネイティブアプリケーションを記述するよりもコストがかからない、よりエレガントで生産的なソリューションを探す必要がありました。 開発チームは、JavaScriptのSPA Webサイトを発見しました。これは、ブラウザー機能が切り詰められたブラウザーに基づいたアプリケーションに読み込まれるはずでした。

この場合、出力時に次のWebサイトアプリケーションを受け取りました。

• 以前のものよりも比類ないほどコンパクトなDOMがありました。
• クライアントデバイスをロードしないで、サーバー側で計算を実行しました。
• ハッシュタグの変更の追跡とコンテンツの非同期的なロード。
• フルブラウザでロードされた通常のサイトとは異なり、デバイスのソフトウェアとハ​​ードウェアに事実上フルアクセスできました。
• プラットフォームではラッパーのみを記述する必要があったため、開発コストを何倍も削減しました。

最も興味深いのは、JavaScriptを操作するためのフレームワークを選択することです。 最も可能性の高い候補には、 Backbone.JS FrameworkとGoogle Closure Toolsがあります 。 テクノロジースタックの選択については長い間考えることができますが、特定のフレームワークを選択するかどうかは好み、習慣、愛着の問題ですが、Google Closure Toolsを選択しました。 次のパラメータが決定的になりました。

• チームはすでにこのフレームワークを使用した経験があり、これによりアプリケーション開発の生産段階に入るためのしきい値が下がりました。
• Googleには独自のコンパイラがあります。これにより、すべてのコードを最適化して1つのファイルに収集できます。
• Google Closureに基づいてユニットテストを直接作成する機能と、追加のツール（たとえば、同じJasmine ）を使用する必要がないこと。
• 独自のMVC（ モデル–ビュー–コントローラー ）フレームワークを実装する機能。

さらに、GoogleのJavaScriptコンパイラは原則として雑食性であり、任意のフレームワーク（たとえば、同じBackbone.JS）で動作できるという事実にもかかわらず、開発チームは1つの会社の2つの製品のタンデムに集中することに決めました。 Google Closureとコンパイラの組み合わせにより、Good Corporationからの長期的なサポートと、最新のテクノロジーの優先的な実装が約束されました。

3. Pikaba Mobileプロジェクトの実装方法

テクノロジースタックを決定した後、2012年末までに、ユーザーが次のことを行える最小限の機能を備えたクロスプラットフォームハイブリッドモバイルアプリケーションの開発を開始しました。

• ログインしてアカウントを作成します。
• アプリケーションの作成、編集、保存。
• アプリケーション、製品、サービスを表示して検索します。
• プロファイル、グリッドで参照します。

したがって、主なタスクは、顧客に必要なすべての機能を作成することでした。 売り手のための機能は後で実装されることになっていました。



開発者には、Google Closureとの対話用にMVCフレームワークを開発するタスクもありました。 もちろん、 AngularJS 、 EmberJS 、 KnockoutJSなどのフレームワークの存在を誰も忘れていません。このフレームワークでは、MVCモデルが最初に実装され、UIとの対話がより簡単で最小限になります。 しかし、雑多なコンパイラ、サポート、単体テストを作成するためのツールという形のGoogle Closure Toolsの「バン」は、これらの小さな不便に値する費用になりました。



その結果、 TDDが使用されたため、上記の機能は以前のソリューションよりもはるかに高速に記述およびテストされました。

4.マーケティングボーナス

もちろん、すべての顧客の要求に対する普遍的なソリューションはありませんが、私たちのチームは、比較的経済的な効率で、いくつかのプラットフォームのネイティブアプリケーションの実装に代わるものであり、潜在的な開発注文のかなりの部分をカバーするソリューションの1つを見つけましたアプリケーション。



それにもかかわらず、ラッパーを備えたモバイルサイトを使用するハイブリッドソリューションは、すべての利点を備えたモバイルサイトのままです.Googleアナリティクスを接続し、アプリケーション内のユーザーの行動を調査し、オーディエンス、アプリケーションサイト内の移動経路をセグメント化し、多くの分析操作を実行できます。



肯定的なポイントは、Google Play、iTunes、その他の市場でアップデートをリリースする緊急の必要性がないことです。 ユーザーが自分のアプリケーションで、機能不全が解決された、または機能が改善された更新されたバージョンのサイトを受信するには、アプリケーションに再度ログインするだけで十分です。



さらに、これは、新しいプラットフォームを実装するだけで、さまざまなプラットフォームの複数の改善点に噴霧することなく、基本的な機能の改善と新しい機能の追加に集中することで、モバイルプラットフォームの新しいバージョンが登場した場合のサポートを節約するのに役立ちます。







PSコード名Pikaba Mobile 2.0のアプリケーションは、iTunesおよびGoogle Playでの公開のためにすでに準備されており、ラッパーを作成し、Windows PhoneおよびBlackberry OSでアプリケーションをテストする予定です。



PSS同様の機能を備えた開発用の小さなソーシャルコマースプロジェクトが登場した数か月で、得られた経験と既に完成したバンドルを適用することができました。 Pikaba MobileのMVCフレームワークを使用して開発を加速しました。