Cordovaというを知っていますでしょうか?
知っている前提なので、詳しく説明しませんが、ようはHTML(+JS)だけでアプリを作ってしまおう!という話です。

「HTML5はアプリ環境になるべく進んでいる」ところを見ると、その使い方が本命のような錯覚を頂いてしまうかもしれませんが、私は実はあまりおすすめできないと思っています。

その理由としては、明らかに、サーバ側で表示するHTMLソリューションでの開発スタイルと違うからです。
それは、手段が一緒にもかかわらず文化が異なるので、結局、文化であるネイティブの世界を知る必要性が出てくるでしょう。
従って、Cordovaを使っているエンジニアも、ちょっと面倒なアプリになると結局、ネイティブで実装しましょう!という方が多くいるのは事実です。
そういう意味で、いずれネイティブにすべて移行する前提で使うので有り、このHTML5はネイティブアプリに行く前の前段である。
と考えているのであれば、別段問題はありません。

でも、それであれば、仕様や動作にぶれがある、新しい「HTML5」を使うほどの費用対効果は薄い気がします。
アプリエンジニアになる前の「2軍」を目指すために、HTML5だ!はちょっと、気が滅入ります。
そうなのです、UIを中心にアプリをとらえているのであれば、あくまでもHTML5は「2軍」の技術です。
(あきらかに新しい技術ではなく、周回遅れの技術なのです。ただし、仕様は新しいですよ!でも、仕様の新しさと技術の新しさは別ですから・・・)

それよりも、Cordovaは、HTMLにおける「組込みRESTサーバ」である。という位置付けがいいと思っています。

つまり、こんな感じです。

cordova_and_main_plugin

ほぼ、サーバ&クライアントと同じ関係です。
そして、プラグインは、Cordovaの一部という考え方よりも、Cordovaインターフェースを持って、そのエンジンを取り込むというイメージに近いでしょう。
なので、私のCordovaアプリには、必ずメインのプラグインが存在し、そこでデータ処理や、通信、その他機器との接続なども行います。
もちろん、ブラウザから直接ajaxでサーバにアクセスは技術的にはできるわけですが、できるだけそれも行わず、メインプラグインを通じて行います。
そして、その結果だけ、HTML側にJSONとして返すわけです。

なぜ、こうするか。
それは、中央にある「リッチ」(UIではなく、価値がです)なWEBサービスの、「出張所」としてアプリがほしい。からです。
そして、HTML5レベルでは機能拡張はできるだけ行いません。
それは「単なる」ディスプレイという役目のままにします。

そして、できるだけ「リッチ」なWEBサービス側のリソースを生かしたいからです。

これなら、まだ、ネイティブアプリだけで作った方がいいと思うかもしれませんが、
実は、こうする事で、ネイティブアプリでおきがちな、UIと処理が結びついてしまう問題が自然と回避できるようにもなります。

つまり、「UIを動かしたいから処理をしているのか」と「処理が行われたからUIに結果を反映しているのか」が明確に分かれるようになります。
前者は、必ずUIの再描写が必要だが、後者は、そのアプリのその画面を見ている必要なければ「UI」側は無視する必要があるのです。
しかし、処理は確実に必要なのです。

もちろん、ネイティブであっても、気を付けることで十分にこの問題を回避できますが、
Cordovaという、別アーキテクチャーが間に挟まることで、自然とこの2つ事は別なこととしてとらえます。

もし、このようなアーキテクチャーにもご興味があれば、ご相談ください。

お仕事のご依頼・相談を承ります
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら

Leave a Reply

お仕事のご依頼・相談
この記事に関連するお仕事のご依頼やご相談をお待ちしております。 詳しくは、こちら
ソフトウェア&ライブラリ




ライブラリ
airxmail(en)
AIR版メール送受信ライブラリ
airxzip
AIR版ZIP圧縮・解凍ライブラリ
執筆書籍
本、雑誌等

WEB記事:CodeZine
執筆記事はこちら
カレンダー
2015年11月
« 10月   12月 »
 1
2345678
9101112131415
16171819202122
23242526272829
30  

カスタム検索
RSS
Add to Google < !–adsense–>
アーカイブ
カテゴリ
にほんブログ村 IT技術ブログへ