【Android】アプリのページ遷移に Intentは使うな。と思う今日このごろ(トーンダウン)


 

Intentの仕組み。特に暗黙的なしくみについては、良い設計だと思いますが

プロセス管理の仕組みとして、
Activity単位が、 いわゆるプロセス単位に近い状態になっているため、
ページ遷移を Intentですると色々大変です。

対応策として

flipper や  Visibility.GONEを使って消したりする仕組みが良いです。

ページ遷移に対応するボタンか、TextViewを使って
表示の ON/OFFを制御します。 include単位で LineaLayoutなどで囲い階層構造にすれば、
その一個のIDの制御で表示が簡単に切り替えできます。

レイアウトは includeを使えば、 ビジュアルエディターも使え、使い回しやコピーも容易です。

スマニューなども、それっぽいです。

メリット

変数管理、生存管理、変数の受け渡し等が簡単で自然になる。

共通ロジックを、共通ロジックとして 用意する部分が楽になる。
値の保存、DBの連携、通信、 UIスレッド、 スレッド、  アクションバー、Toast、文字列処理などもろもろ

Activity単位だと  ユーザの設定保存のタイミングや、いつの間にかバンされている対応など
結構することが多いですが、一つにしてしまえば、表示されているので破壊されません。

数行の似たようなコードを書かなくて済む。
(微妙に変数とか変えないといけないときもあるし)

デメリット

デメリットとその対策

起動時間がちょっと遅い →スレッドで対応
レイアウトが直接いじれない→ include を xmlの中に書いて別だし
バックボタン対応→ オーバーライドで、特別に管理する。
                       (デフォに従った方が良いが、デフォに従っていないアプリも多い)
アプリの巨大化→クラスを分割
表示(ページとか)とボタンの関係性をコーディングする必要がある。

まとめ


似たようなページや、処理が大きくかぶるなら、まとめて表示内容だけ変えるほうが楽。

ページを独立させたい時は、多少のコードが被っても、
ひとつのAcitivityにする必要もないです。

設計の全体像レベルの構成のほうが、分担するときにも重要です。

コラム補足

Intentも当初の設計書の思いから、だいぶずれて、
あとで、2,3つめの設定ができ
筋がなんだかわからなくなってますよね。

 

Delicious にシェア
Digg にシェア
reddit にシェア
LinkedIn にシェア
LINEで送る
email this
Pocket




コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です