2014年5月1日木曜日

Resumeとロケール変更について~Unity

Unityで作成したアプリにてResumeとロケール変更操作を併用した場合にちょっと予想外の挙動を確認したのでメモ。

少々ややこしいので順を追って以下に。


■まえおき

※ちょっと用語(?)について。Androidでなんと呼称しているかは厳密に調べてるわけではないので「だいたい」で。

  • 【(アプリの)サスペンド時とは】
    アプリ起動状態から「ホームボタン」を押した後の状態。
    アプリはメモリ中に起動状態のままサスペンド(バックグラウンドへ?)。
    この時、OnApplicationPause(bool pauseStatus) が呼ばれ pauseStatus は true。
     
  • 【(アプリの)リジューム時とは】
    アプリのサスペンド状態から、「戻る」ボタンや当該アプリアイコン押しで再度起動した時。
    メモリ中のアプリが再度フォアグランドに返ってくる。
    この時、OnApplicationPause(bool pauseStatus) が呼ばれ pauseStatus はfalse。
     
  • 【(アプリの)終了時とは】
    アプリ起動状態から「戻る」ボタンを押したとき。
    OnApplicationQuit()が呼ばれる。
     
  • 【言語ロケールとは】
    Android本体の言語設定。日本語とか英語とか。
    Application.systemLanguage.ToString() で現在の設定値を取得できる。
    日本語設定なら"Japanese"、英語系なら"English"が返される。
     

■気になる挙動~Kindle Fire HD8.9

問題が起きるのはKindle Fire HD8.9。
多分FireOSの同バージョンなら同じだと思う。


以下、操作手順

  1. Android本体の言語ロケールを日本語にしておく。
     
  2. アプリを起動する。
     
  3. ホームボタンを押す。
     
  4. アプリはサスペンドしてOSのランチャーに戻る。
    この時、OnApplicationPause()は呼び出される。
    ※OnApplicationQuit() は呼ばれない。
     
  5. Android本体の言語ロケールを英語に変更する。
     
  6. 戻るボタンまたは、アプリアイコンを押す
     
  7. アプリはリジュームしてアプリ画面に戻る。
    OnApplicationPause()は呼び出される。
     
  8. アプリで Application.systemLanguage.ToString() を取得してみる。
    この時、期待する結果は「English」だと思う。
    しかしKindle Fire HD8.9は"Japanese"を返す
     
つまりサスペンド中の言語ロケール変更は検出できていない。

これを踏まえて、さらに次の例へ。

■ME173Xの場合

次に別なAndroid機 ME173Xを使って同様な操作をしてみる。

  1. Android本体の言語ロケールを日本語にしておく。
     
  2. アプリを起動する。
     
  3. ホームボタンを押す。
     
  4. アプリはサスペンドしてOSのランチャーに戻る。
    OnApplicationPause()は呼び出される。
     
  5. Android本体の言語ロケールを英語に変更する。
     
  6. 戻るボタンまたは、アプリアイコンを押す
     
  7. アプリはリジュームしない。(少々予想外)
    OnApplicationPause()は呼ばれない
    OSはアプリを一旦終了させている。(OnApplicationQuit()通過を確認)
    OSはアプリは新規に起動する。(Awake()、Start()を通過する)

     
  8. アプリで Application.systemLanguage.ToString() を取得してみる。
    期待通り「English」を返す。
     
つまり強引(?)な対策なのか仕様なのか、言語ロケール変更時はOS側(?)がアプリを一旦終了させている様子。

なので結果的にアプリから見て言語ロケールの整合性は保たれている。
OnApplicationQuit() はきちんと呼ばれているのでアプリ側としても困ることはない。


■つまり困るんだろうか?


普通は困ることはまず無いとは思う。

ただ(少なくともKidle Fire HD8.9では)既知の現象として把握しておけばデバッグ時に焦らずに済む感じ。

Kindle Fire HD8.9のFire OSは Android4.0.3(Ice Cream Sandwich)ベース。
ME173Xは Android4.2.2で確認。
Fire OS独特の現象なのか、AndroidのVer違いだからなのかは未確認。


正直対策はしたいところではあるけど、回避策が思いつかない・・・ME173Xは大丈夫そうだし。うーん・・・

ME173XではOSがアプリを再起動かけてくるし、ホーム画面のGUIもを全描画し直したりしてる挙動が見て取れるので単純にAndroidのActivityにアクセスして言語を拾うとかできたとしてもダメな予感がする・・・?


あとこの手のOS依存情報は言語ロケールだけなのか?という点。他にも似たものがあるかも?ということも一応は心に留めておく感じ?。


■おまけ


一応、Androidの仕様(?)によると、アプリは起動後ユーザーが明示的に戻るボタンで終了させない場合はメモリ中に待機(サスペンド)している。

ただしホーム押しで待機させている場合、他のアプリ等の影響でメモリ不足となった場合は、待機中のアプリはOS側が勝手に終了しても良いことになっている。

ユーザー操作云々というよりも、イベントとして OnApplicationPause()、OnApplicationQuit()に来るときに適切に処理を書いておけば丸く収まるハズ。

サスペンドでも必ずアプリに帰ってくる保証はないという前提でデザインしておくべきだと思う。


結局今回のKindle Fire HD 8.9の挙動はこれらだけではカバーできない現象なのでしょうがないかな・・・。


0 件のコメント:

コメントを投稿