I’ve made a few interactives in the past that sent SMS text messages, but I only just recently was asked to make one that could receive them as well.  I decided to post this simple, little project that anyone can do as a way to share a few details I learned along the way.  It may be a useful overview to anyone else writing their own first two-way SMS app.  I don’t think I’ll talk a lot in actual code, because I’m pretty sure the code part of this project will be universally easy to anyone about to design a two-way SMS app.  This is more of a big picture overview for someone wondering what all the pieces are.  If you’re actually doing this and you get stuck on any code steps, feel free to email me and I can fill in the blanks.

The project: We’re going to make a simple Shockwave app that will receive SMS text messages from anyone with a mobile phone and then display them on a web page as they come in.  Sound fun?  I know, but it will walk us through all the minimal steps involved in making a two-way SMS application.  Once those are in place, there’s bound to be something fun you could do with them.  Maybe.  Anyway, we’ll begin with…

The part you can’t do: This’ll be the step that slows you down if you’re following along at home.  Unless you are a mobile network provider with lots of expensive telecommunications equipment, you can’t actually receive text messages and convert them into recognizable data.  So if you’re building a two-way SMS application, you’ll need to hire a service that will do that part for you.

There are essentially two ways that the computer running your application can receive an SMS text message.  This project will focus on one, but make passing reference to the other as we go.

The first thing you could do is put a physical GSM/GPRS modem in your computer.  A GSM modem is essentially a mobile phone.  In fact, the mobile phone in your pocket probably has the ability to act as a GSM modem, given the right cable and software.  Or you can buy an internal or external GSM modem.  These can send messages a lot faster than your phone, but that probably won’t matter for an interactive exhibit.  The phone in your pocket may also give you issues with concatenated or multimedia messages.  For an actual exhibit, you’d probably want a proper modem.  For this project you could use your phone.  Remember, too, that a GSM modem obviously needs to be located in an area with GSM signal.  So, you know, think about where and how your exhibit will be deployed.  With a GSM modem you need a SIM card, just like your mobile, and the SIM card needs a service plan, just like your mobile.  But I’ll gloss over the details of that, because that is not the method we will use in our project.  (I’ll try to point out the differences as we go, though, so you can use that method if you already have those pieces handy.)

The second method is to lease access to an SMS gateway from a service provider.  And unless you do a spamtastically high volume of texting, you can’t afford to get your own SMS gateway from a wireless carrier.  So you use a service that enables several customers to share one.  There are lots of those and lots of things to consider and I could say lots about that.  But I won’t.  Because it’s really boring.  I said the part where there are lots of them, the other part worth saying is that it’ll probably cost you 3 or 4 cents-ish per message, some variables depending.  You can email me if you want to know anything more I learned about that.  For our project we are going to pretend you chose clickatell.com, because, well, my client chose clickatell.com.  (That, btw, isn’t a formal, qualified endorsement of clickatell.com.  I wasn’t too involved in this part.  My client wasn’t actually a museum but a rather large non-profit with a rather noble-sounding mission and I’m given to understand that this lead to generous terms.  Somebody on their board knew etc dot dot dot.)  You may choose who you choose and it will end up being very similar to this.  I can say that clickatell.com is very developer-friendly with excellent docs and APIs.

Service that permits two-way SMS is different than using a gateway service just to send.  Your provider will offer both plans.  You need 2-way.  Which means you need a Virtual Mobile Number (VMN: an acronymic way of saying that you have a number for people to dial, but no corresponding phone or SIM card.)  You have to apply for this and it can take a couple of days to come through.  This process includes you accepting liability to the tune of 4 cents-ish a pop for incoming messages to that number.  (I’m not sure what if any built-in safeguards are available in terms of not accidentally getting a much higher bill than you hoped.  I’ll edit this post with that info when I track it down.  Incidentally if you’ve wondered why this page doesn’t have a working demo version of the completed project, that’s why.  Sharp-elbowed, snarky blogs may tempt four-cents-a-whack revenge bots.)

