Complete Implementation and Best Practices for Calling Android Contacts List

Introduction and Problem Context

Integrating system contact functionality is a common requirement in Android application development. Developers typically need to allow users to select specific contacts from the device's contact list and return the selected contact's information (such as name, phone number, etc.) to the application. However, due to differences in Android versions, changes in permission models, and API evolution, implementing this functionality often presents various challenges.

From the provided Q&A data, the original code attempts to directly query contact data through People.CONTENT_URI and display a custom list. This approach has several issues: first, the People class has been deprecated since Android 2.0 and above; second, directly managing Cursor and list logic increases code complexity; most importantly, this method does not utilize the system-provided standard contact selection interface, resulting in inconsistent user experience and potential compatibility issues.

Core Implementation Solution

Based on the guidance from the best answer, implementing contact selection functionality should follow these three core steps, which constitute the standardized pattern for modern Android applications handling such requirements.

Permission Declaration

Add read contacts permission declaration in the AndroidManifest.xml file:

<uses-permission android:name="android.permission.READ_CONTACTS" />

Starting from Android 6.0 (API level 23), runtime permission requests are also required. Developers should check and request permissions before invoking contact selection functionality to ensure compliance with the latest security specifications. Typical runtime permission implementation includes checking the return value of ContextCompat.checkSelfPermission() and calling ActivityCompat.requestPermissions().

Launching Contact Picker

Use standard Intent to launch the system contact selection interface:

Intent intent = new Intent(Intent.ACTION_PICK, ContactsContract.Contacts.CONTENT_URI);
startActivityForResult(intent, PICK_CONTACT_REQUEST_CODE);

The key here is using the Intent.ACTION_PICK action and ContactsContract.Contacts.CONTENT_URI as the data URI. ACTION_PICK indicates that the user will select an item from the specified dataset, while Contacts.CONTENT_URI points to the standard URI of the contacts content provider. This approach lets the system decide which specific Activity to use for handling the selection request, ensuring optimal user experience and cross-device compatibility.

The request code PICK_CONTACT_REQUEST_CODE should be defined as a unique integer value within the application for identifying the request source in result callbacks. Using static constants rather than hard-coded numbers is recommended to improve code maintainability.

Handling Selection Result

Override the onActivityResult method in the Activity to handle the returned result:

@Override
protected void onActivityResult(int requestCode, int resultCode, Intent data) {
    super.onActivityResult(requestCode, resultCode, data);
    
    if (requestCode == PICK_CONTACT_REQUEST_CODE && resultCode == RESULT_OK) {
        Uri contactUri = data.getData();
        if (contactUri != null) {
            Cursor cursor = getContentResolver().query(
                contactUri,
                new String[] { ContactsContract.Contacts.DISPLAY_NAME },
                null, null, null
            );
            
            if (cursor != null && cursor.moveToFirst()) {
                String displayName = cursor.getString(
                    cursor.getColumnIndex(ContactsContract.Contacts.DISPLAY_NAME)
                );
                // Use the obtained contact name
                updateUIWithContactName(displayName);
            }
            
            if (cursor != null) {
                cursor.close();
            }
        }
    }
}

The result handling logic first verifies the request code and result code to ensure processing the correct return result. data.getData() returns the content URI of the selected contact, typically in the format content://com.android.contacts/contacts/[ID]. Querying the content provider through this URI can retrieve detailed information about the contact.

Specifying projection parameters new String[] { ContactsContract.Contacts.DISPLAY_NAME } during querying retrieves only the needed fields, which is more efficient than querying all columns. After query completion, the Cursor must be properly closed to avoid resource leaks, an important best practice in Android development.

Advanced Implementation and Optimization

Referencing supplementary content from other answers, the basic implementation can be further extended to meet more complex requirement scenarios.

Retrieving Complete Contact Information

If additional information such as phone numbers or email addresses is needed, associated queries can be performed using the contact's ID:

String contactId = cursor.getString(cursor.getColumnIndex(ContactsContract.Contacts._ID));
String hasPhone = cursor.getString(cursor.getColumnIndex(ContactsContract.Contacts.HAS_PHONE_NUMBER));

if ("1".equals(hasPhone)) {
    Cursor phoneCursor = getContentResolver().query(
        ContactsContract.CommonDataKinds.Phone.CONTENT_URI,
        null,
        ContactsContract.CommonDataKinds.Phone.CONTACT_ID + " = ?",
        new String[] { contactId },
        null
    );
    
    // Process phone number data
    
    phoneCursor.close();
}

This associated query pattern leverages the relational structure of the Android contacts database. The ContactsContract.Contacts.HAS_PHONE_NUMBER field indicates whether the contact has phone number records, avoiding unnecessary queries. Using parameterized queries (CONTACT_ID + " = ?") instead of string concatenation prevents SQL injection attacks and improves query performance.

Asynchronous Processing and Performance Optimization

For scenarios requiring retrieval of extensive contact information or complex processing, asynchronous tasks should be considered:

private class ContactQueryTask extends AsyncTask<Uri, Void, ContactInfo> {
    @Override
    protected ContactInfo doInBackground(Uri... uris) {
        // Execute contact information query in background thread
        return queryContactDetails(uris[0]);
    }
    
    @Override
    protected void onPostExecute(ContactInfo result) {
        // Update UI in main thread
        displayContactInfo(result);
    }
}

Moving time-consuming database query operations to background threads via AsyncTask or more modern Coroutine (in Kotlin) avoids interface lag caused by blocking the main thread. This is particularly important for handling scenarios involving large numbers of contacts or requiring complex data processing.

Compatibility Considerations and Best Practices

When implementing contact selection functionality, differences across Android versions and best practices must be considered.

API Version Compatibility

The ContactsContract API was introduced from Android 2.0 (API level 5), replacing the older Contacts and People classes. For applications needing to support earlier versions, conditional code should be used:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.ECLAIR) {
    // Use ContactsContract
    Intent intent = new Intent(Intent.ACTION_PICK, ContactsContract.Contacts.CONTENT_URI);
} else {
    // Fallback to old API (for extremely rare cases)
    Intent intent = new Intent(Intent.ACTION_PICK, People.CONTENT_URI);
}

However, considering the negligible market share of versions below Android 2.0, modern applications typically set the minimum API level to 15 or higher, allowing focus on using the ContactsContract API.

Error Handling and Edge Cases

Robust contact selection implementation should include comprehensive error handling:

try {
    startActivityForResult(intent, PICK_CONTACT_REQUEST_CODE);
} catch (ActivityNotFoundException e) {
    // Handle case where no contact app is available
    Toast.makeText(this, "No contact app available", Toast.LENGTH_SHORT).show();
}

Other edge cases to consider include: user cancellation of selection (resultCode == RESULT_CANCELED), null return data, denied permissions, query exceptions, etc. Complete implementation should provide appropriate user feedback and error recovery mechanisms for these situations.

Conclusion

Integrating contact functionality through the system-provided contact selection interface not only simplifies the development process but also ensures consistent user experience across devices and Android versions. The core implementation is based on three key steps: permission configuration, Intent launch, and result handling. Advanced extensions can retrieve more complete contact information, while asynchronous processing and error handling enhance application quality and stability.

Modern Android development should prioritize using the ContactsContract API and standard Intent mechanisms, avoiding direct manipulation of the contacts database or creating custom selection interfaces. This approach both complies with Android design specifications and fully leverages system optimizations and benefits from future API improvements.