Android read sms inbox fields

Android | Wednesday March 30 2011 23:41 | Comments (0)

While I was doing some work on an android app (possibly related to my previous post ;)) I came across a problem. Google don’t seem to want people messing with their SMS inbox, for whatever reason, so have decided to put as little documentation on their site as possible.

So, in order to retrieve data from an SMS inbox you need 3 things:

  1. The URI of the inbox
  2. A Cursor to traverse the texts
  3. Some idea of what fields will be returned by the cursor.

After some Googling, I have found that most people use the inbox URI like so:

Uri uriSms = Uri.parse(“content://sms/inbox”);
Cursor c = getContentResolver().query(uriSms, null,null,null,null);

I have tried this and it works, if you want to retrieve the texts that people have sent you, but not for ones you’ve sent.Here is the complete list of URI’s for SMS.

All: content/all
Inbox: content/inbox
Sent: content/sent
Draft: content/draft
Outbox: content/outbox
Failed: content/failed
Queued: content/queued
Undelivered: content/undelivered
Conversations: content/conversations

Others have said online, this is not the best way to do it. You can also use the built in SmsManager class but I haven’t had time to look at that yet. Hopefully its easy enough to use.

Next up is the cursor, which is easy enough, and is used as follows:

Cursor myCursor = getContentResolver(UriSMS,null,null,null);

The 2nd “null” here is for the fields you want to retrieve. Putting “null” is effectively like saying “SELECT * FROM inbox”. We can specify other fields to retrieve like “body” or “date” or “person” but what I had trouble with was actually finding documentation on which fields are available.

Which brings me to my 3rd point. There is a built in method on the cursor that can return the name of each field. Using this, I’ve made a list of what fields can be retrieved from the outbox.

Starting from myCursor(0) to myCursor(15):
0: _id  (long)
1: thread_id   (long)
2: address   (String)
3: person   (String)
4: date     (long)
5: protocol
6: read
7: status
8: type
9: reply_path_present
10: subject    (String)
11: body    (String)
12: service_center
13: locked
14: error_code
15: seen

So there ya have it. Some basic SMS retrieval info. I might update this when I look into the SmsManager class in more detail.

C ya.

Double Snap!!

Android,College | Saturday March 26 2011 14:44 | Comments (0)

As with everything in the world of IT, ideas move fast! And they get replaced with ideas even faster.

About 5 minutes after I posted my last blog entry, I joined up with another group of programmers, who are making an app. Its a good idea for an app, and I reckon it should be good experience and look good on my CV.

With this app, there is scope to market it, in cooperation with some marketing people who have expressed interest in it. Also, we will be entering it in a competition, sponsored by Vodafone, called App-o-vation. The winners of this get backing from Vodafone, who will then distribute it through their channels and make it available through their web store.

I can’t give too much away, but put simply…..watch this space!!

Snap!

College,Mobile Development | Thursday March 24 2011 10:33 | Comments (0)

So, after some further research into making a RESTful server on the Android, I have decided to make a game of “Snap” instead!

There’s a few reasons for not making the RESTful server, mainly that it would take too long to code, and I have a deadline next month for it to be submitted, which simply isnt long enough for research, design and coding, as well as testing.

So, enter “Snap! for Android“. A cool little 2-player game to test your skill and reflexes against either the computer, or another human player. So far I just have the basics, ie Main menu with a “New Game” button, that loads 2 “snap” buttons and a random card. Expect some code samples, screenshots, and possibly a beta (or alpha) soon.

Meanwhile, I must get back to making my iPhone app too…..

A little side project

Android,College | Tuesday March 8 2011 00:16 | Comments (0)

Following on from my last post about RESTful services, I’ve recently gotten an Android phone (HTC Desire) and have downloaded the Android SDK to have a little play around with it. I’ve managed a simple “Hello World” app, but nothing more yet. I have another subject in college that deals with mobile computing where, as part of our grade, we have to develop a smartphone app.

As it stands, to test the project, there will be a need to commandeer either a college computer, or bring in my own laptop to demo the server backend, but ideally I’d like to combine both the year long project and this other mini-project and create a server on an Android phone, which is capable of running a RESTful service and spitting out XML to be consumed by the iPhone, or indeed any client running on the network that is capable of displaying Google Map data.

So, this would be handy for 2 reasons:

  1. I always have my Android phone on me.
  2. I wont need to bring my laptop to college.

If this is possible, it would really look good on my CV, and would probably be something that would get a lot of downloads on the Android Market….which would nicely pad out my CV more, and kick start my portfolio, which at the moment is depressingly empty!! 🙁

However, if its not possibly, or feasibly for someone with basic knowledge, such as myself, then I suspect a little game of SNAP on the Android might be “on the cards…”!

RESTful services, XML and JSON

College,Mobile Development | Tuesday March 8 2011 00:07 | Comments (0)

As this project has gone on, as expected, we have been adding features. So far, along with the core bike rental system features, there is now plans for LUAS integration, a map of secure bicycle lock-up facilities and possibly cycle lane support too.

As all the info relating to the bike stations (availabile number of bikes, location etc etc) is retrieved from one location, there will be a need to create another data source containing the info for these new features. As its only a college project, proof of concept is only needed, meaning the data does not have to be correct, it just needs to work, and pull back some info, be it dynamic or static. However, if some new official, correct, data source was found, simply changing the location to where the parser is pointing would then make it a fully functional, accurate piece of software! Until that day comes, a customised backend running a RESTful service will have to suffice.

Lets take the secure bike lock-up facility as an example here. There are no known (to me) sources at this time that contain the locations of any bike parking facilities, so for the purposes of this project, these locations will have to be fabricated. This will be done by storing mock coordinates in a data source (which I’ll get to in a minute), then writing a RESTful web service, most likely in NetBeans, which will run off glassfish server, and serve the results in either XML or JSON format. I reckon XML will probably be best route here, even though, as far as I know, there is built in support for both formats in NetBeans/glassfish. I’m not sure if there are any performance gains in choosing JSON, but looking at the raw data from both, the XML seems a lot more readable with its tags, so I’m hoping its a lot easier to parse. Although, going back to what I just said a few lines back, there is built in support for both so I think either option is the same at the high level NetBeans deals with it. Feel free to correct me in the comments if JSON performs better.

Keeping with the XML line here, we will need to store these coordinates somewhere. For peace of mind, and transparency of functions, it is my opinion that storing the details of the bike lock-up facilities in an XML file will make it a lot easier to read (for humans at least) by having matching tags in the data source and the XML data produced by the server. We also have to take into account what the iPhone can handle. This whole RESTful service thing is something I’ve only been looking into for a matter of days, hence why I’m unsure about performance vs XML files, so I’m also unsure if any differences exist between how the iPhone will handle XML and JSON when parsing them and storing the coordinates as arrays of strings, so for arguments sake, and to keep in line with the rest of the project, XML will what I will be focusing on, except if I discover JSONs performance gains far outweigh XMLs, as above.

So, after a few minutes playing around with this, I’ve managed to get my own server running, and it was surprisingly easy! Luckily enough, as you know, Java is pretty popular, as is NetBeans, so there is plenty of documentation online. For example, the easiest, most straightforward guide I found is here: Getting Started with RESTful Web Services from the netbeans.org docs. In 10 minutes flat, you can have your own server running, complete with a sample database, serving out a choice of both XML and JSON, which works perfect on Firefox, Internet Explorer, even an Android phones stock browser….but unfortunately not Google Chrome. But as far as I know, when using the UIWebView in the iPhone SDK, the iPhone uses the Safari renderer to display the Google Maps themselves, rather than some Google provided solution, ie Chromiums renderer, so this browser incompatibility shouldnt be a problem….hopefully. I’ve no idea what the case is when using MapView in either iPhone or Android, but I’d imagine its some sort of JVM solution so should be fine.