Thank god that’s over. Still with me?  Probably not.  That’s not necessarily curious hobbyist-friendly, but… let’s pretend.  (You’re welcome to make your phone into a modem if you’re that determined to join in.  Go download a driver.  If you have a Motorola RAZR V3m like I do, it’s here.)  Now you have an account that will receive SMS text messages and deliver them to you any which way you like.  For simplicity sake our project is going to get them as GET data via http.  Doesn’t get simpler than that.  (How do we do that, you ask?  In my case, you tell clickatell.com where to send what and how every time your VMN receives an incoming message.  Be sure you look into APIs and available formats when you pick your service.) So let’s begin, shall we, with a visitor sending an SMS message to our Shockwave app and talk about each of the pieces we will need to build to handle it along the way.  So:

A visitor types a text message and sends it to the number that matches our app.

An expensive magic box at clickatell.com receives the message for us and sees that we have asked them to immediately send GET data via http to…

The first PHP script that we have written and placed on our web server: In the simplest short hand, this script takes GET data from clickatell.com creates variables and inserts them into a MySQL database on our server.  Just like it was sent from any html form.  In our project we are only concerned with the message string.  Our example MySQL database could be a simple three-field table with a primary key id, a datetime stamp, and the message text.  When the message comes from clickatell.com, our script makes a message variable, tidies and parses it, and inserts it as a new row in our table using the current time on the server as the datetime stamp.  That’s it.

Meanwhile elsewhere on the same server: There is our Shockwave app.  When a visitor opens a webpage that loads the app, it first makes a variable of the current server time.  Let’s call it checkForMessagesSince.  Then every x seconds (10, say) it asks a question to…

The second PHP script that we have witten and placed on our server: In the simplest shorthand, this script takes the checkForMessagesSince variable as POST data from our Shockwave app, creates a variable for $checkForMessagesSince and uses that to query our same database.  It asks for all the messages received since that time and gives us back only the oldest message received since then.  Then, as XML, it tells us two things: the message text string and the datetime stamp that matches it (or NULL as the case most often will be.)

If our Shockwave app hears NULL, it does nothing at all but continue to ask.  If our Shockwave app hears a string and a datetime, it does three things.  First it makes a variable for each.  Then it echoes the message text (Um… tada!  That’s the show, folks. Your text mesage on a webpage.  All this for that?  But it’s a variable now.  Your real app will think of something cooler to do.), and resets the checkForMessagesSince variable not to the current server time, but to the datetime from the message it just echoed (so none will get skipped.)  Rinse.  Repeat.  You may now text your exhibits.

(Of course, if you decided to play using a GSM modem, you have a little additional work, no?  You only get half of what we clickatell.com folks get.  You get a message from the mobile network, but you don’ get the neatly parsed and formatted results submitted as GET data to the URL of your choice.  If your exhibit is local/gallery (meaning non-internet) you can receive this message as serial data under a number of protocols using the syntax and commands for your device.  That’s even easier, in theory, than our project above.  Get data, parse data, show data.  But I’ll bet you can’t do the get data step without google.  I can’t and it’s boringer than the scope of this blog post.  Your modem will support AT commands, if it helps to consider that.  If your exhibit is web-based, you have one more step.  You have to be your own clickatell.com and send the nicely-formatted data as GET your damn self to the aforementioned script waiting for it that way.)

Cool, huh?  But, wait!  For the hobbyest of hobbyist, there is one last method-ish.  A clunky but SMS-service-less and, therefore, FREE cheat.  With almost every contemporary phone, you can pretend to be SMS-ing when in reality you are using email as a transport.  (I’ve actually used this cheat for a low-end send-only prototype.  Two-way adds a tricky step, but in untested-by-me-personally theory, it’s totally feasible.)  You see, almost all major carriers provide this service to their customers.  I can email your phone and your phone company will send it to you for me as SMS.  Or you can SMS my email address and your phone company will send it to me as email.  If you want to cheat-SMS an AT&T/Cingular customer, for example, simply send an email to 5555555555[their 10-digit number]@text.att.net and they will receive it as SMS.  (T-Mobile is 5555555555@tmomail.net.  Verizon is 5555555555@vtext.com.  Nextel, Sprint, and Virgin are @messaging.nextel.com, @messaging.sprintpcs.com, and @vmobl.com.  You can look up others.)  For the same matter, any of those customers could send an SMS message to yourexhibit@yourmuseum.org and the phone company will give it to you as email.  Now you’re left with an email that you need to write a reliable parser for.  (Bet you’ll be debugging that for a few hours.)  That’s wonky for a hundred reasons I needn’t point out, but it works.  And I just saved you four cents.  You can owe me.