マルチタスクに対応していないiPhoneアプリをそのままの設計でAndroidに移植してしまうと何が起きるのかという話

勉強になったのでメモ。

・マルチタスクに対応していないiPhoneアプリをそのままの設計でAndroidに移植してしまうと、ホームボタン長押しでタスクを切り替える、メニューからアプリのアイコンをタップして起動する、バックボタンで戻りすぎた場合、アプリの起動画面（スプラッシュ画面など）から始まってしまい、マルチタスクを前提としたAndroidでは使いづらい。

（Androidのアプリのライフサイクルを考慮して移植されていないのが原因）

・マルチタスクに対応するiPhone OS 4.0では、マルチタスクに対応したアプリとそうでないアプリが混在することになるが、Androidのように使いづらい状態になるかどうかはわからない。

（iPhone OS 4.0のFirst App Switchingは、アプリをバックグランドに移行する時は単にサスペンドするだけらしい）

 

Androidへ移植されたiPhoneアプリが残念すぎる。（携帯総合研究所）

現在のiPhoneアプリはシングルタスクをベースとして設計されているため、アプリケーションを切り替え後、再度起動した際に切り替えする前の情報が記憶されてないものがほとんどです。

まぁ、そうかも。

Androidのアプリならば画面の状態や情報などすべて記憶されます。

Androidのアプリ側で上記を意識して作る必要があると思います。

iPhone OS 4.0にてこの仕様（Fast app switching）が追加されますが、これはAPIであるため、Fast app switchingを開発者が任意で対応しないと画面の状態や情報は保存されません。（Androidではアプリのライフサイクルとしてサポートしています。この2つのアプリはクロスフォームコンパイラを用いて移植したのかそのままエンコードだけしたのかライフサイクルを守れていないと思います。）

Androidのフレームワークではアプリのライフサイクルを管理する仕組みは提供してくれますが、以下のように状態遷移に応じて適切にアプリ側で処理を行わないといけないはずなので、魔法のように画面の状態や情報が保存されるわけではないかと。（Activityの遷移の履歴をスタックとしてAndroidのフレームワークが管理してくれるのは便利ですよね）

iPhone OS 4.0の「Fast app switching」に対応したアプリでも、Androidと同じようなことをしないといけないはず。

Activity | Android Developers

Androidアプリ作成の基本“Activity”とは何か？ (1/2) – ＠IT

Androidのアプリでバックグラウンドに移行すると処理が止まってしまうので（ここまではiPhone OS 4.0のFast App Switchingと同様？）、バックグラウンドで独自の処理を行いたい場合は、サービスとしてつくらないといけないんですね。

Fast app switchingに対応しているアプリとそうでないアプリが混在するのは結構ストレスになりそうです。UIまで統一しているならここら辺も統一するべきだったんじゃないかなーと今更思ってみたり。

↓こちらの情報を見て初めて知ったのですが、iPhone OS 4.0のFirst App Switchingが導入されても、高速にアプリを切り替えられるだけで、Androidのようにユーザが自由にバックグラウンドで動作するアプリを作れるわけではないんですね。

iPhone OS 4.0 のマルチタスク対応

AppleInsider: iPhone OS 4.0 の内側： マルチタスキング vs Mac OS X、Android – silvervine の定点観測所

AppleInsider: iPhone OS 4.0 の内側： マルチタスキング vs Mac OS X、Android [Page 2] – silvervine の定点観測所

AppleInsider: iPhone OS 4.0 の内側： マルチタスキング vs Mac OS X、Android [Page 3] – silvervine の定点観測所