Android開發中「即編即達」的用戶模型

Android開發官方網站 http://developer.android.com 給咱們Android開發從入門到深刻提供了完善的文檔支持。

在Dev Guide標籤下，文檔完整定義了Android（What is Android?），包括給出其特性、架構（底層硬件和上層軟件）、自帶應用、應用框架、庫、運行環境以及其所帶的Linux內核等信息和參數。在應用基 礎（Application Fundamentals）中介紹了四大應用組件——Activities，Services，Content providers以及Broadcast receivers。等等。本項目的開發過程，一樣是對這些文檔進行研讀的過程；不少思想和實踐指導着本應用於的開發，其中使人感覺最深的是「edit in place」思想（實踐）。

英文原文：（位於對Activity類進行規約的頁面中。地址： http://developer.android.com/reference/android/app/Activity.html ）

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.
  

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.

中文譯文：

對於內容提供者型數據（前文有定義），咱們建議活動體採用一種「即編即達」（或「寫直達」）的用戶模型。該模型是指，對用戶所做出的任何編輯，沒必要提供額 外的確認環節，一概使之生效（有點太絕對，有些情形下應該要先由用戶確認——譯者注）。要支持該模型，一般只需遵循如下兩條原則便可：

• 一個新的文檔當在概念上建立的時候，在物理上（後臺數據庫記錄或文件）就應該被當即建立了。好比，若是用戶選擇了寫郵件，那麼在用戶開始 輸入數據的那一刻，該郵件的一個永久存儲就被建立了；這以後，若是用戶跳到了其餘活動體（即便退出郵件程序——譯者增），該郵件都會以草稿的形式被保存。
• 當 活動體的onPause()方法被調用時，應該將用戶所做的任何更改當即寫回後臺數據庫或文件。這確保了這些更改可以被其餘即將運行的活動體獲知。或許你 還可能須要更加頻繁地寫回這些的更改，好比在你活動體生命週期中的關鍵時刻：在啓動一個新的活動體以前，在結束你的活動體以前，在用戶切換輸入域之時，等 等。

設計這一模型，是爲了不用戶在活動體之間穿行時致使數據丟失，並能確保系統在一個活動體被暫停以後的任什麼時候刻將其殺死都是安全的（資源緊缺時系統會選擇 性地殺死被暫停的活動體）。注意，這也意味着用戶在運行你的應用時，按BACK鍵並不意味着「撤消」——而意味着保存當前活動體當前內容，然後安全離開 （這一習慣對於用習慣了Windows系統的人，會很不習慣——譯者注）。活動體中的撤消編輯，必須以某種其餘的機制提供，好比要給出明顯的「還原」或 「撤消」選項。