2011年07月16日

javadoc翻訳 〜Activity編〜(4)

Configuration Changes

If the configuration of the device (as defined by the Resources.Configuration class) changes,
then anything displaying a user interface will need to update to match that configuration.
Because Activity is the primary mechanism for interacting with the user, it includes special
support for handling configuration changes.
Unless you specify otherwise, a configuration change (such as a change in screen orientation,
language, input devices, etc) will cause your current activity to be destroyed, going through
the normal activity lifecycle process of onPause(), onStop(), and onDestroy() as appropriate.
If the activity had been in the foreground or visible to the user, once onDestroy() is called
in that instance then a new instance of the activity will be created, with whatever savedInstanceState
the previous instance had generated from onSaveInstanceState(Bundle).

コンフィグレーションの変更

Resources.Configurationによって定義される、端末のコンフィグレーションが変更された場合、
表示しているユーザインタフェースはそのコンフィグレーションに適合するように更新される必要がある。
なぜなら、Activityはユーザとインタラクトする主なメカニズムであり、そこにはコンフィグレーションの変更
も含まれているからである。

端末の設定はResources.Configurationによって定義される。
端末の設定とはネットワーク設定や言語設定、あるいは画面設定などのことだ。
そのResources.Configurationが変更された場合、ユーザに対して何かを表示しているインタフェースは、
この変更を適用する必要があるだろう。そこには当然、アプリケーション、およびそれを使うActivityも含まれる。

別の方法で定義しない限り、スクリーン・オリエンテーション、言語、入力デバイスなどの各種端末設定変更により、
現在のActityは破棄されることになるだろう。その後、通常のActivtyのライフサイクル、すなわちonPause()、onStop()、そしてonDestroy()が適正にコールされるだろう。

もし、onDestroy()がコールされたActivityが、フォアグランドにいるか、ユーザから視認可能であった場合、
つまりユーザーから確認可能な位置に居た場合、保存してある以前のインスタンス状態がどうあれ、
新たにActivityインスタンスが作られることになる。

This is done because any application resource, including layout files, can change based on any
configuration value. Thus the only safe way to handle a configuration change is to re-retrieve
all resources, including layouts, drawables, and strings. Because activities must already know
how to save their state and re-create themselves from that state, this is a convenient way to
have an activity restart itself with a new configuration.

In some special cases, you may want to bypass restarting of your activity based on one or more
types of configuration changes. This is done with the android:configChanges attribute in its manifest.
For any types of configuration changes you say that you handle there, you will receive a call to your
current activity's onConfigurationChanged(Configuration) method instead of being restarted. If a
configuration change involves any that you do not handle, however, the activity will still be restarted
and onConfigurationChanged(Configuration) will not be called.

レイアウト定義ファイルを含む、アプリケーションが使用する全てのリソースは、端末設定に基づいて変化しうる。
だから、、コンフィグレーションの変更を安全にハンドリングする唯一の方法は、レイアウトや画像、文字列を含む
全てリソースをイチから全部再構築することである。そうしないと、Activityはその設定変更ひとつひとつに対して
どうデータを保存し、自身を再構築するのか考慮しなければならなくなるし、結局、イチから作りなおすのが
Activityを新しい設定でスタートさせるのにもっとも適合しているからである。

場合によっては、コンフィグレーションの変更によるActivityの再構築を回避したい場合もあるかもしれない。
この意志をハンドリング設定がandroid:configChanges属性だ。

<activity
android:configChanges=["mcc", "mnc", "locale",
"touchscreen", "keyboard",
"keyboardHidden",
"navigation", "orientation",
"screenLayout", "fontScale", "uiMode"]
</activity>


つまり、端末の設定変更をカテゴライズして、そこに変更があった際、ハンドリングしたいものを選べるわけである。
これで、設定変更の際、無条件で再構築される代わりに、Activity#onConfigurationChanged(Configuration)のコールを
受け取ることになる。もしも、ハンドリング外のコンフィグレーション変更が発生した場合は、当然Activityは無条件に
リスタートされActivity#onConfigurationChanged(Configuration)はコールされない。




