仕事で Webアプリ（jQueryMobile） を使ってみた感想。

クライアントの要求に応えづらい

これが率直な感想でした。 慣れないせいもあるけど質の高いアプリを作りにはかなり非効率な気がします。

今回のアプリはファイル先読みや独自APIサーバに接続して動的にデータを表示する混合アプリでした。

デメリット

Webクリップのアプリ切り替えの問題

これは アプリを切り替える度にアプリが必ず初期状態になってしまうので、前の状態を保持できない。 これはちょっと深刻といっていいかも知れない。

cookie 使って前の画面に強制的に飛ばす荒業で対処したが、最初の読み込み時間がかかるので凄く不自然。

キャッシュを使って読み込みを早くする方法もあるが、開発的に非効率かつ危険なので使わなかった。

Webクリップからの外部リンク

Webクリップから aタグでリンクすると、強制的に safari が起動してしまいます。 （調べた限り対処方法がわかりませんでした）

iframe で埋め込みも検討しましたが、結局、フレーム内でリンクが発生すると safari へのリンクになってしまうので意味がありません。 やるとしたら、htmlを読み込んで、動的に jQueryMobile に対応したタグにコンバートするくらいでしょうか？

アニメーションの不自然さ

動的にデータ通信するのでローディング使ったりして対処したが、大きな画像を表示する場合は、ちらつきの対処が物凄く大変。

通常の Webアプリの感覚で作るとハマリます

jQueryMobile の画面遷移の切り替えは、HTMLタグだと [xhthml] xxxx javascript だと

$.mobile.changePage('#page_index', 'fade');

になるが、HTMLタグで書いてしまうとクリックした直後に画面遷移が行われる為、コンテンツを読み込んでる処理とブッキングして、不自然な動きになりがちです。

他のJSライブラリが正常に動作しない

これは JavaScript 全般に言えますが、世の中に便利なライブラリが出回ったりしてますが、jQueryMobile を使うと挙動がおかしかったり、動かなくなったりする問題が多々ありました。

結局、カスタマイズや１から作り直しました

jQueryMobile の画面遷移の仕組み上、多分仕方がないような気がします。

Webアプリとネイティブアプリとのギャップ

クライアントはネイティブアプリと比較してしまいがちです。 Webアプリがネイティブに到底勝てるわけもなく、このギャップをクライアントに理解させる時間と労力が大変なのです。

メリット

リアルタイムに更新

Webアプリなので、修正がリアルタイムに更新できるのが一番のメリットでしょう。 今回Webアプリを選択したのも、これが一番の理由かも知れません。

ネイティブが作れない・大変そうと言う安易でWebアプリを選択すると、結構大変な問題が待っているかと思います。

アプリを配布しなくて良い

今回はAppStore 経由でない案件だったので、ネイティブだったら Enterprise ないし AdHoc で配布する必要がありました。

これはクライアントにはちょっと敷居が高い。 Webアプリは URL だけお知らせすれば良いので、クライアントが理解しやすいと思います。

ネットワーク処理を気にしなくて良い

ネイティブで作ると、APIに接続してコンテンツを表示するには結構大変です。 (PhoneGap とか WebView を使う方法もありますが） その点、Webアプリは、HTML ないし JavaScriptの通信さえ抑えれば比較的簡単にコンテンツの表示ができます。

結論

jQueryMobile は、iOS の UI に近づける為のフレームワークですが、実はクライアントは UIのカスタマイズの要求が非常に高いと言うことです。 つまりは、jQueryMobile のようなものは望んでいないのです。

どうしても、HTML5やJavaScriptで作りたいのであれば、その道を相当極める必要があります。 ネイティブ以上に、これができない！あれができない！が発生するからです。

Objective-C がわからないから、Webアプリにするのはとても危険な選択肢

だと思います。