Titanium Mobileでアプリをどう書くか - マルチコンテキストからクラス設計まで -
Titanium でアプリ開発でなにげに苦労したのが
「この機能をどう書くか」
でなく
「全体としてどう書くか」
のお作法というか設計よりの部分。
自分はけっこういろいろ変わったので時系列にそってまとめておきます。
・目次(時系列順)
1.マルチコンテキスト+include (2011/6~)
2.マルチコンテキスト+include+coffeescript (2011/9~)
3.シングルコンテキスト+require(CommonJs) (2012/2~)
4.シングルコンテキスト+require+coffeescriptでクラスベース設計 (2012/3~)
5.MVCではなくMOVE(Model/Oparation/View/Event/)で (2012/5~)
6.公式に出たAlloyがデフォ？（今後?）
1.マルチコンテキスト+include(2011/6~)
このころ初めて教本片手にtitaniumを触ってみました。
このころ主流だったマルチコンテキストは、ざっくり言うとwindowオブジェクトを作るときにurlプロパティで渡すようにする書き方で、文字通りコンテキスト（一番大きいスコープ）がwindow単位で切り分けられます。
varwindow = Ti.UI.createWindow({ url:"lib/hoge.js"}); window.open();
利点：
・教本もありわかりやすかった
・初学者にシングルコンテキストより理解しやすい（個人的にそう思いました）
デメリット：
・Window間の文字の受け渡しが煩雑
・挙動が不安定
・即時関数を使ってスコープをちゃんと切り分けないとややこしいことになる。
自分はまずはお勉強でさわっていたので気にならなかったですが、やはりちゃんとプロダクトとして出すことを考えるととくに挙動が不安定な点はネックでした。
はwindowを切り替わる際に新しいwindowのファイルを読み込むため、ガタンっともたつく感じがあったり。
あとincludeするというのは、ファイルを切り分けているとはいえ、スコープは大きい一つのファイルに上からダーッと書いてるものと同様なので、include先はそれぞれ即時関数でスコープをちゃんと切ってやる必要があったりして最初手こずった記憶があります。
しかし、プログラミング経験数ヶ月のあのときの自分でも教本見ながら理解できて、iphoneアプリっぽいものがある程度の自由度を持って作れることは魅力的でした。
2.マルチコンテキスト+include+coffeescript
1,2ヶ月してサンプルくらいは作れるようになってさて実際なにかオリジナルなものを作ってみるかといったタイミングで、javascriptを生で書くのではなくcoffeescriptで書いてみることにしました。
ここはいろいろ意見がわかれる点かと思いますが、記述がシンプルになったり、jsにコンパイルするときにいろいろ最適化してくれるというタレコミのもと、とりあえずお勉強だと思って使ってみました。
結果クラスベースっぽくその先で書くことになり、今も愛用しております。
ファイル保存をフックに、coffeeファイルをjsに自動コンパイルするための準備はこちらを参考に。
GuardでTitanium+CoffeeScriptの開発を快適に
coffeescriptってなにが便利って方はこちら:
CoffeeScript で Titanium Mobile すると嬉しいのか?
3.シングルコンテキスト+require(CommonJs)
開いた時間にマイペースで開発を続けること数ヶ月、ある程度アプリが形になってきた！ってタイミングですごい変更が入りました。
マルチコンテキストをシングルコンテキストにしろと言うのです。大枠としてCommonJsにしたがってという方針になったようでその関係でincludeはもう非推奨ですよと。requireでファイルを読み込んでくださいと。
ぐふぅっ・・っとなったのですが、まぁしょうがないか、と切り替えすべてコードを書き換えることに。。
思った以上の大仕事でした。
参考ページ：
CommonJS + シングルコンテキストで実装？？ #titaniumjp
公式ドキュメント:Mobile Best Practices
4.シングルコンテキスト+require+coffeescriptでクラスベース設計
アプリを作っていると、ホーム画面とユーザー画面のUIがほぼ一緒だったり、セルの若干のUIの違いだけであとは同じみたいなリストビューとかがでてくることが増えてきました。
そこでクラスをつくって、基底クラスをしっかりつくって幸せになりたいなと思うところなのですが、jsのプロトタイプベースでやるのはちょっと億劫、、というところでcoffeescriptのクラスを使いました。
coffeeスクリプトのスラスの書き方についてはコチラ：
CoffeeScript入門
プロジェクト途中から入れるのはいろいろめんどくさい作業が発生するので、できれば初期から使うか考えとくのをおすすめします。
5.MVCというよりMOVEで
だいぶ幸せに開発ができるようになってきたのですが、クラスベースにして、再利用性を少し上げても、ある程度の大きさのアプリを書こうとすると、一画面にUI生成, リクエスト、モジュールの読み込み、イベント、ビューの状態の情報などロジックと様々な要素が混在し始めます。
たとえば最近リリースしましたこのTitanium Mobile製アプリ：
シンブルなように見えますが、ユーザーのアクションによって表示要素を変えたり保存したり、カレンダーの日付を保持したり、日付の計算ロジックだったり、他のwindowを開いたりと、裏では思ったより要素が盛り盛りとなっています。
そんなごちゃごちゃのところでバグのリファクタなどしても精神衛生上よろしくないので、このアプリを作る前にちゃんとクラス設計をして書いたほうがよいなと思い、いろいろ思考錯誤していました。
そこで厳密にはMVCではないながら、それっぽい書き方を改良してやっていたら、それはMOVEと言われるものに近いようでしたので、MOVEということにしときます。
原文: MVC is dead, it's time to MOVE on.
翻訳してくれてるところはこちら： http://d.hatena.ne.jp/nowokay/20120704
ざっくり言うと、
MOVE = モデル(M),オペレーション(O),ビュー(V),イベント(E)
という4つの役割を定義し、それにもとづいてクラスを設計していきます。
これにより、記述すべきファイルにコードが分断され、またより疎結合なコードになります。
自分は主に以下のようなフォルダ構成でやっています。EventはEventを定義するだけのファイルで、他はWindow(Scene）ごとにそれぞれ作られます。
.
├── Component(View)
├── Event(Event)
├── Model(Model)
└── Window(Oparation)
このあたりについては次の機会にもうすこし具体的にまとめようと思います。
6.公式に出たAlloyがデフォ？
ちょっと前にbetaで出ていたAppceleratorの公式アプリケーションフレームワークが
ちゃんと正式リリースされたようですね。
5の俺俺フレームワークでひとまず事足りているのであまり触れていないのですが、最終的にはこっちのほうがよいのかな？先人の方に伺いたいところ。
以上TitaniumMobileの書き方振り返りでした。
