2011年08月03日

エドワード・ゴーリー 『不幸な少女』


エドワード・ゴーリーの『不幸な少女』。
知人女性の誕生日プレゼントを選んでいるときに、ひと目惚れして購入した。
まずタイトルが良い。僕は基本的にタイトルで本を買う。
どの本を読むかは、純粋に「出会い」でしかない。であれば、第一印象はとても重要だし
実際、タイトルが面白そうな本はだいたい面白い。
そこらへんは経験と勘の世界である。

さて、『不幸な少女』は主人公の少女がひたすらに不幸のどん底に落ちていくだけの話だ。
身も蓋もない紹介だが、実際にそうなのだから仕方がない。
そんな話のどこが面白いのかとお思いだろうが、そんな話がなんだか面白いのが
人間の面白いところだ。僕は悪趣味を悪趣味であるとカラカラ笑える人間が好きである。

しかしながら、これを贈った知人女性は
「この娘、悪い男に引き取られた後、性的虐待を受けていないじゃない。駄目ね。」
と言っていた。
とんでもないことを言う女だ。
でもなんだかんだ結構気に入ってくれた。






posted by sandman at 22:35| Comment(0) | | このブログの読者になる | 更新情報をチェックする

2011年07月31日

javadoc翻訳 〜Activity編〜(6)last

Process Lifecycle

The Android system attempts to keep application process around for as long as possible, but eventually
will need to remove old processes when memory runs low. As described in Activity Lifecycle, the decision
about which process to remove is intimately tied to the state of the user's interaction with it. In general,
there are four states a process can be in based on the activities running in it, listed here in order of
importance. The system will kill less important processes (the last ones) before it resorts to killing more
important processes (the first ones).
プロセス・ライフサイクル

Androidシステムはアプリケーションプロセスを可能な限り長く保とうとするが、いずれはメモリ不足により古いプロセスを
破棄する必要がでてくる。Activityのライフサイクルのトピックにおいて記述した通り、プロセス破棄の決定は、その
プロセスがユーザに対するどのようにインタラクトしている状態であるかに深く関わっている。通常、プロセスは自身の中で
動作しているActivityに基づいて、4つの状態を取りうる。以下はそのリストである。システムは、重要なプロセスをKILLしてしまう
前に、より重要度の低いプロセスをKILLしようとするだろう。

1)
The foreground activity (the activity at the top of the screen that the user is currently interacting with)
is considered the most important. Its process will only be killed as a last resort, if it uses more memory than
is available on the device. Generally at this point the device has reached a memory paging state, so this is
required in order to keep the user interface responsive.

2)
A visible activity (an activity that is visible to the user but not in the foreground, such as one sitting
behind a foreground dialog) is considered extremely important and will not be killed unless that is required
to keep the foreground activity running.

3) A background activity (an activity that is not visible to the user and has been paused) is no longer critical,
so the system may safely kill its process to reclaim memory for other foreground or visible processes. If its
process needs to be killed, when the user navigates back to the activity (making it visible on the screen again),
its onCreate(Bundle) method will be called with the savedInstanceState it had previously supplied in
onSaveInstanceState(Bundle) so that it can restart itself in the same state as the user last left it.

4)
An empty process is one hosting no activities or other application components (such as Service or BroadcastReceiver
classes). These are killed very quickly by the system as memory becomes low. For this reason, any background
operation you do outside of an activity must be executed in the context of an activity BroadcastReceiver or
Service to ensure that the system knows it needs to keep your process around.

1)
最前面のActivity(ユーザが現在インタラクトしている最上位のActivity)は最重要だとみなされる。このActivityを
有するプロセスがKILLされるのは、このプロセスがデバイスの許容範囲外のメモリを使用した場合のみである。一般的に、
このような場合、端末はメモリ・ページング状態にあり、従ってこの対処はユーザインタフェイスを応答不能にしないために
実行されるものである。

2)
視認可能なActivity(最前面ではないが、ユーザから視認可能なActivity。例えば、ダイアログの後ろにあるActivityなど)
もまた極めて重要だとみなされる。このプロセスは最前面のプロセスを保持する目的以外でKILLされることはない。

