History log of /packages/apps/Contacts/src/com/android/contacts/model/EntityDiff.java
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
14f61ab769f6e178a540a7579e446a010fb836da 06-Aug-2009 Jeff Sharkey <jsharkey@android.com> Switch edit UI to tabs, TYPE_ASSERT for version, cleanup.

Integrated with the tabs and header widget built by
emillar, kept separate from BaseContactCardActivity since
I'm handling EDIT/INSERT intents differently. Added hooks
to pick primary photo/name from header.

Cleaned up the colorful testing UI, added padding to match
mocks, and initial pass at collapsed secondary area. Added
back menu items and confirmation toast.

Changed to new TYPE_ASSERT ContentProviderOperation for
asserting RawContacts.VERSION number during updates.
/packages/apps/Contacts/src/com/android/contacts/model/EntityDiff.java
2ae666ec99ae9318936a9326e5243987e4e1c586 22-Jul-2009 Jeff Sharkey <jsharkey@android.com> Checkpoint of new edit contact UI, work in progress.

This change introduces several new concepts which are
summarized below. One major change is a MMVC approach that
has two models: the structured Contacts data, and the
data-source constraints model. Another is augmenting an
Entity using a specific set of actions.

First, each data source is defined through a ContactsSource
that describe how it handles data, both for rendering and
editing cases, such as the Data.MIMETYPE it handles, what
types are allowed, and the fields required for editing. In
this change, ContactsSource objects for Google and Exchange
are hard-coded, but an initial XML version will need to be
finalized for supporting third-party apps that show custom
icons and strings.

Second, AugmentedEntity allows us to keep the edit changes
separate from the initial data and build a "diff" between
the current Entity state and the desired changes, which is
represented as a set of ContentProviderOperations. If the
data changed while the user was editing, we can easily swap
in the new Entity and apply the edits on top. In the worst
case, this may end up creating duplicated data, but won't
lose the users changes.

Finally, this change starts splitting the UI and modeling
code into different sub-packages. The UI is split into
multiple ViewHolders to mirror the structure on screen.

There are dozens of TODOs littered throughout the code,
which I'm following up on shortly. This is a checkpoint to
start a code review on the core structure.
/packages/apps/Contacts/src/com/android/contacts/model/EntityDiff.java