サウンド系API事情05 Android系API

前回はLinuxのサウンドAPIについて説明したが、今回はAndroidのサウンドAPIに関して説明する。
Androidはアプリケーションの実装言語がJavaであるため、またちょっとかわったソフトウェア構成になる。今回はその構造から説明したい。

サウンド系API事情01 前知識

近年では、様々なプラットフォームでアプリケーションが作成される。
これがプラットフォームごとにそれぞれ異なるAPIで実装されているのだから、マルチプラットフォームのアプリ開発環境が隆盛するのも当然といえる。
ただ、マルチで開発していると何を使用しているかを意識することがなく、それぞれに抱える問題などが正確に把握できない、という問題もまた開発者にはあることだろう。
この記事では、いくつかのプラットフォームを例にとって、サウンド系APIについて説明したい。

Service

Androidでは、よくあるViewが表示されるアプリとは別に、Serviceというバックグラウンド処理を行うクラスを実装することができる。
Serviceはバックグラウンド処理を行うのに都合がいい機能が幾つか実装されている。

前置き

1. Activityがバックグラウンドに移動しても、Serviceは動き続ける。
2. Activityが終了した場合でも動き続けるような設定ができる。（正確には、Activity終了時にServiceを立ち上げ直しているもよう）
3. Serviceの立ち上げ方は２種類あり、それによって挙動やライフサイクル、Activityとの通信方法などが異なる。
4. ServiceはActivityなどと別のプロセスではない。
5. Serviceは多重起動はできない。

４に関しては、Activityと同じスコープで実装・ビルドしている以上、そうなのかなと思ったが、
よく考えたら、Activityが落ちた後もずっと動いてるし、その後またActivityが立ち上がったらどうなるの...？と思った。

Serviceはライフサイクルが特殊なので、いろいろテストをして確認した結果も踏まえて、使用方法をまとめた。

Android Backup Service

詳しい話はここに書いてあるけど英語だし。。。
なので、実装した上での経験も含めてまとめた。

前置き

Android Backup ServiceはAndroid2.2から実装された、Androidアプリのデータバックアップの仕組み。
BackupManagerというクラスを通して、バックアップを行う。
主な特徴は下記の通り。

1. バックアップ内容は、保存したい内容をbyte列にしてwriteする方法と、ファイルやSharedPreferencesを指定する方法がある。
2. ファイルに関しては、基本的にはContext.getFilesDir()のパス内に保存されているデータを指定できる。（それ以外にもできるという記事がよそにありますが）
3. バックアップのタイミングは指定できない。（OSが定期的にバックアップを行う）
   できるのは対象データが変更されたのを通知することのみ。
4. リストアもタイミングを指定できないとあるが、実際に実装してみたらアプリ側でリクエストしたらすぐに処理が始まるっぽい。
5. 画像やテキストデータでもバックアップ可能。データ容量制限は記載がない。
6. 最終的にバックアップを行うかどうかはユーザがAndroid端末の設定アプリから設定できる。

3のため、ゲームのセーブデータ共有などには向かない。（セーブしたタイミングでバックアップが走るとは限らないので）
4は実際に試したところ、そんな感じの挙動だった。

Androidのアプリデータバックアップ事情

アプリを製作していると、たまにデータの引き継ぎの話になる。
iOSでは、ある程度はiTunesのバックアップでデータまで引き継ぎできるので、まーこれでいいか、となるが、Androidではどうなのか？

アプリデータバックアップに関しては

1. バックアップアプリを使用する。
2. Android Backup Serviceに対応するよう実装する。
3. 独自にサーバとクライアントモジュールを実装する。

などがあげられる。
（公開アプリ前提なので、Root化が必要な方法は除外）