Starting Activities and Getting Results

The startActivity(Intent) method is used to start a new activity, which will be placed at the top of the
activity stack. It takes a single argument, an Intent, which describes the activity to be executed.

Sometimes you want to get a result back from an activity when it ends. For example, you may start an
activity that lets the user pick a person in a list of contacts; when it ends, it returns the person
that was selected. To do this, you call the startActivityForResult(Intent, int) version with a second
integer parameter identifying the call. The result will come back through your
onActivityResult(int, int, Intent) method.

When an activity exits, it can call setResult(int) to return data back to its parent. It must always
supply a result code, which can be the standard results RESULT_CANCELED, RESULT_OK, or any custom
values starting at RESULT_FIRST_USER. In addition, it can optionally return back an Intent containing
any additional data it wants. All of this information appears back on the parent's Activity.onActivityResult(),
along with the integer identifier it originally supplied.

If a child activity fails for any reason (such as crashing), the parent activity will receive a result with the
code RESULT_CANCELED.

Activityの開始と結果取得

Activityスタックに新たなActivityを追加するコマンドが
startActivity(Intent)メソッドである。
引数にとるのはIntentというオブジェクトである。
このオブジェクトが次に起動されるActivityが何なのか知っている。

例えばあるActivityがstartActivity(Intent)を使用して新たなActivityを呼び出し、その子Activityの振る舞いの結果を、
呼び出し元のActivityが取得したい場合があるだろう。例えば、一時的に連絡リストを表示しているActivityを前面に起動して、
ユーザが選択した連絡先を元のActivityに戻したい場合などだ。これはstartActivityForResult(Intent, int)を使用する。
二つ目のintの引数は、呼び出しを識別するための識別子だ。結果はonActivityResult(int requestCode, int resultCode, Intent data)
が呼び出したActivityの処理終了時にコールバックされることによって受け取ることができる。

子Activityはその処理結果をsetResult(int)をで設定できる。引数のint値は結果コードである。結果コードはRESULT_CANCELED, RESULT_OKのほか
RESULT_FIRST_USERから始まるカスタム値が設定可能である。加えて、Intentに追加のデータを含めてリターンすることもできる。
内容はStringでもintでも、独自のオブジェクトでもよい。ただし、独自のオブジェクトをintentにセットする場合、そのオブジェクトは
Serializableインタフェースを実装する必要がある。

こうした子Activityの処理結果情報は親のonActivityResult()メソッドにオリジナルのint識別子と共に戻される。
int識別子はもちろん、親のActivityがstartActivityForResult()で引数に渡した識別子のことである。
仮に子Activityがクラッシュなど、なんらかの原因で失敗状態になった場合、親Activityは結果をRESULT_CANCELEDコードと共に受け取るだろう。

[呼び出し元(親Activity)]

・以下のコードで子Activityを起動


Intent i = new Intent(getApplicationContext(),ChildActivity.class);

startActivityForResult(i,0);


・あらかじめ、結果が返却された場合の処理を以下メソッドで実装しておく

protected void onActivityResult(int requestCode, int resultCode, Intent data) {
	
	//Check request code
	if (requestCode == DEFINED_REQUEST_CODE) {
		//expected
		
		//RESULT_OK
		if (resultCode == RESULT_OK) {
			//display message
			String message = data.getStringExtra("test.child.activity.result");
			Log.d(TAG, "message = " + message);
		}
		
	}

}



[子Activity]

・以下のコードで結果を送信


Intent intent = new Intent();
intent.putExtra("test.child.activity.result", "The world is on.The world is mine.");
setResult(RESULT_OK, intent);
finish();



