ハブに関する1つの記事（ 274635 ）で、オブジェクトをonRestoreInstanceStateせずにonRestoreInstanceStateからonSaveInstanceStateに転送するための奇妙なソリューションが示されました。 android.os.ParcelクラスのwriteStrongBinder(IBInder)メソッドを使用します。

このようなソリューションは、Androidがアプリケーションをアンロードするまで正しく機能します。 そして、彼にはそれを行う権利があります。

...システムは、他のフォアグラウンドまたは可視プロセスのメモリを再利用するために、そのプロセスを安全に終了する場合があります...
（ http://developer.android.com/intl/en/reference/android/app/Activity.html ）

ただし、これはポイントではありません。 （このような再起動後にアプリケーションがその状態を復元する必要がない場合、このソリューションも適しています）。

しかし、そのような「シリアライズ不可能な」オブジェクトが使用される目的は、私には奇妙に思えました。 そこで、アプリケーションの表示状態を更新するために、非同期操作からActivityに呼び出しを転送します。

私はいつも、Smalltalk以来、どんな開発者もこの典型的な設計作業を認識すると思っていました。 しかし、私は間違っていたようです。

挑戦する

• ユーザーからのコマンド（ onClick() ）で、非同期操作を開始します
• 操作が完了したら、 Activity結果を表示します

特徴

• 操作の完了時に表示されるActivityは
  
  • チームが来たのと同じ
  • 同じクラスの別のインスタンス（画面の回転）
  • 別のクラスのインスタンス（ユーザーがアプリケーションで別の画面に切り替えた）
  
  
• 操作が完了すると、アプリケーションの単一のActivtyが表示されないことが判明する場合があります

後者の場合、次回Activity開いたときに結果が表示されます。

解決策

MVC（アクティブモデル付き）およびレイヤー。

詳細なソリューション

記事の残りの部分では、MVCとレイヤーについて説明します。

具体例を挙げて説明します。 アプリケーション「電子キューへの電子チケット」を作成する必要があります。

1. ユーザーは銀行支店に入り、アプリケーションの「チケットを取得」ボタンをクリックします。 アプリケーションはサーバーにリクエストを送信し、チケットを受信します。
2. キューが開くと、アプリケーションは連絡する必要があるウィンドウの番号を表示します。

非同期操作を使用してサーバーからチケットを受け取ります。 また、非同期操作はファイルからチケットを読み取り（再起動後）、ファイルを削除します。

このようなアプリケーションは、単純なコンポーネントから構築できます。 例：

1. チケットが配置されるコンポーネント（ TicketSubsystem ）
2. チケットが表示されるTicketActivityおよび「チケットをTicketActivity 」ボタン
3. チケットのクラス（チケット番号、広告申込情報、ウィンドウ番号）
4. 非同期チケット取得のクラス

最も興味深いのは、これらのコンポーネントがどのように相互作用するかです。

アプリケーションには、 TicketSubsystemコンポーネントを含める必要はありません。 チケットは
静的フィールドTicket.currentTicket 、またはTicket.currentTicketクラスandroid.app.Applicationフィールド。
ただし、その条件は、ロールを実行できるオブジェクトからのチケットである/ないことであることが非常に重要です
MVC -つまり、チケットが表示された（または置き換えられた）ときに通知を生成します。

TicketSubsystemをMVC観点からモデルにすると、 Activityはイベントをサブスクライブし、ロード時にチケット表示を更新できます。 この場合、 ActivityはMVC観点からViewとして機能しView 。

その後、非同期操作「新しいチケットを取得」は、受信したチケットをTicketSubsystem記録するだけで、他のことを心配する必要はありません。

モデル

明らかに、チケットはモデルでなければなりません。 ただし、アプリケーションでは、チケットを空中に「吊るす」ことはできません。 さらに、チケットは最初は存在せず、非同期操作の完了時にのみ表示されます。 このことから、チケットが配置されるアプリケーションには何か他のものがなければならないことがわかります。 それをTicketSubsystemます。 チケット自体も何らかの方法で提示する必要があり、それをTicketクラスにします。 これらのクラスは両方とも、アクティブなモデルの役割を果たすことができる必要があります。

アクティブなモデルを構築する方法

アクティブなモデル-モデルは、変更が発生したというアイデアを通知します。 ウィキペディア

アクティブなモデルを作成するためのjavaのヘルパークラスがいくつかあります。 以下に例を示します。