3)
バックグラウンドのActivity(ユーザから視認できず、ポーズされたActivity)はすでに最重要とはいえない。従って、システムは
ほかの最前面にあるプロセスや視認可能なプロセスのメモリを確保するために安全にKILLすることができる。もしこのプロセスを
KILLする必要があるならば、ユーザがバックボタンでそのActivityに戻ったとき(つまり、再び視認可能になったとき)、
以前にonSaveInstanceState(Bundle)で保存されたsavedInstanceStateと共に、そのActivityのonCreate(Bundle)メソッドが
コールされるだろう。これにより、そのActivityは最後にユーザが残していったままの状態で再構築できるのである。

4)
空プロセスはActivityもほかのアプリケーションコンポーネント(ServiceとかBroadcastReceiverとか)もホスティングして
いないプロセスである。これらはシステムがメモリ不足になると直ちにKILLされる。したがって、Activity外でいかなる
バックグラウンド処理を行うにしても、それはActivityのBroadcastReceiverなりServiceなりのContextないで実行しなければ
ならない。そうしないと、システムがそのプロセスを保持するべきだと認識できないからである。

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

2011年07月24日

javadoc翻訳 〜Activity編〜(5)

Saving Persistent State

There are generally two kinds of persistent state than an activity will deal with: shared document-like data
(typically stored in a SQLite database using a content provider) and internal state such as user preferences.

For content provider data, we suggest that activities use a "edit in place" user model. That is, any edits a
user makes are effectively made immediately without requiring an additional confirmation step. Supporting this
model is generally a simple matter of following two rules:

When creating a new document, the backing database entry or file for it is created immediately. For example,
if the user chooses to write a new e-mail, a new entry for that e-mail is created as soon as they start entering
data, so that if they go to any other activity after that point this e-mail will now appear in the list of drafts.

When an activity's onPause() method is called, it should commit to the backing content provider or file any changes
the user has made. This ensures that those changes will be seen by any other activity that is about to run.
You will probably want to commit your data even more aggressively at key times during your activity's lifecycle:
for example before starting a new activity, before finishing your own activity, when the user switches between
input fields, etc.

永続的な状態の保存

Activityが扱う永続的データには2種類ある。ひとつが、共有フォルダチックなデータである。これはコンテント・プロバイダを使用して
SQLiteデータベースに保存される。もうひとつがユーザ設定のような端末内部状態である。

コンテント・プロバイダーが管理するデータに関して、Activityは"edit in place(その場編集)"モデルを採用している。
これは、ユーザの起こしたあらゆる編集を、追加の確認段階を踏まずに迅速に有効化するものである。
このモデルには二つのシンプルなルールがある。

@新たなドキュメントを作成しているときは、バックグラウンドのデータベースエントリーや、ファイルを 直ちに作成する。
 例えば、もしユーザが新たなEmailを作成した場合、ユーザがデータをエンタリングした場合
 そのEmail用の新たなエントリを直ちに作成する。これにより、違うActivityに遷移した後でも、Emailを編集していた
 Activityに戻れば、先ほど編集していたEmailは下書きの中に入っているわけである。

AActivityのonPause()メソッドが呼ばれた場合、ユーザ編集の全ては背後のコンテント・プロバイダーなりファイルなりに
 コミットされるべきである。これにより、ほかの起動されるActivityからでも、ユーザ編集への参照が保証される。
 場合によっては、もっと能動的に、Activityの各ライフサイクルの中でデータをコミットしたい場合もあるだろう。
 例えば、新たなActivityを起動する直前や、自身のActivityを終了させた後、あるいはユーザがインプット・フィールドを
 切り替えた場合などである。

This model is designed to prevent data loss when a user is navigating between activities, and allows the system to safely kill
an activity (because system resources are needed somewhere else) at any time after it has been paused. Note this implies that
the user pressing BACK from your activity does not mean "cancel" -- it means to leave the activity with its current contents
saved away. Canceling edits in an activity must be provided through some other mechanism, such as an explicit "revert" or "undo" option.

