Push Notification to Mobile Devices via SMS – Part 2

To implement push, let’s start by sending the SMS that will be the notification that the mobile device will receive. To do that, we will use the free SMS service from ZeepMobile. Doing a search for “ZeepMobile C#” results in a match to AboutDev’s Weblog. He has already done all the heavy lifting of writing a managed wrapper around ZeepMobile’s SMS API. I rearranged the code slightly so it is easily reused.

Here’s the code sample from my ZeepMobile managed API:

ZeepMobileClient myClient = new ZeepMobileClient(API_KEY, SECRET_ACCESS_KEY);

private void mySendButton_Click(object sender, EventArgs e)
{
    if (string.IsNullOrEmpty(myUser.Text) || string.IsNullOrEmpty(myMessage.Text))
    {
        MessageBox.Show("Please enter a user and message");
        return;
    }
    myClient.SendSMS(myUser.Text, myMessage.Text);
}

Ok! Now, let’s hook up the SMS notification to my blog. The iframe below is hooked up to a ASP .NET application that uses the ZeepMobile managed API to subscribe a user and allow them to send SMS to themselves. First enter a user name to register on this blog, then follow the steps that show up to allow this site to send you SMS through ZeepMobile:

You should be able to use this site to send SMS to yourself. Next step, intercept the SMS on your phone and handle it. More to come in a later post!

Click here for the code used in this tutorial. The code sample includes a standalone Windows Application that allows you to send SMS to your phone (once you get a free API key with ZeepMobile).

“Push” Notification to Mobile Devices via SMS

One of the questions I seem to get on a frequent basis is “How is push notification implemented?”. Push notification is extremely useful for mobile devices; whenever there is a power constraint, typical polling/pull approaches will tax the device’s battery. Some examples of Push vs. Pull:

Push

1. ActiveSync
2. Gmail on Android

Pull

1. IMAP/POP3 email (user configurable polling interval)
2. Twitter Clients (which checks Twitter periodically)

The obvious problem with polling cycles and pull is that the phone needs to come out of sleep/power save periodically and poll the server for messages: and there may be none waiting! For example, if you set a 5 minute email check interval on your Windows Mobile phone’s IMAP/POP3 account, your battery will be dead before the end of the day.

As far as I know, there are two ways to implement Push notification to a mobile device:

1. Persistent TCP/IP Connection: Ideally the server would initiate the connection to the phone, but most phones do not have a static IP address available to them. Thus, generally, the phone initiates and maintains the connection. I know that actually maintaining a connection indefinitely will also drain the phone’s battery quite quickly due to a constant stream of keep-alive pulses. I’m a little hazy on the details here, but I have read that ActiveSync actually utilizes connections with a 15 to 30 minute time out to get around this problem.
2. SMS: This is the ideal way to implement push, as the client only gets notified via SMS when there is something new on the server. Beware potential SMS costs that may be incurred.

 

Setting up SMS Interceptors

So, how does a developer use SMS to to implement a custom push solution? Well, first, the phone needs to set up an SMS interceptor: you don’t want to be sending protocol related SMS to the user’s Inbox!

Android: Register a receiver that watches for the android.provider.Telephony.SMS_RECEIVED broadcast.

Windows Mobile: Set up an Application Launcher for SMS events.

 

By way of SMS message prefixes, a developer can the specific SMS that are meant to be handled by the application. For example, a sample SMS in my custom protocol could be:

Koush: Poll!

By filtering SMS that begin with “Koush:” as they arrive, the user will never see them, and my application can utilize them to implement Push notification.

 

Sending an SMS to a Phone

There are several web services that allow you to send an SMS to a phone. Some free, some not. In the free category, I would recommend trying ZeepMobile. It’s easy to set up, and the API is straightforward.

 

Code sample and demo coming in a later post!

Samsung Mobile Innovator: A Step in the Right Direction

Windows Mobile developers that have used the Windows Mobile Unified Sensor API may know that painful reverse engineering process took place to add support for Samsung and HTC phones. This is because no phone manufacturer has released the internal API specifications for their device sensors!

However, Samsung recently released the SDK for their Light Sensor and Accelerometer on their new Samsung Mobile Innovator website. I don’t have a Samsung phone available at the moment, but the SDK looks pretty straightforward! And although it would have been ideal if Samsung had officially supported the Sensor API, this is a step in the right direction! A published API is better than no API. Hopefully HTC follows suit!

Here’s a snapshot of the managed bindings that were included with some of the SDK sample code:

namespace SamsungMobileSdk
{
    public class Accelerometer
    {
        public struct Vector
        {
            public float x;
            public float y;
            public float z;
        }

        public struct Capabilities
        {
            public uint callbackPeriod; // in milliseconds
        }

        public delegate void EventHandler(Vector v);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerGetVector")]
        public static extern SmiResultCode GetVector(ref Vector accel);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerGetCapabilities")]
        public static extern SmiResultCode GetCapabilities(ref Capabilities cap);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerRegisterHandler")]
        public static extern SmiResultCode RegisterHandler(uint period, EventHandler handler);

        [DllImport(Shared.SamsungMobileSDKDllName, EntryPoint = "SmiAccelerometerUnregisterHandler")]
        public static extern SmiResultCode UnregisterHandler();
    }
}

I’ll be adding support for the official Samsung API to the Sensor API shortly.

Back from Hawaii!

The deafening silence for the past week on my blog was due to my being in Maui! It was a great trip overall.

High point: I swam with a 4 foot long sea turtle.

Low point: I let someone convince me that the Road To Hana was a good idea. I am pretty sure that Road To Hana is actually the largest man made fractal. Here’s my artistic rendition:

The scenery and such is unbelievably beautiful, but not even that can offset the nausea that sets in after the 300th hairpin turns on the highway. Here’s an actual satellite image of a typical 1 mile stretch of road along Hana (tile this image 40 times for actual representation):