綺麗にAndroidのUIとビジネスロジックのコードを分離する方法についてなやむ
若干高速化とは話がズレますが、最近趣味でAndroidのアプリを書くことが多いのですが、さくっとコードが汚くなっていくので何故だろうと考えてみた、という話です。
コードの何が汚いのかを説明する前に、状況の説明をしますが
自分はAndroidのコードを以下の3分類に分けて開発しています。
- (1)画面制御用ロジック : Fragment、Activity、Adapter(PagerAdapterなど)
- (2)ビジネスロジック : Service
- (3)データアクセスロジック(DB/SharedPreferenceなど) : Accessor
(1)は基本的にはFragmentに書いています。動的に要素数が変わる処理ならAdapterを作る必要もあります。(2)はServiceという独自クラスを定義して書いています。(3)はAccessorという独自クラスです。
図で説明すると、こんな感じ(字が汚くてｺﾞﾒﾝﾅｻｲ
で、画面制御とビジネスロジックが分けづらい部分が出てくるんですね。
たとえばリストで選択したものをダウンロードして表示する、というロジックを考えたときに
- ダウンロードする対象をリストから選択する
- loading中アイコンを出す
- 非同期でネットワークからダウンロードする
- ダウンロードが成功したらコンテンツを画面に表示する
- ダウンロード失敗したら画面にリトライしてくださいというメッセージとともにエラー表示を出す
3でAsyncTaskを生成してdoInBackgroundでダウンロードサービスを呼び出し、4、5の処理はAsyncTaskのonPostExecuteで処理するということになるのですが、ダウンロードしなかったらエラーを出す、というのも立派なビジネスロジックなので画面の制御用のコードが入ってくるAsyncTaskではなくビジネスロジック側に持たせたいんですね。
それで何とかすっきり書きたいなあ、と悩んでいました。
Webプログラミングで同じようなことに悩んだ記憶が無いのですが、Webの場合は画面制御は全体処理の 最後 に静的なHTMLを吐き出して動的な処理があればJavaScriptにパラメータを渡してあげる、というものでした。最後にレンダリングすればいいので、ビジネスロジックを呼び出してView用のデータオブジェクトを作って、それを最後にテンプレート(VelocityとかSmartyとか)にぶち込む、という感じになります。ビジネスロジックを動かすタイミングとUIに反映させるタイミングが重ならないのでWebプログラミングの場合、両者がくっついてしまうという問題に悩まされることは少ないようです。
Androidの場合、ビジネスロジックの途中にUXの向上のために画面の細かい制御を入れる必要があって、それがビジネスロジックと画面制御ロジックの間を曖昧にしているためコードが汚くなりがちなのではないかと考えました。
同じ問題に悩まされている人いないかなと調べたところ
とか大体似たような悩みのような気がしますね。ただ個人開発にはDDDは大袈裟な気がするので導入は悩みますが
とかも参考になりそう。というわけでこの辺を明日からソースコードを読んでみたいと思います(時間切れ)。