See the content package for more information about content providers. These are a key aspect of how different activities invoke
and propagate data between themselves.

The Activity class also provides an API for managing internal persistent state associated with an activity. This can be used,
for example, to remember the user's preferred initial display in a calendar (day view or week view) or the user's default home
page in a web browser.

Activity persistent state is managed with the method getPreferences(int), allowing you to retrieve and modify a set of name/value
pairs associated with the activity. To use preferences that are shared across multiple application components (activities, receivers,
services, providers), you can use the underlying Context.getSharedPreferences() method to retrieve a preferences object stored under
a specific name. (Note that it is not possible to share settings data across application packages -- for that you will need a content provider.)

Here is an excerpt from a calendar activity that stores the user's preferred view mode in its persistent settings:

この"edit in place"モデルによってActivityがpauseされた後であるならば、以下のことが実現できる。
 ・ユーザがActivity間に渡って端末操作を行った場合のデータ紛失の回避
 ・Activityの安全なKILL(システム・リソースが必要になった場合など)

つまり、ユーザが「戻る」ボタンを押したからといって、Activityが「キャンセル」されるわけではないことに注意すること。
あくまでも、Activityを現在の状態で保存し、一時的に放置しているに過ぎないのである。Activity内での編集破棄は、"revert"、"undo"オプションといった
他のメカニズムで提供されるべきである。

コンテント・プロバイダーに関する詳細はcontentパッケージを参照してください。ここにActivity間がお互いにどうやって呼び出し合い、データを伝播させているかに
ついてのキーが記載されている。

Activityクラスは、Activityに関連した内部的な永続的状態を管理するためのAPIも持っている。例えば、ユーザの好みのカレンダーの初期表示、つまり
デイ・ヴューするのかウィーク・ヴューにするのかなど、あるいはブラウザのデフォルトのHPなどを記憶しておくのに使用される。

こうしたActivityの永続的状態はgetPreferences(int)メソッドによって管理される。Activityに関連するname/valueペアのプロパティを取得、修正すること
が可能になる。ActivityやReciver、ServiceやProviderといった複数のアプリケーション・コンポーネント間でユーザ・プリファレンスを共有したい場合、
Context.getSharedPreferences(String, int)メソッドを使用する。このメソッドを通して、特定の名前で定義されたオブジェクトを取得することができる。
(ただし、異なるアプリケーション間でセッティングデータを共有することはできない。その場合はコンテント・プロバイダーを使用すること)

以下は設定で保持しているユーザの好きなヴュー・モードをストアリングしているカレンダーActivityからの抜粋コードである。

 public class CalendarActivity extends Activity {
     ...

     static final int DAY_VIEW_MODE = 0;
     static final int WEEK_VIEW_MODE = 1;

     private SharedPreferences mPrefs;
     private int mCurViewMode;

     protected void onCreate(Bundle savedInstanceState) {
         super.onCreate(savedInstanceState);

         SharedPreferences mPrefs = getSharedPreferences();
         mCurViewMode = mPrefs.getInt("view_mode" DAY_VIEW_MODE);
     }

     protected void onPause() {
         super.onPause();
 
         SharedPreferences.Editor ed = mPrefs.edit();
         ed.putInt("view_mode", mCurViewMode);
         ed.commit();
     }
 }
Permissions

The ability to start a particular Activity can be enforced when it is declared in its manifest's tag. By doing so, other
applications will need to declare a corresponding element in their own manifest to be able to start that activity.

See the Security and Permissions document for more information on permissions and security in general.

パーミッション

ある特定のActivityを起動する能力は、マニフェストファイルのactivityタグに権限が明示されていた場合に制限されることがある。これによって、
他のアプリケーションはそのActivityを起動するために、対応するuses-permissionタグを自身のマニフェストファイルに宣言する必要がでてくる。

権限とセキュリティーに関するより詳しい情報は以下のリンクを参照すること。
Security and Permissions document

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

広告


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

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

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


×

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