javadoc翻訳 〜Activity編〜(1)
javadoc翻訳 〜Activity編〜(2)
javadoc翻訳 〜Activity編〜(3)
javadoc翻訳 〜Activity編〜(5)
javadoc翻訳 〜Activity編〜(6)last
posted by sandman at 16:30| Comment(0) | Android | このブログの読者になる | 更新情報をチェックする

2011年07月15日

Myアンドロイド&周辺機器紹介

本日は僕の愛機、Galaxy Tabの紹介を致します。
Galaxy Tab、最初はこんなもの何に使うんだよと思っていましたが、所有してみるとかなり便利な代物です。
どこにでも持っていってWEB端末として使用できるし、大きさがあるので電子書籍もストレスなくみれます。
もっともこれはAndroidなので、何ができるかはどんなアプリを入れるかにかかってきますが。
いまのところ満足しています。

以下、写真です。

Galaxy_supply.jpg

周辺機器は以下のとおり

■Bluetooth キーボード


ElecomのBluetoothキーボードです。
スマートフォンは便利ですが、いかんせんキー入力が面倒です。
長い文章を作成するにはやはりキーボードが一番かと。

ただ、説明書通りに接続すると不安定です。
このキーボードはSPP(Serial Port Profile)とHID(Human Interface Device Profile)の両方に対応しており、スマートフォンでの接続はSPPで行うと説明書には書いてあります。

実はHIDでいけます。そしてHIDのほうが安定しているようです。
ただちょっとこつがあります。

以下手順

1.まず、HIDで機器を認識させます。
2.機器を認識させたら、SPPモードに切り替えます。
3.そのままSPPでペアリング実施。
4.表示されている機器を長押しで「オプション」を選択します。
5.ここでスイッチをHIDに戻し、「HIDデバイス」にチェックを入れます。
6.キーボード側のBlueToothボタンを押して、「接続」を選択します

これで僕の環境では問題なく動いています。

■BlueTooth ヘッドセット


BlueToothのヘッドセットです。音楽再生用に購入しました。
これはかなり使い倒していますね。なにより、コードレスに音楽を聴けるのは想像以上に快適です。
本体の近くにいれば接続も切れることはほとんどなくストレスなく使用できます。
ただ、マイク機能はあまり優秀ではなく、通話するには少し雑音が混じるようです。
ただ、値段以上の価値はあったと思っています。おすすめ。


■BlueTooth マウス


Buffaloです。リンク貼っといてなんですが、これはおすすめできません。
まず、接続が切れます。それはもうブツブツと切れます。
マウスで接続がこれほど頻繁に切れるのではまったく使い物になりません。
安いだけのことはあるなって感じの商品です。


■Galaxy tab用レザーケース兼スタンド


BELKINです。これはかなり気に入っています。
デザインもシンプルですし、なによりスタンド機能が素敵です。
ただ、僕のようにSIMカードの抜き差しを頻繁にする人間にとっては
SIMカード部分に穴が開いていないのはちと不便です。
なので、僕は自分で穴あけました。カッターを使えば簡単にあけれます。
この値段でこのクオリティはなかなかお買い得です。
posted by sandman at 01:13| Comment(0) | Android | このブログの読者になる | 更新情報をチェックする

2011年07月10日

javadoc翻訳 〜Activity編〜(3)

The entire lifecycle of an activity is defined by the following Activity methods.
All of these are hooks that you can override to do appropriate work when the
activity changes state. All activities will implement onCreate(Bundle) to do
their initial setup; many will also implement onPause() to commit changes to
data and otherwise prepare to stop interacting with the user. You should always
call up to your superclass when implementing these methods.

Activityの全体的なライフサイクルは以下に示すActivityのメソッドにより定義される。
これらはActivityが状態遷移する際、それぞれオーバライドして適正な処理を行うため
のメソッド群である。全てのActivityは初期設定を行うためにonCreate(Bundle)メソッドを
実装することになる。またその多くがonPauseを実装することにより、データへの変化を
コミットするなどといった、ユーザとのインタラクトを中止するための準備を行う。
これらのメソッドを実装する際は、常にスーパークラスのメソッドをコールすべきである。

	public class Activity extends ApplicationContext {
	     protected void onCreate(Bundle savedInstanceState);

	     protected void onStart();
	     
	     protected void onRestart();

	     protected void onResume();

	     protected void onPause();

	     protected void onStop();

	     protected void onDestroy();
	}
	


