Android
- Android端末をUSBデバッグ接続してもMacのDDMSで認識されない問題でハマった件について (21 Sep 2012 | Tags:
Android端末をUSBデバッグ接続してもMacのDDMSで認識されない問題でハマった件について )Android端末をUSBデバッグ接続してもMacのDDMSで認識されない問題でハマった件について
現象について
Android端末をUSBケーブルでつないでデバッグ接続しても、EclipseのDDMSで認識されませんでした。
PCは、Core2世代のMac book air
Android端末は、docomo版Sony EricssonのXperia arc
原因
端的に言うと、MBAにインストールされていたEasyTetherのドライバと競合していた為でした。
対処法
EasyTetherのドライバを削除することで、DDMSでAndroid端末が認識されない問題は解消できます。
「/System/Library/Extentions」をFinderで開き、「EasyTetherUSBEthernet.kext」を削除する
競合そのものを解消する方法ではないので、EasyTetherが使えなくなりますが、Android2.3以降？の端末では、OSの機能としてテザリングがサポートされているようなので影響は少ないかな、と。
こちらの記事を参考しました。
LinkLatest post:
- OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った
- OpenWhisk+Scalaで作るServerless Architectureとっかかり
- BluemixにPlayframeworkアプリケーションをデプロイする
- sbt、Giter8を統合するってよ
- Scala 2.12.0でSAM型
Recent Books:
- TouchUtilsを使ったAndroidテストでjava.lang.SecurityException:PermissionDenialが起きたときの回避方法 (30 Aug 2012 | Tags:
TouchUtilsを使ったAndroidテストでjava.lang.SecurityException:PermissionDenialが起きたときの回避方法 )TouchUtilsを使ったAndroidテストでjava.lang.SecurityException:PermissionDenialが起きたときの回避方法
以前の記事では、InstrumantetionTestCaseとTouchUtilsを使ってのUIテストについて書きました。
最近、この方法でテストを実行してjava.lang.SecurityException: Permission Denialが発生して、テストに失敗する事象に悩まされたので、 回避方法を記録しておきます。
原因
この問題が発生する正確な理由はわかっていません。
特定の端末(今回の場合、私が持っていたXperia arc android2.3.4)でのみ事象の発生が確認できました。
Xperia NX, MEDIASでは同じテストケースを実行してもこの現象は確認できませんでした。
これらの状況と、logcatで確認できたエラーログから察するに、 TouchUtilsは端末によっては利用できないよう制限されているようです。
そのため、テストケース中のボタンなどのViewのクリック動作がシミュレートできずにテストが失敗したようです。
TouchUtilsを使わずにテストする方法
以前紹介した方法では、ユーザのViewのクリック動作を以下のような方法でシミュレートしました。
Activityの取得
Viewを取得して、初期状態を確認。
ボタンのクリックをシミュレート。
performClick()を使った回避方法
上記のクリックのシミュレートに使用したTouchUtilsの代わりに、performClick()を使います。
※この場合、clickPerformは明示的にUIスレッドで実行する必要があります。
Latest post:
- OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った
- OpenWhisk+Scalaで作るServerless Architectureとっかかり
- BluemixにPlayframeworkアプリケーションをデプロイする
- sbt、Giter8を統合するってよ
- Scala 2.12.0でSAM型
Recent Books:
- AndroidアプリのUIテスト-InstrumentationTestCase編- (20 May 2012 | Tags:
AndroidアプリのUIテスト-InstrumentationTestCase編- )AndroidアプリのUIテスト-InstrumentationTestCase編-
複数のActivityに跨る画面遷移のテストを調べて、サンプルを作ってみました。
サンプルのAndroidプロジェクトとテストプロジェクトは以下に置きました。
サンプルAndroidアプリ uiTestSample
サンプルテスト uiTestSample-test
参考にしたのは以下のページ How do you test an Android application across multiple Activities?
※：参考ページでは、JUnit4を使っていますが、ここではJUnit3を使っているため一部違っています。
サンプルアプリの動作について
このサンプルでは、アプリの起動後の画面にボタンが表示され、そのボタンをクリックすると別画面に遷移します。
起動後の画面
ボタンクリックで遷移後の画面
テストの概要
このサンプルでは、アプリ起動後の画面のTextViewの内容を確認。ボタン1のクリックをエミュレートし、画面遷移後の画面のTextViewの内容を確認しています。
InstrumentationTestCase
InstrumentationTestCaseを継承したクラスを作成します。 getInstrumentation()を使うことで、現在有効になってるアクティビティを捕捉し、TouchUtilsでユーザ操作をエミュレートします。
テストの流れ
捕捉するインテント情報を設定
存在するInstrumentation.ActivityMonitorがヒットするまで待ちます。タイムアウト時間を設定。
Viewを取得して、初期状態を確認。
ボタンのクリックをエミュレート。
再度Activityを取得。
画面遷移後の表示を確認。
まとめ
TouchUtilsを使えば、このほかにもドラッグ、スクロール、長押し等色々エミュレートでき、UIスレッドを意識しないで書けるので、アプリのハッピーパスのテストくらいであれば簡単に書けそうです。
Latest post:
- OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った
- OpenWhisk+Scalaで作るServerless Architectureとっかかり
- BluemixにPlayframeworkアプリケーションをデプロイする
- sbt、Giter8を統合するってよ
- Scala 2.12.0でSAM型
Recent Books:
- Androidプログラミング入門してみた-アクティビティ編- (04 Apr 2012 | Tags:
Androidプログラミング入門してみた-アクティビティ編- )Androidプログラミング入門してみた-アクティビティ編-
前回のつづきです。
今回も主に書籍（ 本格アプリを作ろう！ Androidプログラミングレシピ）を参考にして進めます。
アクティビティについて
アクティビティは、android.appp.Activityクラスのサブクラスによって記述される。 Activityのサブクラスでは、アクティビティが存続する間Androidが呼び出す、ライフサイクルコールバックメソッドをオーバーライドします。
７つのライフサイクルコールバックメソッド
- onCreate(Bundle)
最初にアクティビティが作成されたときに呼び出されるメソッド。このメソッドは、アクティビティのユーザインタフェースを作り、その他のグローバルな初期化（バックグラウンドスレッドの作成など）を必要に応じて実行する。onCreate(Bundle)が呼び出された後に、onStart()が呼び出される。このアクティビティの前の状態が保存されていたら、onCreate()にandroid.os.Bundleが渡される。（無ければnull参照が渡される）
- onStart()
アクティビティをユーザに見せる直前に呼び出される。onStart()を呼び出した後、アクティビティがフォアグラウンドに出たときにonResume()を呼び出し、アクティビティが隠されるときにonStop()を呼び出す。
- onRestart()
停止されていたアクティビティが再スタートされる直前に呼び出される。名前の通り。onRestart()の後にonStart()が呼び出される。
- onResume()
アクティビティがユーザと対話処理を始める直前に呼び出される。このアクティビティがフォーカスを得て、ユーザの入力を受けつける。onResume()の呼び出し後に、そのアクティビティを中断する必要がある場合のみonPause()を呼び出す。
- onPause()
別のアクティビティを再開しようとするときに呼び出される。このメソッドがリターンするまで次のアクティビティが再開されないことに注意。onPause()を呼び出した後、ユーザがそのアクティビティとの対話処理を再開したらonResume()を呼び出し、アクティビティがユーザから見えなくなったらonStop()を呼び出す。
- onStop()
アクティビティがユーザから見えなくなったときに呼び出される。アクティビティが破棄されたか、他のアクティビティが再開されて隠されたかのどちらかの理由で発生する。onStop()を呼び出した後、再びユーザとの対話処理に戻る場合はonRestart()を呼び出し、破棄される場合はonDestroy()が呼び出される。
- onDestroy()
アクティビティが破棄される前に呼び出される。ただし、メモリ不足により強制終了される場合は例外で、onDestroy()は呼び出されない。
これらの７つのメソッドによって、アクティビティのライフサイクル全体が定義され、３つのネストしたループが記述される。
３つのネストしたループ
- ライフタイム全体
最初にメソッドonCreate(Bundle)が呼び出されたときから、onDestroy()が呼び出されるまでの全ての期間。
- 可視ライフタイム
メソッドonStart()の呼び出しから、それに対応するonStop()の呼び出しまでの期間。この間、ユーザはアクティビティを画面で見られるが、アクティビティがフォアグラウンドで対話処理をしているとは限らない。
- フォアグラウンドタイム
メソッドonResume()の呼び出しから、それに対応するonPause()の呼び出しまでの期間。この間、他の全てのアクティビティより手前にあり、ユーザとの対話処理を行っている。
上記のライフサイクルを図にしたものがこれ
これを見てわかるように、onDestroy()は呼び出されない場合があるので、データ保存の処理を書いてもあてにはならない。onPause()の中でコミットするのが一般的。onDestroy()の実装では、アクティビティに割り当てられていたリソースの解放をするのが一般的。
タスク、アクティビティスタック
- タスク
相関するアクティビティのシーケンスのこと。アクティビティスタックを提供する。
- アクティビティスタック
相関するアクティビティのシーケンスを記録する。「ヒストリースタック」「バックスタック」とも呼ばれる。
このスタックに最初にプッシュされるアクティビティは、タスクを開始したアクティビティであり、ルートアクティビティと呼ぶ。実行中のアクティビティは、スタックの一番上に位置する。
実行中のアクティビティが別のアクティビティを起動すると、新しいアクティビティがスタックにプッシュされてフォーカスを得る。前のアクティビティがスタックに残り、停止状態になる。 ユーザが端末のバックボタンを押すと、現在のアクティビティがポップされて、その前のアクティビティが実行中になる。ポップされたアクティビティは破棄される。このときアクティビティが停止したときのユーザインターフェースの状態がレストアされる。
スタック内のアクティビティの順序は変わることがなく、プッシュもしくはポップされるだけ。アクティビティがスタックにプッシュされるのは、現在のアクティビティによって起動された場合のみ。スタックからポップされるのはバックボタンが押され、アクティビティの使用が終わったとき。
Latest post:
- OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った
- OpenWhisk+Scalaで作るServerless Architectureとっかかり
- BluemixにPlayframeworkアプリケーションをデプロイする
- sbt、Giter8を統合するってよ
- Scala 2.12.0でSAM型
Recent Books:
- Androidプログラミング入門してみた-アーキテクチャ編- (02 Apr 2012 | Tags:
Androidプログラミング入門してみた-アーキテクチャ編- )Androidプログラミング入門してみた-アーキテクチャ編-
仕事でAndroidアプリの開発をすることになったので、改めてAndroidプログラミングについて勉強してみたいと思います。
今回は主に書籍（ 本格アプリを作ろう！ Androidプログラミングレシピ）を参考にして進めました。
アプリケーションアーキテクチャについて
Androidアプリのアーキテクチャは、「intent(以下、インテント)」を用いて相互にコミュニケーションを行うコンポーネントの集合がベースになっているそうです。 インテントとは、実行すべき処理や外部イベントが発生したことを他のコンポーネントに通知するために使われるメッセージです。
コンポーネント
ついさっきあったように、コンポーネントはAndroidアプリを構成する要素です。 Androidアプリのエントリポイントは、C言語のmain()関数のように定まったものはなく、代わりにアプリが必要に応じてインスタンス化して実行できるコンポーネントを使用することになります。
アクティビティ
コンポーネントの１種類。 ユーザがアプリと対話処理できるようにUIが提供するコンポーネント。自分の理解ではViewを持っているコンポーネント。
サービス
コンポーネントの１種類。 バックグラウンドで実行されて、アクティビティの様にViewは持たない。UIが表示されていないとき何がしかの処理を行うために用いる。そのためにスレッドを生成したり、別プロセスで実行されたりする。
ブロードキャストレシーバ
コンポーネントの１種類。 同報通信(broadcast)を受信して、それに対する処理を行う。名前の通り。Viewは持たないが、アクティビティの起動したり通知マネージャで画面へ情報を表示する。
コンテンツプロバイダ
コンポーネントの１種類。 アプリが管理するデータを、他のアプリからも使えるようにする。データはAndroidファイルシステムでもSQLiteでも、何でもOK。データプロバイダを使うことで、データのフォーマット変更による影響をコンポーネントが受けないように出来る。
インテント
コンポーネント間のメッセージ。 インテントは明示的、暗黙的の２種類に分類される。
明示的インテント
ターゲットとなるコンポーネント名を指定したインテント。アプリの内部メッセージとして使われる。
暗黙的インテント
ターゲットとなるコンポーネント名を指定しないインテント。他のアプリのコンポーネントを起動するために用いられることが多い。 暗黙的インテントの処理に最適なコンポーネントを探す処理の際、AndroidはIntentオブジェクトの内容とインテントフィルタを比較する。
インテントフィルタ
コンポーネントがどんなインテントを受け取ることができるか？を明示するためのマニフェスト情報。 インテントフィルタを持たないコンポーネントは、明示的インテントしか受け取らない。
マニフェスト
アプリの持つ情報やアプリケーション間の相互連携に必要な設定、コンポーネント、インテントフィルター情報を含む。 アプリをインストールするときに確認されるようなパーミッション付与についても情報を持っている。
この辺がわかりやすいサイトがあったので参考にしました。
Latest post:
- OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った
- OpenWhisk+Scalaで作るServerless Architectureとっかかり
- BluemixにPlayframeworkアプリケーションをデプロイする
- sbt、Giter8を統合するってよ
- Scala 2.12.0でSAM型
Recent Books:
