Android SMS popup – Part Two : Passing Information

The Android component responsible for the user interface is the Activity. As this is a fundamental concept in the Android system, the reader is encouraged to read the section of the developer's guide on Activities and their lifecycle.

But we need to somehow transition from a BroadcastReceiver to an Activity. Looking at the Android API, we learn that we could use an Intent to start an Activity. In what form will we send the SMS information from the background processing we did in Part One, to the foreground screen display? We have a number of options:

1. Pass each SMS field individually (sender, body, timestamp) through an Intent
2. Pass a Serializable 'PopMessage' object through an Intent
3. Pass a Parcelable PopMessage object through an Intent

For the first option we could simply proceed like this:

    // code to go at the end of our SMSBroadcastReceiver's onReceive() method
    intent.putExtra("sender", sender);
    intent.putExtra("body", body);
    intent.putExtra("timestamp", timestamp);

    ----------------------------------------

    // code to go in our Activity class to retrieve the values passed above
    String sms_sender = getIntent().getStringExtra("sender");
    String sms_body = getIntent().getStringExtra("body");
    long timestamp =  getIntent().getLongExtra("timestamp", 0L);

But the two last options are the more OO and elegant ones. As for the choice to be made between the two, let's say that Parcelable is more efficient performance-wise, but needs more plumbing code (see this previous article on the subject). Here, for our simple PopMessage class, Serializable works just fine.

With the Serializable object option, we could then use Intent.putExtra(Serializable..) and Intent.getSerializableExtra() to send and retrieve PopMessage objects. Here's the basic skeleton of the PopMessage class:

public class PopMessage implements Serializable {

      private String sender;
      private String body;
      private long timestamp;

      // getters and setters go here
      // ...

     /**
       * Utility method
       * Display a shorten, more user-friendly readable date from the original timestamp
       */
     public String getShortDate(long timestamp){
          Date date = new Date(time);
          Calendar cal = new GregorianCalendar();
	  SimpleDateFormat sdf = new SimpleDateFormat("E MMM dd hh:mmaa");
	  sdf.setCalendar(cal);
	  cal.setTime(date);
	  return sdf.format(date);
     }
}

Now we need to pass our SMS message around. We do it at the end of our Receiver's onReceive() method:

public class SMSReceiver extends BroadcastReceiver {

  @Override
  public void onReceive(Context context, Intent intent) {

   // code to capture sms goes here
   // .... see Part One

   // construct a PopMessage object
   PopMessage pop_msg = new PopMessage();
    // populate with timestamp, SMS sender & body using the setters here
    //...

    // start a new task before dying
    intent.setClass(context, PopSMSActivity.class);
    intent.setFlags(Intent.FLAG_ACTIVITY_NEW_TASK);

    // pass Serializable object
    intent.putExtra("msg", pop_msg);

    // start UI
    context.startActivity(intent);

    // keep this broadcast to ourselves
    //abortBroadcast();
  }
}

The last line of code has been commented out, and needs further thought, because when we abort the broadcast, the other receivers (like the default SMS program on the phone) don't get a chance to handle the same event. Why would we want to abort the broadcast? Because otherwise we would get two notifications on the same SMS message, ours and the default mechanism. That can be annoying to the user. Remember how, in Part One, we set an arbitrary high number (999) to our SMS intent-filter in the Android Manifest:

 
<!-- Incoming SMS messages can be intercepted by the SMSReceiver class --><
<receiver android:name="com.ts.pop.sms.SMSReceiver">
   <intent-filter android:priority="999" android:exported="true">
      <action android:name="android.provider.Telephony.SMS_RECEIVED" />
   </intent-filter>
</receiver>

By setting a high priority and aborting the broadcast after getting the SMS messages, we effectively hijacked them. But that is a problem if our program is not actually a full replacement of the system default one. In this particular case, one thing we lose by aborting the broadcast, is SMS storage in the inbox. All we do is a display in a popup window, but, when we close that window, there is no trace of that received message in our inbox message threads. The SMS popup program we are writing is merely an add-on, not a full replacement of the default program with all its features.  So we need to be extra cautious when using abortBroadcast(), and consider the positive as well as the negative.

And we're done with all the background processing in our SMS BroadcastReceiver. Now, we're ready to tackle the UI with the Activity class. In Part Three.

Source: Tony's Blog.