By, Jacob Michaelis, SimpleNexus Android Developer

Link to original article here

Purpose

At SimpleNexus, we sell software to mortgage companies. These companies can have hundreds of loan officers, and thousands of users. Company admins and especially loan officers wanted a way to differentiate between their app users and spam calls. A recent deploy to our app displays app user data as caller ID. Now when admins and loan officers receive phone calls from users not saved in their phone they can confidently answer. This caller ID functionality has many more practical applications.

This article teaches how to display your users as caller ID data. The most helpful documentation found on this subject was in the Android docs regarding ContactsContract.Directory and ContactsContract.PhoneLookup. But who doesn’t like some real life code examples to learn from?

Get Started

Clone or fork the Sample Caller ID App repository. The master branch is the starting point for this tutorial. The callerid branch is the final product of this tutorial.

Get a phone or Google Voice account with a phone number not in your contacts app.

You may need to disable spam filtering on your Android device.

Content Providers

One of the key native elements in Android development is the ContentProvider. We will need to create one to send information to apps that want phone numbers:

In the Android Manifest:

If you’re like me, you’ve never seen some of this stuff before. So let me explain what is happening here. The key elements to this content provider are:

The query method: All ContentProviders need a query method. Any service asking for information from an app will send a URI matching what kind of data they want, and a projection reference of which columns it wants. The result is a cursor with the data requested.

method: All ContentProviders need a query method. Any service asking for information from an app will send a URI matching what kind of data they want, and a projection reference of which columns it wants. The result is a cursor with the data requested. The uriMatcher : As mentioned in the documentation linked above regarding ContactContract.Directory, to display “directory” information (such as phone numbers and email addresses), the app must first display directory account information. This has to be unique from all other apps on the device. More will be explained later on what to return in response to the “directories” URI.

: As mentioned in the documentation linked above regarding ContactContract.Directory, to display “directory” information (such as phone numbers and email addresses), the app must first display directory account information. This has to be unique from all other apps on the device. More will be explained later on what to return in response to the “directories” URI. The <meta-data> : This is how the system know that your app can provide directory information. Much like an intent. Important also to notice, the provider has “authorities”. It is important to use the same authority throughout your content provider, but the value is not as important. For this app my authority was com.example.simplecallerid.callerid .

Directories

The first step is to display directory account information. These values can be arbitrary, they just need to be unique. In the `query` method, fill a MatrixCursor with the right column data and send it back:

Now the system knows your app can provide a few kinds of data. It will send URI’s like contacts/lookup/* , phone_lookup/* , data/emails/lookup/* etc.

Phone Lookup: Caller ID

The important URI for a caller ID app is phone_lookup/* . Add the following to your ContentProvider:

Let’s get the data:

Now all that’s left to do is return a cursor with your contact data:

https://gist.github.com/jacobmichaelis/0a90d96f476d0237717cb3eda1e851ee

The Final Product

You should now be able to run your app on your phone. Add a user with a phone number you don’t have saved to a contact on your phone. Call yourself from that phone number and you should see something like this: