Mio Project!

はじめに

FlexによるRIAやAIRアプリのプログラム開発案件を複数人で行うとき、小規模なコードの共有だけならまだしも、プロジェクトやライブラリをやり取りすることが増えると、バージョン管理が大変になってきます。
　そこで、Flex案件をチーム開発するときの、Flex Builder Project や Flex Library のやり取り方法についてベターなの方法を探求してみます。

開発案件は、ここでは、モバイル端末についてある加速度センサーから加速度値をもらって各軸の加速度地をリスト表示するコンポネをライブラリを作成して、そのライブラリのコンポネを使って、加速度値をリアルタイムで指数加重移動平均値として表示させるというFlexアプリケーション作成する、というサンプル案件を用意して見ることにしました。

作成したライブラリ

「AcclmtrDisplayLib」について

いきなりですが、まずは、開発結果から。今回のサンプル案件で作成したライブラリを紹介します。

• AcclmtrDisplayLib の ダウンロード (SWC形式)
• AcclmtrDisplayLib APIリファレンス(ドキュメント) の閲覧

この AcclmtrDisplayLib は、加速度センサーの監視と更新制御を行い、加速度値を生の値もしくは指数加重移動平均値に加工した状態で、s:List コンポーネントとしてディスプレイリストに吊るすことができる、Flex Custom Component の AcclmtrDisplayList コンポーネントが含まれるライブラリです。

このライブラリの使い方

次のようなコード（5行目＆7行目）を、MXMLアプリケーションファイル内に挿入することで、自動的に、加速度値をモニタリングしてくれます。

<?xml version="1.0" encoding="utf-8"?>
<s:Application xmlns:fx="http://ns.adobe.com/mxml/2009" 
			   xmlns:s="library://ns.adobe.com/flex/spark" 
			   xmlns:mx="library://ns.adobe.com/flex/mx" 
			   xmlns:mio="net.chsmea.mioproject.lib.acclmtr.components.*">
	 
	<mio:AcclmtrDisplayList interval="500" displayMethod="AcclmtrDisplayMethod.METHOD_EWMA" />
	 
</s:Application>

上のコードを使用した場合は、加速度センサーから500ミリ秒ごとに加速度値を取得し、取得した加速度値から指数加重移動平均値を算出し、その最新の移動平均値をリスト表示します。

AcclmtrDisplayList コンポーネントは、プロパティとして、通常の s:List コンポーネントで持っているプロパティ以外に、interval と displayMethod を指定することができます。
　interval プロパティでは、加速度センサーから取得する加速度値の更新間隔（ミリ秒単位）を設定できます。
　displayMethod プロパティでは、加速度センサーから受け取った加速度値をそのまま表示する（AcclmtrDisplayMethod.METHOD_RAW）か、指数加重移動平均値として表示する（AcclmtrDisplayMethod.METHOD_EWMA）かを、設定できます。

このライブラリを使用しての実行例

このライブラリを挿入したFlexアプリケーションを、モバイルデバイスのFlashエミュレータ（FlashPlayer10.1相当）で実行してみたスクショは、以下のとおりです。

チーム開発するときのやり取りでベターな方法を探す

では、このようなライブラリの開発や、ライブラリを使ったプロジェクトを開発する案件の際、チーム内の開発者間でやり取りする際に、以下にいくつかの方法を紹介する中で、ベターな方法を探求してみたいと思います。

[METHOD_1] FXP, FXPL 形式でメールやファイル共有を通じてやり取りする

まずは、【方法－１】として、原始的な方法を見てみたいと思います。

この方法は、ライブラリを使ったメインアプリの開発中のプロジェクトを、FXP (Flex Builder Project File) 形式で インポート/エクスポート し、そのメインアプリで使用するための開発中のライブラリプロジェクトを、FXPL (Flex Builder Library Project File) 形式で インポート/エクスポート し、それらのファイルを、メールへの添付やファイル共有（FTP, WebDAV, Samba, Dropbox等のオンラインストレージ, etc...）で、やり取りを行う、というものです。

この方法では、チーム内の開発者でやり取りを行うたびに、プロジェクトのインポート/エクスポート作業が必要になる上に、書き出されたプロジェクト（FXP, FXPL）ファイルの、比較がとても困難になります。
　誰がどの部分を変更したのか、最新のコードはどれなのか、などが、とても追跡・管理しにくくなってしまいます。
　ただ、かなりの小規模なプロジェクトの場合やチーム内の開発者数が2名くらいの場合は、この方法で十分かもしれません。

ですがやっぱり、今日び、チーム開発の際は、バージョン管理はしっかりしたいところ。次は、バージョン管理システムとして、SVN (Apache Subversion) を利用した、プロジェクト・ライブラリプロジェクトのやり取りの方法について見てみます。