1. java.beansパッケージのPropertyChangeSupportおよびPropertyChangeListener
2. java.utilパッケージのObservableおよびObserver
3. android.databindingからのBaseObservableおよびObservable.OnPropertyChangedCallback

私は個人的に第三の方法が好きです。 android.databinding.Bindableアノテーションのおかげで、観測フィールドの厳密な命名をサポートします。 しかし、他の方法があり、それらはすべて適切です。

Groovyには素晴らしい注釈groovy.beans.Bindableがあります。 オブジェクトのプロパティを簡単に宣言する機能とともに、非常に簡潔なコードが取得されます（これはjava.beans PropertyChangeSupport依存していjava.beans ）。

 @groovy.beans.Bindable class TicketSubsystem { Ticket ticket } @groovy.beans.Bindable class Ticket { String number int positionInQueue String tellerNumber } 

提出

TicketActivity （プレゼンテーションに関連するほとんどすべてのオブジェクトと同様）は、ユーザーの意志で表示および非表示になります。 アプリケーションは、 Activityが表示され、データが変更されたときにActivityが表示されるときにのみ、データを正しく表示する必要があります。

そのため、 TicketActivity次が必要です。

1. ticketデータを変更するときにUIウィジェットを更新する
2. リスナーが表示されたらチケットに接続します
3. リスナーをTicketSubsytem接続します（ ticketが表示されたときにビューを更新します）

1. UIウィジェットを更新します。

この記事の例では、デモンストレーションのためにjava.beansのPropertyChangeListenerを使用します
詳細。 また、ソースコードでは、記事の下部にあるリンクでandroid.databindingライブラリを使用しますが、
最も簡潔なコードを提供するものとして。

 PropertyChangeListener ticketListener = new PropertyChangeListener() { @Override public void propertyChange(PropertyChangeEvent event) { updateTicketView(); } }; void updateTicketView() { TextView queuePositionView = (TextView) findViewById(R.id.textQueuePosition); queuePositionView.setText(ticket != null ? "" + ticket.getQueuePosition() : ""); ... } 

2.リスナーをチケットに接続する

 PropertyChangeListener ticketSubsystemListener = new PropertyChangeListener() { @Override public void propertyChange(PropertyChangeEvent event) { setTicket(ticketSubsystem.getTicket()); } }; void setTicket(Ticket newTicket) { if(ticket != null) { ticket.removePropertyChangeListener(ticketListener); } ticket = newTicket; if(ticket != null) { ticket.addPropertyChangeListener(ticketListener); } updateTicketView(); } 

チケットを変更すると、 setTicketメソッドは古いチケットからイベントサブスクリプションを削除し、新しいチケットからイベントをサブスクライブします。 setTicket(null)を呼び出すと、 TicketActivity ticketイベントのサブスクTicketActivity解除します。

3.リスナーをTicketSubsystemに接続する

 void setTicketSubsystem(TicketSubsystem newTicketSubsystem) { if(ticketSubsystem != null) { ticketSubsystem.removePropertyChangeListener(ticketSubsystemListener); setTicket(null); } ticketSubsystem = newTicketSubsystem; if(ticketSubsystem != null) { ticketSubsystem.addPropertyChangeListener(ticketSubsystemListener); setTicket(ticketSubsystem.getTicket()); } } @Override protected void onPostCreate(@Nullable Bundle savedInstanceState) { super.onPostCreate(savedInstanceState); setTicketSubsystem(globalTicketSubsystem); } @Override protected void onStop() { super.onStop(); setTicketSubsystem(null); } 

コードは非常に簡単です。 しかし、特別なツールを使用せずに、同じタイプの操作を非常に多く記述する必要があります。 モデル階層内の各要素について、フィールドを作成し、個別のリスナーを作成する必要があります。

非同期操作「チケットを取る」

