Hello dear readers, or should I say, Hello World? Hue hue!
This is third time if I am calculating correctly that I am starting a blog, so don’t expect too much.
I’ve always stopped writing due to lack or quality of content, but this time I am sure I have something quite interesting here!
I am currently in progress of writing a internal application for Android that is supposed to manage the calls in logging manner.
So the ultimate task I am trying to solve here is to log every call and mark their type to the database.
However today I was stuck with a problem!
So as a Android developer(?) you might know about the Broadcast system Android uses to notify applications about events system wide.
As I started to develop the application the obvious choice was of course to hook to the broadcast system using a BroadcastReceiver and listening for android.intent.action.PHONE_STATE and android.intent.action.NEW_OUTGOING_CALL broadcasts, which basically notifies the receiver about telephony state changes such as phone ringing or phone not ringing anymore.
As I started to implement the BroadcastReceiver and checking for possible outcomes I noticed on the documentation the following text:
The
EXTRA_STATEextra indicates the new call state. If the new state is RINGING, a second extraEXTRA_INCOMING_NUMBERprovides the incoming phone number as a String
That’s when I got worried, what if the system doesn’t provide me with the number in other states except for the RINGING state, how can I possibly know when which call had ended when the state is updated..
I began my quest to crawl through the docs thoroughly and quickly found out that the TelephonyManager has a listen method, which accepts a PhoneStateListener, which on part has a method onCallStateChanged with parameters of phoneState and incomingNumber, I thought this was it!
But after firing up the app and doing some calls my worst nightmare came to true, the incomingNumber is actually only incomingNumber, and what I mean is that it is only provided when a call is receiving, AKA ringing.. So using this listener I could only receive the same amount of data as with the broadcast receiver..
I was just about to give up handling multiple calls for the API limitations but as we visited chinese restauraunt on our lunch break we came up with a ‘foolproof’ way of handling multiple calls.
As we’re receiving the IDLE event as a broadcast when all the calls have ended, we know then to query the call log for any recent calls, and see which are new and how long had they lasted and let the user handle logging of those.
And that’s what I ended up with. When the BroadcastReceiver is first started, it checks if the processed call ids have been initialized, and if not it setups a list of phone calls that were pre-existent before the installation of the app, to figure out which of the calls are new.
Then the app just sits and waits for the EXTRA_STATE_IDLE to be broadcasted and once it is done it starts listening for changes in CallLog with a ContentObserver, and once the change happens we know that there’s been a write in the call log(hopefully..) and proceed to process the calls!
Phew! that was quite an adventure! but these are the kind I walk up to once in a while, and hope to write about.
So if you’re interested more about such horror stories as a Android Developer, drop me a comment.
Thanks for reading!