2011年に、Androidで動作するhtmlバージョンから始めました。 彼らは、直面しなければならない困難にもかかわらず、他のプラットフォームに移植する準備をしていました。 しかし、最終的に、2年後、彼らはこのプロジェクトをオフにし、プロジェクトをネイティブアプリケーションに置き換えました。
この記事では、UBANK Alexander Putilinの主要な開発者が 、クロスプラットフォームアプリケーションの作成における私たちの経験について語り、HTML5がまだ必要な理由とそれを打ち負かす方法についていくつかのアイデアを共有します。 実用的な問題に興味がある場合はコメントを歓迎します。
バダのベータ版
アレクサンダープーティリン：
-もちろん、HTMLでは、マルチプラットフォームに魅了されました。 UBANKは、すべての一般的なデバイスに存在するという任務を負っていました。 Webアプリケーションを一度作成してからすべてのプラットフォームに移植する方が、それぞれにネイティブのアプリケーションを作成するよりもはるかに簡単だと思われました。
開発は2011年に始まりました。 Badaプラットフォームから始めることにしました。 サムスンは私たちのスタートアップにとって戦略的なパートナーでした。 これは彼のネイティブプラットフォームであり、韓国人は約200台の電話モデルをリリースしました。 2010-2011年には、ロシアのモバイル市場の約10％を占め、有望であるように見えました。
PhoneGapフレームワークを使用してアプリケーションの作成を開始しました。 タスクは数か月で管理されました。 2011年末までに、このアプリケーションのバージョンはかなり安定したベータ版のレベルに達しました。
しかし、その後、ちょっとしたトラブルが起こりました。サムスンは予想外に、皆のためにバダを崩壊させることにしました。 韓国人はTizenオペレーティングシステムの開発を開始し、将来的にはBadaとの統合を計画しています。 Badaでアプリケーションをリリースすることは、意味がありませんでしたが、準備はできていました。
しかし、私たちはあまり怒っていませんでした。 結局のところ、非ネイティブバージョンを使用すると、アプリケーションを任意のデバイスに簡単に移植できましたよね？ わかった BadaでUBANKをリリースせずに、開発をAndroidに移植することから始めました。
しかし、ここではすべてが思ったよりも複雑であることが判明しました。
Androidとのレスリング
最初の問題は暗号化でした。 当初、フレームワークは、アプリケーション、フォーム、テキスト、データ出力など、一般的に複雑なものを作成することを目的としていません。 また、支払いアプリケーションには暗号化が必要でした。 同時に、java-scriptの数学は率直に弱く動作します。ネイティブコードよりも桁違いに遅くなります。
暗号化を実装し、操作が数分間完了するのをユーザーに待たせないために、htmlインターフェイスと対話するネイティブコードの一部を記述する必要がありました。 したがって、アプリケーションのネイティブコードは約10％でした。 そして、コードの残りの部分が正常に機能した場合、おそらくそれは素晴らしいでしょう。 しかし、違います。
ご存知のように、Androidにはあまりにも多くの修正があり、それらは互いに非常に異なっています。 新しい機能は、新しいバージョンのiOに追加されますが、通常、古い機能は落ちません。 Androidでは、何らかの理由で2.2で正常に動作するものが4で動作しません。
Android 2.2のアニメーションでは、4つは灰色のストライプになっています。 そして、私たちが4つの下で作ったものは、2つ目で愚かにブレーキをかけました。 しかし、まだ3番目のAndroidがあり、どちらも動作しませんでした。
キーボードには多くの問題がありました。 Androidのブラウザでは、彼女は望みどおりに動作しました。フィールドの入り口で閉じ、新しいフィールドに切り替えるときに古いフィールドにとどまることができました。 私はこれと戦わなければなりませんでした-そして再びネイティブコードで。
私はそのような小さな問題を解決するために多くをいじくり回さなければなりませんでした。 さらに、少なくともネイティブ開発に関するドキュメントがあり、ここではすべてを実験的に、つまり科学的な突っ込みの方法で到達する必要がありました。 しかし、実験は非常にうまく終了しました。UBANKの最初のバージョンは、Androidに移植されたHTMLアプリケーションでした。 しかし、このプロジェクトの輝かしい歴史はこれで終わりました。
デスクで働く
もちろん、モバイル決済サービスとしてのUBANKには、すべての主要なスマートフォンに存在するというタスクがありました。 したがって、並行して、iOSおよびWindows Phoneのバージョンを見ました。
ここでは、すでに行われたパスを繰り返しました。 いずれの場合も、ネイティブ暗号化を提供するには、コードの約10％を書き換える必要がありました。 また、移植時に現れるさまざまな欠陥に対処するためにも。
この美しい作品は決して日の目を見ませんでした。 私たちのマーケティング担当者はそれを見て、過度の感情なしにすぐにそれを断ち切りました。 そして、一般的に、彼らは正しいことをしました。
ご存じのとおり、iOSは高度に統合された環境です。 IPhoneユーザーは、すでに標準のデザイン要素に慣れています。 そして、iOS上で適切に見えるようにWebアプリケーションの外観を再設計することは事実上不可能であることが判明しました。 試しましたが。 しかし、それでも何かが正しくないことは明らかでした。 タイル化されたインターフェイスを備えたWindows Phoneについて言うことは何もありません。
また、Simbian向けのアプリケーションのリリースも試みました。その結果、Nokiaが関連しました。 しかし、Simbianはネイティブコードでの暗号化を許可していませんでした。 適切な程度のセキュリティを確保できなかっただけです。
その結果、UBANKの私たちは避けられない決断に至りました。モバイルプラットフォーム向けのHTMLでの深刻なクロスプラットフォーム開発は完全なユートピアです。 アプリケーションに本当に深刻なタスクがある場合、移植は私たちが望むほど簡単で簡単ではありません。 また、各プラットフォームの設計機能では、すべてのデバイスで製品を5つのように見せることはできず、同じインターフェースの外観を持っています。
野戦の戦士だけで
現在、6か月前に展開したサービスはすべて完全にネイティブなアプリケーションです。 これは、HTML5を履歴のダンプに送信する必要があるということですか？
そうは思いません 各ツールにはそれぞれの利点があるように思えます-あなたはそれを正しく使用する必要があります。 私の経験からすると、HTMLはプロトタイプ作成に最適だと思います。 これにより、すべてがどのように機能するかをほぼ瞬時に確認できます。
比較：最初の完全に機能するHTMLバージョンは、2か月で1人でやった。 iOS、Android、およびWindows Phoneのネイティブアプリケーションの開発には、プログラマのチーム全体で約1年の作業が必要でした。
クイックスタートのために、HTMLは良いツールです。 しかし、移植されたアプリケーションは常にネイティブのものよりも悪いため、会社の主要なテクノロジーとしてそれを置くことは価値がありません。
現在HTMLモバイルアプリケーションを開発していて、何らかの問題に直面している場合は、コメントを書いてください。 同じ問題を解決する方法をすでに探していたので、おそらくあなたを助けることができます。 インターネットでは、私はその時、手がかりを見つけることができませんでした-私は自分ですべてに到達しました。 そして今、私はそれらを喜んで共有します。