スマートフォンの登場以来、既存の Web アプリケーションをモバイル プラットフォームに移植するという問題が定期的に発生しています。ここでの移植とは、技術的手段を使用して既存のアプリケーションを変換し、スマートフォンまたは別のモバイル プラットフォームでアクセスできるようにすることを意味します。
持ち運びには、容易さ、スピード、そしてコストが伴います。特に私たちが現在経験しているこの危機の時期においては、非常に多くの重要な要素があります。さらに、可視性を求める競争により、企業はできるだけ早くモバイル サービスを開発し、できるだけ早く市場を占有するようになります。したがって、Portage は非常に魅力的なソリューションです。
スマホとPCは関係ないんですが…
このソリューションは魅力的ですが、スマートフォンは PC とは何の関係もないという重大な制限に直面します。いくつかの違いは明らかです。画面サイズと解像度は、モバイルに対応していないアプリケーションのユーザーに永続的なスクロールを強います。
もう一つの明らかな違いはキーボードです。物理的であろうと仮想的であろうと、それらは使用するのが難しいため、その使用は可能な限り減らす必要があります。
顕著な違いをそのままにしておくと、ネットワーク容量は、帯域幅の点でも信頼性の点でも、比較できるものではありません。モバイル インターネット経由で不適切なサイトを閲覧してがっかりしたことのない人はいるでしょうか?現在のサイトには、モバイル ユーザーにとって満足のいかない重い画像や Flash アニメーションが満載されています。一般に利用可能な帯域幅を考慮すると、Google ホームページの名残である英雄的な時代にほぼ戻るはずです。
ネットワークの信頼性はさらに重要な影響を及ぼします。回線が切断されると、大多数のサイトが機能しなくなります。たとえ 3G カバレッジが現在満足のいくものであっても、白い領域が残ります。ここでも、適切に設計されたモバイル アプリケーションでは、この不測の事態を考慮する必要があります。
あまり明らかではない違いとしては、ネットワークを集中的に使用するアプリケーションによって生成されるエネルギーの過剰な消費を挙げることができます。
要するに、違いは数多くあります...そして、これらの基本的な技術的な違いを超えて、構造的な違いも考慮する必要があります。それは、ユーザーがモビリティ状況にあるということです。大画面、本物のキーボード、強力なネットワークを備えた PC で快適に使用できるのと同じサービスを、なぜ彼に提供したり、さらには押し付けたりするのでしょうか?
ユーザーのモビリティ状況を考慮して、フィルタリングされた関連情報をユーザーに提示することが不可欠です。たとえば、地理位置情報を使用して、近くにある情報のみを表示します。
同様に、CRM アプリケーションは、デフォルトでは、その日の予定に含まれる顧客に関連する情報のみを提供し、スマートフォンでは読み取れない過負荷の表示を避ける必要があります。
したがって、アプリケーションの人間工学をスマートフォンに適応させる必要があります…
私たちのスマートフォンには、従来のカメラはもちろんのこと、音声合成、音声認識、モーション検出器など、移動中の使用を容易にする高度なセンサーが搭載されることが増えています。 PCには存在しない周辺機器がたくさんあります。なぜアプリケーション インターフェイスのこうした新しい可能性を奪う必要があるのでしょうか?新しいモバイル サービスは、少なくとも競合他社と同等以上の快適さをユーザーに提供する必要があります。
したがって、移植は非難されるのでしょうか？実際、前述のすべての要素が特定のアプリケーションに有利であると主張する場合、追加の要素、つまりモバイル プラットフォームの断片化を考慮する必要があります。歴史的なプレーヤー (Windows Mobile、Symbian、RIM) と新規参入者 (Apple、Android) の間で戦いが激化しています。この状況では、特定のアプリケーションを選択したサービス プロバイダーが、それをさまざまなターゲット プラットフォームで書き直す必要があります。
これには明らかに法外なコストがかかります。書き換えには直接的なコストに加えて、各プラットフォームに専門のチームを配置し、書き換えに必要な時間を待つことに同意する必要があります。
プラットフォームの断片化により、各ターゲットでの書き換えが困難になる
このため、アプリケーションを複数のターゲット プラットフォームに移植できるようにするための独自のツールが多数登場しました。
Mac 対 Windows、Unix 対 Windows など、何年も前から存在するこの問題は私たちもよく知っています。この問題が、プラットフォームから自分自身を抽象化しようとした何世代もの L4G を生み出したり、1 つのプラットフォームの API を提供するクロスライブラリを生み出したりしました。別の API (Wime など)、またはすべてのターゲット プラットフォーム (Qt など) に共通の新しい API にも対応します。
Java が「一度書けば、どこでも実行できる!」という有名なスローガンで解決しようとしているのも、これと同じ問題です。 » 経験上、これらすべてのアプローチには限界があることがわかっており、Java のスローガンは「一度書けば、どこでもデバッグできる!」とパロディ化されることがよくあります。 »
HTML 5: 解決策は?
しかし、代替手段として HTML 5 が登場しています。HTML 5 は、ユーザーと基盤となるプラットフォームの間のインターフェイスとしてブラウザを提供するため、単一の標準化されたプラットフォーム上でアプリケーションを開発できるようになります。
明らかに、この魅力的なアプローチ自体には限界があります。たとえば、特定の周辺機器の制御を可能にする新しいインターフェイスの検討と標準化です。
この有望なアプローチは、モバイル プラットフォームを含む Web 2.0 開発を合理化するこの道を信じているように見える Google や Apple のような企業によって支持されています。
このアプローチは、人間工学とモバイル アプリケーションの操作の特殊性に関して以前に表明された留保事項を条件として、既存の Web 2.0 アプリケーションのモバイル プラットフォームへの移行を容易にし、逆に、モバイル プラットフォーム用に開発された「固定 Web」アプリケーションを見つけることを可能にします。携帯電話。 Web 2.0 の約束に従って、ユーザーの場所や使用するデバイスに関係なく、ユーザー エクスペリエンスは同一または少なくとも類似したものになります。
Chiyoye