2011年09月04日

Android document翻訳 〜Application Fundamentals編〜(1)


Application Fundamentals
アプリケーションの根幹



Android applications are written in the Java programming language. The Android SDK tools
compile the code along with any data and resource files into an Android package, an
archive file with an .apk suffix. All the code in a single .apk file is considered to
be one application and is the file that Android-powered devices use to install the application.


AndroidアプリケーションはJavaプログラミング言語で記述されている。Android SDK toolsは
Androidパッケージ(.apkという拡張子を持つアーカイブファイル)内の様々なデータやリソース
ファイルと連動して、そのコードをコンパイルする。単一のapkファイル内の全てのコードは
単一のアプリケーションであると見做され、またAndorid対応端末がアプリケーションをインストール
するために使用するファイルでもある。


Once installed on a device, each Android application lives in its own security sandbox:

・The Android operating system is a multi-user Linux system in which each application is a
different user.

・By default, the system assigns each application a unique Linux user ID (the ID is used only
by the system and is unknown to the application). The system sets permissions for all the
files in an application so that only the user ID assigned to that application can access them.

・Each process has its own virtual machine (VM), so an application's code runs in isolation
from other applications.

・By default, every application runs in its own Linux process. Android starts the process when
any of the application's components need to be executed, then shuts down the process when
it's no longer needed or when the system must recover memory for other applications.



端末にインストールされると、個々のAndroidアプリケーションは自身のセキュリティー・サンドボックス
内で動く。

・Android OSはマルチユーザのLinuxシステムであり、各々のアプリケーションは異なったユーザとなる。

・デフォルトでは、システムは各々のアプリケーションに対して、ユニークなLinuxユーザIDを割り当てる。
(そのIDはシステムが使用するものであり、個々のアプリケーションが関知するものではない)
システムはアプリケーション内の全てのファイルについて、そのアプリケーションに割り当てられた単一の
ユーザIDだけがそれにアクセスできるようパーミッションをセットする。

・各々のプロセスは自身のVMを保持しており、従って、あるアプリケーションのコードは他のアプリケーション
とは隔絶されている。

・デフォルトでは、全てのアプリケーションは自身のLinuxプロセス上で動いている。アプリケーションの
コンポーネントが実行される必要がある場合、Androidはプロセスをスタートさせる。その際、すでに不要に
なったプロセスや、ほかのアプリケーションのためにメモリをリカバリしなければならない場合に
プロセスをシャットダウンする。



In this way, the Android system implements the principle of least privilege. That is, each
application, by default, has access only to the components that it requires to do its work
and no more. This creates a very secure environment in which an application cannot access
parts of the system for which it is not given permission.


このようにして、Androidシステムは最小の権限(least privilege)原則を採用している。つまるところ、
デフォルトでは、各々のアプリケーションはその動作上必要となるコンポーネントのみにアクセスできる
のである。これは、パーミッションが与えられていないシステムの一部にはアプリケーションはアクセス
できないという、非常にセキュアな環境を作りだす。


However, there are ways for an application to share data with other applications and for an
application to access system services:

・It's possible to arrange for two applications to share the same Linux user ID, in which case
they are able to access each other's files. To conserve system resources, applications with
the same user ID can also arrange to run in the same Linux process and share the same VM
(the applications must also be signed with the same certificate).

・An application can request permission to access device data such as the user's contacts,
SMS messages, the mountable storage (SD card), camera, Bluetooth, and more. All application
permissions must be granted by the user at install time.



しかし、あるアプリケーションが他のアプリケーションとデータを共有したり、システムサービスにアクセス
する方法も存在する。


・2つのアプリケーションが同一のLinuxユーザIDを共有するように調整することが可能である。その場合、
これらのアプリケーションが互いのファイルにアクセスできる。システムリソースを保存するために、
同一のユーザIDを持ったアプリケーションは同一のLinuxプロセス上で動き、同一のVMを共有する。
(これらのアプリケーションは同一の証明書に署名されていないければならない)

・アプリケーションは端末情報にアクセスする権限を要求することができる。端末情報とは、電話帳や
SMSメッセージ、SDカード、カメラ、ブルートゥースなどである。全てのアプリケーションの権限は
アプリケーションインストール時にユーザによって承諾されなくてはならない。



That covers the basics regarding how an Android application exists within the system. The rest of
this document introduces you to:

・The core framework components that define your application.

・The manifest file in which you declare components and required device features for your application.

・Resources that are separate from the application code and allow your application to gracefully optimize
its behavior for a variety of device configurations.


Androidアプリケーションがシステム内にてどのように存在しているのかということについての記述を、この文書は
包括する。これ以降、この文書は以下を紹介していく。

・アプリケーションを定義するアプリケーションフレームワークのコア

・アプリケーションのためにコンポーネントの宣言やデバイス・フィーチャーを要求するのに使用する
マニフェストファイル

・アプリケーションコードと切り離され、様々なデバイス・コンフィグレーションに対してアプリケーションの
振る舞いを最適化させるリソースについて
posted by sandman at 17:05| Comment(0) | Android | このブログの読者になる | 更新情報をチェックする

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年以上新しい記事の投稿がないブログに表示されております。