opensocial系のアーキテクチャは、以下の前提を持つ
- トリガーとなる html は、opensocialのコンテナが作成するものであり、基本的に gadget 開発者の制御下にない。
- トリガーとなる html 内で gadget 開発者の制御下にあるのは、gadget 定義 xml の Content 要素内のみで、これが トリガーとなる html の body 内に配置される。
- トリガーとなる html 内に iframe で外部サイトを参照する場合、iframe 内からは opensocial 系機能を一切使えない。つまり、トリガーとなる html 内から直接的な関係にある javascript や flash からのみ opensocial 系機能を使用することができる。
- 外部サーバとの連携には、予め用意された特定の API から以外アクセスすることができない。つまり、独自の RPC 等ラップしないかぎり不可能。
mixi アプリ的制約
iframe等で外部サーバに接続するのは、規約的に許可されない。仮に許可されたとしても、iframe 内からは opensocial系の機能が一切使えない。
PC向けmixiアプリを開発する際の方向性検討
上記のことから、PC向けmixiアプリを作成するのであれば、クライアント側は生の javascript で直接作成か、flash をベースにするのがよさそう。ブラウザのによる動作ブレを考えると、flash のほうがよさそう。javascript が動作する環境であれば、iPhone 以外ならそれなりに動作しそう。品質の視点で考えると、少なくとも向こう1,2年くらいは opensocial 関連で GWT の出る幕はなさそうだし、それ以上たっても可能性は薄いと思われ。
opensocial 系以外の PC 向けサイトを開発する際の方向性検討
特に opensocial 系を意識しないのであれば、GAE/J + GWT で開発するという選択肢がある。インフラの保守コスト低いことや、環境が統一されている点が大きい。safari で動くから iPhone 上でも動作すると思われる。
もうひとつの選択肢として、GAE/J + BlazeDS + flex というのも考えられる。コンテナ側が多少重くなる点とサーバとクライアントの開発環境が密結合していない点は GWT よりも生産性が落ちる要素かもしれない。しかし、クライアント単体の開発速度は flex のほうがかなり高速だと思われる。
今後の方向性
アプリケーションの開発を行う場合、初期にアーキテクチャを決定することがかなり重要である。しかし今回は、どのようなアーキテクチャを採用したとしても、万能なものはできそうにない。技術要素だけではなく、今後の自社の進み方も不明だし、世の中の技術動向で大きく方向が変わってしまう。さてどうしたものか、、、。まぁ、どうせ予想できないんだから、予想できないものは考えないというのが正解だろうなぁ。
確実な点から抑えていくとすると、インフラについては GAE/J と心中することにする。開発の初期メンバ2名でかつフルタイムが1名という現状において、独自インフラの構築や保守の工数は割けない。EC2とか使うと、コストがかかるし、事務手続きだけでもかなり面倒そうだ。
クライアントについては、携帯電話に関しては当面は FlashLite になるだろうから、PC版をGWTで作ろうが Flash で作ろうが影響はない。
opensocial については、GWT よりは flash に軍配が上がりそうな気がする。iPhone に対応しようとしたら GWT のほうがよいかもしれないが、今はそこにこだわるときではなさそうだ。
つまり、flash つかっておけば iPhone 以外には大体対応できるということかな。携帯電話については、フルFlash対応するのが早いか、javascriptに完全対応するのが早いか、よくわからないので、考えても仕方がなさそう。
結論
GAE/J + BLazeDS + Flex で行くことに決定!
直近のTODO
GAE/J + BLazeDS + Flex で mixi アプリをどの程度作れるかは試さないとね。サンシャイン牧場とかあるから大丈夫だとは思いきや、あれって Flex じゃないかも。
0 件のコメント:
コメントを投稿