Android Phonebook: Contact UI loading and contact storage process (2)

17:18:29

1. in Phonebook, the UI for creating/editing contacts is not written in xml files. It loads different UIS as the Account type changes, such as SIM contacts, with only Name and Phone Number, if it is USIM, there may be a second number or Email, but in addition to the local contacts, there are also Nickname, Website and so on, so it is very complicated to define the account and load the UI.

2. Account type (take AdnAccountType SIM account as an example)

Inheritance relationship: AdnAccountType. java --> BaseAccountType. java --> AccountType. java, there are two important methods in AccountType:

  ArrayList<DataKind>           DataKind addKind(DataKind kind)      kind.resourcePackageName =                 }

AddKind () method to add kind to mKinds, getSortedDataKinds () to retrieve all kind, the use of these two methods will be described later. For BaseAccountType, this class is the parent class of all account classes. See AdnAccountType below:

      .accountType =          .syncAdapterPackageName =                   simType =          (simType ==                 || simType ==            mIsInitialized =      }          SpbLog.e(TAG, "Problem building account type"      DataKind addDataKindStructuredName(Context context)      DataKind kind = addKind(             R.string.nameLabelsGroup, -1,       kind.fieldList =     kind.fieldList.add(             FLAGS_PERSON_NAME).setNeedFocus(           DataKind addDataKindPhone(Context context)      DataKind kind =       kind.iconAltRes =     kind.actionHeader =      kind.actionAltHeader =      kind.actionBody =       kind.typeColumn =     kind.typeList =       kind.fieldList =     kind.fieldList.add(       }

You can see that the SIM card account has added the UI of the Name and Phone number data, which complies with the rules that SIM contacts can only add names and numbers. If the SIM card is USIM or CSIM, you can also add Email information. You can see the if judgment statement. In the addDataKindStructuredName () method, call the addKind () method described earlier to add a DataKind object and add EditField to the fieldList of the DataKind object, this fieldList contains the View to be displayed, which is actually the sub-entries contained in the phone number or Email entry. These items will be detailed later. The following describes the more complex LocalAccountType:

      .accountType =     .resourcePackageName =      .syncAdapterPackageName =                             mIsInitialized =      }          SpbLog.e(TAG, "Problem building account type"      DataKind addDataKindPhone(Context context)       DataKind kind =       kind.typeColumn =     kind.typeList =        kind.typeList.add(buildPhoneType(Phone.TYPE_FAX_WORK).setSecondary(     kind.typeList.add(buildPhoneType(Phone.TYPE_FAX_HOME).setSecondary(     kind.typeList.add(buildPhoneType(Phone.TYPE_PAGER).setSecondary(      kind.typeList.add(buildPhoneType(Phone.TYPE_CUSTOM).setSecondary(       kind.fieldList =     kind.fieldList.add(       }

As you can see, the local account contains more information, and the Phone number contains many types, such as HOME, MOBILE, and FAX.

AddDataKindStructuredName adds the name-related UI, which is included in kind. fieldList. Each EditField can be considered as an EditTest,

 

AddDataKindPhone adds the PhoneNumber-related UI, kind. fieldList only contains one EditField. Only one EditText is displayed, but kind. typeList adds a lot of things. You can click the Type Spinner to see the eight in total, which are consistent with the Code, such:

 

3. The above analyzes what an account type class contains, including some DataKind, and each DataKind has kind. typeList, kind. fieldList, and other attributes. Therefore, a DataKind represents a type of information, such as Name, Phone number, and Email. However, Name contains a lot of specific information, such as prefix, suffix, and first name, the Phone number contains an EditText file, but there are many types of numbers and so on. This forms a complete account class. when loading the UI, add the UI contained in the account based on the current account. How to load the subsequent analysis.

4. The above analysis involves two auxiliary classes: DataKind and EditField. Let's take a look at these two classes respectively:

                                                                         actionBodySocial =                  List<EditType>      List<EditField>                                              editorLayoutResourceId =         maxLinesForDisplay = 1         DataKind(String mimeType,  titleRes,  weight,                       .mimeType =         .titleRes =         .weight =         .editable =         .typeOverallMax = -1         .editorLayoutResourceId =         maxLinesForDisplay = 1  }

As shown in the preceding figure, DataKind is a class that encapsulates information only.

                                                    needFocus =        editable =                EditField(String column,          .column =         .titleRes =         EditField(String column,  titleRes,                   .inputType =         EditField setOptional(         .optional =                 EditField setShortForm(         .shortForm =                   EditField setLongForm(         .longForm =                   EditField setMinLines(         .minLines =                             (inputType & EditorInfo.TYPE_TEXT_FLAG_MULTI_LINE) != 0         EditField setNeedFocus(         .needFocus =                 EditField setEditable(         .editable =            }

Similar to DataKind, EditField encapsulates some information and analyzes how the information is parsed when the UI is loaded.