In general the movement through an activity's lifecycle looks like this:
Method Description Killable? Next
onCreate() Called when the activity is first created. This is where you should do all of your normal static set up: create views, bind data to lists, etc. This method also provides you with a Bundle containing the activity's previously frozen state, if there was one. Always followed by onStart(). No onStart()
onRestart() Called after your activity has been stopped, prior to it being started again. Always followed by onStart() No onStart()
onStart() Called when the activity is becoming visible to the user. Followed by onResume() if the activity comes to the foreground, or onStop() if it becomes hidden. No onResume() or onStop()
onResume() Called when the activity will start interacting with the user. At this point your activity is at the top of the activity stack, with user input going to it. Always followed by onPause(). No onPause()
onPause() Called when the system is about to start resuming a previous activity. This is typically used to commit unsaved changes to persistent data, stop animations and other things that may be consuming CPU, etc. Implementations of this method must be very quick because the next activity will not be resumed until this method returns. Followed by either onResume() if the activity returns back to the front, or onStop() if it becomes invisible to the user. Pre-HONEYCOMB onResume() or onStop()
onStop() Called when the activity is no longer visible to the user, because another activity has been resumed and is covering this one. This may happen either because a new activity is being started, an existing one is being brought in front of this one, or this one is being destroyed. Followed by either onRestart() if this activity is coming back to interact with the user, or onDestroy() if this activity is going away. Yes onRestart() or onDestroy()
onDestroy() The final call you receive before your activity is destroyed. This can happen either because the activity is finishing (someone called finish() on it, or because the system is temporarily destroying this instance of the activity to save space. You can distinguish between these two scenarios with the isFinishing() method. Yes Nothing


通常、Activityのライフサイクルは以下のように動く
Method Description Killable? Next
onCreate() Activtyが最初に作成された場合にコールされる。ここで、全ての静的なセットアップを行うべきである。Viewの作成、リストへのデータバインド、等々。このメソッドはまた、Bundleに対して"フリーズ"されて保存されているActivityの以前の状態が存在しているのならば、それを提供する。常にonStart()が続く。 No onStart()
onRestart() Activtyがストップされた後、再び起動される前にコールされる。常にonStart()が続く。 No onStart()
onStart() Activityがユーザから視認可能になった時にコールされる。もしActivityがフォアグラウンドに配置された場合、続いてonResume()がコールされる。また、ユーザから視認不可になったときにはonStop()がコールされる。 No onResume() or onStop()
onResume() Activityがユーザとインタラクトし始めた際にコールされる。このポイントにおいて、Activtyはスタックのトップに位置している。常にonPause()が続く。 No onPause()
onPause() システムが以前に存在したActivtyを再開させようとした際に、(現在のスタックトップActivtyに対して)コールされる。これは主に保存されていない永続的データのコミットや、CPUを消費するアニメーションの停止などを行うために使用される。このメソッドの実装は非常に軽快なものでなくてはならない。なぜなら、次のActivtyはこのメソッドがリターンするまで再開されないからである。もしこのActivtyがフロントへ戻ってきた場合、onResme()がコールされ、また、ユーザから視認不可になったらonStop()がコールされる。 Pre-HONEYCOMB onResume() or onStop()
onStop() Activtyがユーザから視認不可になった時、つまり他のActivtyが再開され、このActivtyを覆っている状態になった時にコールされる。このメソッドコールは新規Axctivityが開始されるか、既存のActivtyがこのActivtyの前面に現れた場合、あるいはこのActivtyが破棄される場合に発生しうる。後にこのActivityがユーザとインタラクトするために再開された場合にはonRestart()がコールされ、またはこのActiytyが破棄されていなくなる場合にはonDestory()がコールされる。 Yes onRestart() or onDestroy()
onDestroy() Activityが破棄される直前、最終的にコールされる。このメソッドコールは誰かがfinish()をコールしたか、システムがスペースを確保するために、このActivtyインスタンスを一時的に破棄した場合、つまりActivtyの終了時に起こりうる。この二つのシナリオはisFinishing()よって判別できる。 Yes Nothing


Note the "Killable" column in the above table -- for those methods that are marked as being killable,
after that method returns the process hosting the activity may killed by the system at any time without
another line of its code being executed. Because of this, you should use the onPause() method to write
any persistent data (such as user edits) to storage. In addition, the method onSaveInstanceState(Bundle)
is called before placing the activity in such a background state, allowing you to save away any dynamic
instance state in your activity into the given Bundle, to be later received in onCreate(Bundle)
if the activity needs to be re-created. See the Process Lifecycle section for more information on
how the lifecycle of a process is tied to the activities it is hosting. Note that it is important
to save persistent data in onPause() instead of onSaveInstanceState(Bundle) because the latter is not
part of the lifecycle callbacks, so will not be called in every situation as described in its documentation.

上記テーブルの"Killable"カラム、killableにマークされているメソッドには注意すること。
このメソッドがリターンされた後、Acitiyのホストプロセスがシステムによって、他に一行のコードも実行することなく
KILLされる可能性がある。従って、onPause()ではユーザ編集などの永続データをストレージに保存すべきである。
加えて、Activtyがバックグラウンド状態に置かれる前に、onSaveInstanceState(Bundle)が呼ばれ、その中でActivty内の動的
インスタンスを与えられたBundleオブジェクト内に格納し、Activtyの再構築に必要であれば後でonCreate(Bundle)で
受け取ることができる。プロセスのライフサイクルがホスティングしているActivtyとどのように結びついているかについての
より詳細な情報は「プロセスライフサイクル」のトピックを参照のこと。onSaveInstanceState(Bundle)の代わりに
onPause()で永続的データを保存することは重要であることに留意すること。なぜなら、後者はライフサイクル・コールバック
の一部ではなく、従ってこのプロセスライフサイクルで記述されているどの状態でもコールされないからである。


Be aware that these semantics will change slightly between applications targeting platforms starting
with HONEYCOMB vs. those targeting prior platforms. Starting with Honeycomb, an application is not
in the killable state until its onStop() has returned. This impacts when onSaveInstanceState(Bundle)
may be called (it may be safely called after onPause() and allows and application to safely wait
until onStop() to save persistent state.

これらの意味はHONEYCOMBとそれ以前のアプリケーションプラットフォームの間でわずかに異なっていることに注意すること。
HONEYCOMBからは、アプリケーションはonStop()がリターンするまでkillableの状態にならない。これは
onSaveInstanceState(Bundle)がコールされる時に影響がある。つまり、onPause()の後で安全にコールされ、アプリケーションは
持続的状態を保持するためにonStop()まで安全に待機することが可能になる。


For those methods that are not marked as being killable, the activity's process will not be killed
by the system starting from the time the method is called and continuing after it returns.
Thus an activity is in the killable state, for example, between after onPause() to the start of onResume().
killableになっていないメソッドは、Activityのプロセスはこのメソッドがコールされてからリターンする
までに、システムによってKILLされることはない。逆に言えば、onPause()の後からonResume()の開始まではActivtyは
KILLされうる状態だということである。

javadoc翻訳 〜Activity編〜(1)
javadoc翻訳 〜Activity編〜(2)
javadoc翻訳 〜Activity編〜(4)
javadoc翻訳 〜Activity編〜(5)
javadoc翻訳 〜Activity編〜(6)last
posted by sandman at 15:48| Comment(0) | Android | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。