非同期操作コードも非常に簡単です。 主なアイデアは、非同期操作の完了時に結果をに書き込むことです。 そして、 はからの通知によって更新されます。

 public class GetNewTicket extends AsyncTask<Void, Void, Void> { private int queuePosition; private String ticketNumber; @Override protected Void doInBackground(Void... params) { SystemClock.sleep(TimeUnit.SECONDS.toMillis(2)); Random random = new Random(); queuePosition = random.nextInt(100); ticketNumber = "A" + queuePosition; // TODO     ,    //     . return null; } @Override protected void onPostExecute(Void aVoid) { Ticket ticket = new Ticket(); ticket.setNumber(ticketNumber); ticket.setQueuePosition(queuePosition); globalTicketSubsystem.setTicket(ticket); } } 

ここで、 globalTicketSubsystemリンク（ globalTicketSubsystemも記載されていTicketActivity ）は、アプリケーションでサブシステムをTicketActivity方法によって異なります。

再起動時に状態を復元する

ユーザーが「Take a Ticket」ボタンをクリックし、アプリケーションがサーバーにリクエストを送信し、その時点で着信コールが発生したとします。 ユーザーが呼び出しに応答している間に、サーバーから応答がありましたが、ユーザーはそれについて知りません。 さらに、ユーザーは「ホーム」をクリックして、すべてのメモリを食い尽くすアプリケーションを起動し、システムはアプリケーションをアンロードする必要がありました。

これで、アプリケーションは再起動前に受け取ったチケットを表示するはずです。

この機能を提供するには、チケットをファイルに書き込み、アプリケーションの起動後に読み取ります。

 public class ReadTicketFromFileextends AsyncTask<File, Void, Void> { ... @Override protected Void doInBackground(File... files) { //     number, positionInQueue, tellerNumber } @Override protected void onPostExecute(Void aVoid) { Ticket ticket = new Ticket(); ticket.setNumber(number); ticket.setPositionInQueue(positionInQueue); ticket.setTellerNumber(tellerNumber); globalTicketSubsystem.setTicket(ticket); } } 

レイヤー

このテンプレートは、1つのクラスが他のクラスに依存することを許可するルールを定義しているため、コードのもつれが過剰になりません。 一般に、これはテンプレートのファミリであり、「UMLとデザインパターンのアプリケーション」という本のCraig Larmanのバージョンに焦点を当てています。 ここに図があります 。

基本的な考え方は、下位レベルのクラスは上位レベルのクラスに依存できないということです。 クラスをLayersのレベルに配置すると、次の図のようになります。

レベルの境界を横切るすべての矢印は厳密に下に向けられていることに注意してください！ TicketActivityは、 GetNewTicket下矢印を作成します。 GetNewTicketは、下矢印のTicket作成します。 匿名ticketListenerは、 PropertyChangeListenerインターフェース（下矢印）を実装します。 TicketリスナーにPropertyChangeListener下矢印を通知します。 等

つまり、依存関係（継承、クラスのメンバーの型としての使用、パラメーター型または戻り値の型としての使用、型としてのローカル変数の使用）は、同じレベルまたはそれより低いレベルのクラスにのみ許可されます。

理論の別のドロップ、およびコードに移動します。

レベル割り当て

Domainsレベルのオブジェクトは、アプリケーションが動作するビジネスエンティティを反映します。 これらは、アプリケーションの配置方法とは無関係でなければなりません。 たとえば、 Ticket positionInQueueフィールドが存在するのは、ビジネス要件によるものです（アプリケーションの作成方法ではありません）。

Applicationレベルは、アプリケーションロジックを配置できる場所の境界です（外観の整形を除く）。 有用な作業を行う必要がある場合、コードはここ（または以下）にあるはずです。

外観を使用して何かを行う必要がある場合、これはPresentationレベルのクラスです。 したがって、このクラスには表示コードのみを含めることができ、ロジックは含めることができません。 ロジックについては、 Applicationレベルからクラスにアクセスする必要があります。

特定のレベルのLayersへのクラスの所属は条件付きです。 クラスは、要件を満たしている限り、特定のレベルにあります。 つまり、編集の結果として、クラスは別のレベルに移動したり、任意のレベルに適さなくなったりする可能性があります。

特定のクラスがどのレベルにあるべきかを判断する方法は？ 控えめな発見的方法を共有しますが、一般的には、アクセシブルな理論を勉強することをお勧めします。 ここからでも始めてください 。

発見的

1. アプリケーションがプレゼンテーションレベルを削除すると、すべての機能を実行できるはずです（結果のデモを除く）。 プレゼンテーションレベルのないアプリケーションには、チケットをリクエストするためのコード、チケット自体、およびそれにアクセスするためのコードが含まれています。
2. あるクラスのオブジェクトが何かを表示するか、ユーザーのアクションに応答する場合、その場所はビューレベルにあります。
3. 競合する場合は、クラスをいくつかに分割します。

コード

リポジトリhttps://github.com/SamSoldatenko/habr3には、 android.databindingおよびroboguiceを使用して構築された、ここで説明するアプリケーションが含まれています。 コードを見て、ここで私がどのような選択をし、どのような理由で行ったのかを簡単に説明します。

ありがとう