Android开发官方网站 给我们Android开发从入门到深入提供了完善的文档支持。 在Dev Guide标签下，文档完整定义了Android（What is Android?），包括给出其特性、架构（底层硬件和上层软件）、自带应用、应用框架、库、运行环境以及其所带的Linux内核等信息和参数。在应用基 础（Application Fundamentals）中介绍了四大应用组件——Activities，Services，Content providers以及Broadcast receivers。等等。本项目的开发过程，同样是对这些文档进行研读的过程；很多思想和实践指导着本应用于的开发，其中令人感受最深的是“edit in place”思想（实践）。 英文原文：（位于对Activity类进行规约的页面中。地址： ） 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系统的人，会很不习惯——译者注）。活动体中的撤消编辑，必须以某种其他的机制提供，比如要给出明显的“还原”或 “撤消”选项。