[METHOD_2] プロジェクトの数だけ管理プロジェクトを作ってSVNリポジトリを通じてやり取りする

次に、【方法－２】として、バージョン管理システムの SVN を使った、方法を見てみたいと思います。

この方法は、ライブラリを使ったメインアプリの開発中のプロジェクトを、MainApplicationプロジェクトとして、そのメインアプリで使用するための開発中のライブラリプロジェクトを、Libraryプロジェクトとして、SVNリポジトリ上にそれぞれサブプロジェクトディレクトリを用意して、アップデートとコミットを繰り返して、チーム開発を行うというものです。

この方法では、開発する案件のプロジェクト規模が大きくなるに従って、多数のライブラリやモジュールを保守管理しなければならなくなり、しかも参照するすべてのライブラリやモジュールの入ったプロジェクトを開発者・保守作業者が取得しないと、コードの記述・保守作業などができない、という問題があります。
　メインアプリケーションを少し書き換えたいという開発者が、自分の保守していないライブラリプロジェクトのソースまで取得しないと、Eclipseのプロジェクトの設定ファイルの制約により、ライブラリの参照リンクが果たされなくなってしまい、コンパイルが通らなくなります（下図参照）。
　
　そこで無理やりその開発者がライブラリのバイナルファイルだけを落として、参照ライブラリのリンク情報をメインアプリのプロジェクトのプロパティーに独自に設定してしまいますと、ローカルのパスを指定してしまい、最新のライブラリのバイナリを使用できないばかりか、せっかくのバージョン管理システムを使ったプロジェクトの共有時に、プロジェクトの情報の整合性が取れなくなってしまい、チーム内の開発者間で、プロジェクトファイルがバラバラになってしまいます。
　その問題を解決するために、手動では、ライブラリプロジェクトのメイン開発者・保守者は、自分の保守しているライブラリのバイナリを更新した際に、メインアプリのプロジェクトのbinディレクトリ以下にそのライブラリの最新バイナリファイルを配置してコミットする、という方法があります。
　そうすれば、コンパイルが通るようになり、プロジェクトの情報の整合性も担保されますが、この方法は、コミットするごとに手動での作業量が増えて、すっごく面倒です。
　つまり、ちょっとメインアプリのプロジェクトの一部分だけを書き換えたいと管理者にも、全くもって煩わしいことですが、参照するすべてのライブラリプロジェクトも落としてもらって絶えず保守してもらうほうが、ライブラリのコミッターの作業量が減ります（下図参照）。
　
　ただ、この【方法－２】では、チーム内で誰かが必ず苦や面倒を感じる羽目になってしまうので、もう少しいい方法を採用する必要があります。

[METHOD_3] メインプロジェクトから参照するライブラリはSVN外部定義してプロジェクトをSVNリポジトリを通じてやり取りする

次に、【方法－３】として、バージョン管理システムの SVN と、その外部定義を使った、方法を見てみたいと思います。

この方法は、ライブラリを使ったメインアプリの開発中のプロジェクトを、MainApplicationプロジェクトとして、そのメインアプリで使用するための開発中のライブラリプロジェクトを、Libraryプロジェクトとして、SVNリポジトリ上にそれぞれサブプロジェクトディレクトリを用意し、更にライブラリを使用しているメインアプリの開発中のプロジェクトの内のlibディレクトリ内に、SVNの外部定義（svn:externals）属性を設定して、参照するライブラリのバイナリファイルへのシンボリックリンクを設置し、チーム開発を行うというものです。

SVN1.5以降の環境で、SVNの外部定義を設定するには、次のコマンドを打ち込めば、OKです（※SVN1.4以前とSVN1.5以降とでは、引数の順番が逆になっているので注意）。

(main-app-flex-project/dir/path)/$ svn propset svn:externals "(../symbolic-link-path/to/flex-library-project/)/bin/(library-name).swc (library-name).swc" bin

この方法では、開発者自身が保守・管理できる範囲のメインプロジェクト・ライブラリプロジェクトのみをバージョン管理システムのアップデートとコミット作業を通じて追いかけていけばいいだけという環境を作り出せるので、かなり効率的にチーム開発ができるようになりますし、それぞれの管理者の保持しているコードやプロジェクト単位でバグ箇所の切り分けができるので、バグのトラッキングも大変行い易くなります。

メインアプリケーションの開発中のプロジェクトの一部分のみを書き換えたいという開発者がいても、そのメインプロジェクトのみをSVNチェックアウトしてさえもらえれば、そのメインプロジェクトで参照しているライブラリの最新のバイナリファイルが自動的にlibsディレクトリ以下に展開される（下図参照）ので、開発中のプロジェクトのやり取り時に、大規模なものであったとしても、ライブラリやモジュールの参照まわりで煩わしさを一切感じなくなります。
　

まとめ

バージョン管理システムの外部定義機能、ほんと便利ですなー。