Project Progress Update

College,Mobile Development,Python | Thursday April 14 2011 14:11 | Comments (0)

I just realised I havent updated my project progress on here in a while, and since this is the reason I actually made this blog, I thought I better do so now.

So, as of this moment, I have every single bike station in Dublin being populated onto the iPhone UIMapView. I also have a dummy set of coordinates for places to lock your bike up, once you rent it. Additionally, I have all the LUAS stops appearing on the map. This was super tedious, as I had to manually get the coordinates of each stop from Google Maps, which took me about 3 times to get them right since Google Maps decided to give me the wrong coordinates, only to be discovered when I consumed the XML data and populated the map. I created the XML file by hand too!

I also have details of individual stations/lockups but not LUAS stop, as I’m currently trawling through the BeautifulSoup documentation to find a way to convert HTML into XML/JSON so as to be readable from the existing code. Once I figure out how to strip <div class=”xx”>xyz</div> so as to keep the xyz part, I should be good to go!

The public server is up and running too. I set it up using Django as the server, using a RESTful service to expose each “view”. My views are written in Python, which I am starting to like a lot. Its a very powerful language!

Also, since there are about 42 bike stations, lots of lockups, and about 50 LUAS station, getting the nearest station is going to take ~50 requests to the Google Maps server. I will need to implement some sort of client side “coordinate maths” to actually get the closest, then send that to Google, and return the directions. Google imposes a “2500 request per day” for non-premium users. Since the server is actually using shared hosting, I think it filters by IP. Usually I get one try, and then the limit is used up. As its only a school project, I’m not too worried about this. Obviously if it was going public, I’d actually pay for a dedicated IP! I have other hosting with an Irish company, but unfortunately I don’t think they do Python/Django hosting.

So, on my TODO list:

LUAS: Get individual station details (in JSON)

Directions: Figure something out client side for measuring coordinates

Custom start point: As a follow on from the “Directions”, the user should be able to choose a start point, other than their own, and get directions from there to the “nearest” station/stop.


So, not much to go. The beta is due up tomorrow, then I have a couple of weeks to polish it off. I also have that Android app to develop too…

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… this space!!


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 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.

Google Maps API – Intro

Android | Wednesday February 9 2011 16:44 | Comments (0)

I’ve gotten down to the nitty gritty of actually making an app that uses Google Maps, which means finally trying to get a map on the screen and at least pick up my location automatically.

To get a basic Google Maps app up and running, its surprisingly easy! Yes, to just have the app pinpoint your location using GPS, its shockingly simple! The reason for this is that Google have done all the hardwork for you. All we, as developers, have to do is call the javascript file on the Google servers and hey presto. For example: Geolocation test . Yes, its that easy, providing you have internet access, obviously! The source code, if needed, can be found here: Maps source

In case you’re interested, there are lots of examples on Googles website here: Google Map Examples

So, now we have a basic application that detects the users location and centres the map on it. However, as you can see in the first link above, the zoom level is a bit too high. Also, we will want to add markers on the street corresponding to the coordinates of the bike stations, or whatever place of interest you’re intending to map. This is more complicated and will be covered in the next section! 😀

Brains! Delicious Zombie Brains!!

iOS | Wednesday February 2 2011 16:04 | Comments (0)

When developing for the iPhone, you have to be aware of its memory limitations. For example, the original iPhone had 128mb of RAM, the iPhone 3GS has 256mb RAM and the iPhone 4 has 512mb RAM. Its all well and good to develop solely for the iPhone4 and use a lot of memory, but then that excludes anyone with an older handset.

Also, take into account that the iOS (iPhone Operating System) itself will use up a sizeable chunk of that memory too, and then you’re left with about the same amount of RAM that, say for example,  a Windows 98 PC would have had! iPhone4 specs are 1Ghz, 512mb RAM so maybe a high end Win98 machine! FYI, the iPad is similar specced to the iPhone4, eg same CPU but only 25mb RAM!!

So, what I’m trying to say is, Memory Management is important. Even more so with the limited resources found on mobile devices, like the above Apple products, and also Android phones and the new Windows Phone 7.

We saw in a previous chapter on Memory, Constructors, Destructors, new, alloc and init how to create objects, allocate space in memory, and initialise them, so you should be familiar with that concept.

Now, thats all well and good, but what the hell has that got to do with Zombie Brains???

When debugging, we can use a feature of XCode called “Zombies”. If we allocate space and release it, as we should since we’re such good programmers, then if we have a momentary lapse of concentration and continue coding somewhere else and try make a function call on this object, which has already been released, then we should expect and error. The problem here is, XCode will only give a very general error, eg “objc[123]: FREED(id): message release sent to freed object=0x213d2” or something similarly cryptic. If you are developing a large program with a lot of code, its pretty hard to pinpoint the exact object that you released earlier and subsequently made a call to.

With Zombies enabled, you will be able to find out what type the object was, so that will narrow down the search to a smaller area of code. It will tell you this with an error message similar to this:

NSInvocation: warning: object 0x1234f of class ‘_NSZombie_myClass1‘ does not implement….blah blah blah

The bolded part is the important part. You can focus your search on objects of that type only. It might not make a big difference on small apps, but on large ones, it will save a good chunk of searching!!

So, how do you enable Zombie mode?

On the left pane in XCode under “Groups & Files”, scroll down to “Executables” and expand. Double click on your app name (or right click-> Get Info) and when the new windows pops up, make sure you’re in the “Arguments” tab. Now, in the bottom box where it says “Variables to be set in the environment”, click the “+” button to add a new entry. Type in “NSZombieEnabled” and give it the uppercase value of “YES”.

Congratulations, you now have Zombie Brains in your code!!

SQLite – Database Intro

Android | Wednesday January 26 2011 17:56 | Comments (0)

Since I finished my exams last week, I’ve began working on a little small personal project. In my research for that, I’ve come across SQLite.

For those of you not familiar with it, SQLite is basically a really light database, built in C, that doesnt require its own server, thus requires no installation of any kind. You can literally just include the database file and not have to worry about anything else.

Using Visual Studio 2010, you can do one of two things:

  1. Get the installer from that automatically integrates with Visual Studio, or
  2. Download the SQLite DLL and add it as a reference in your Project Solution.

The first option is probably easiest, as you can use Visual Studio to create and edit the database through Server Explorer, eg right-click on Data Connections, select New Connection and select SQLite.

The second way, you will need to get 3rd party software to create and edit the database. Of course, you’ll probably be writing software that does edit your database, so you just really need the DB created initially. I’m not sure if it can be edited within Visual Studio, but I could be wrong, as I was using the first method in my testing.

SQLite is really handy for small projects, and portable projects, and in fact, is probably the most widely used database in the world!! Firefox uses SQLite, iPhones use SQLite, and probably a lot of other mobile platforms like Android might use it too! This isnt even taking into account all the private projects developers use it for, and a lot of other personal projects, like mine! With Firefox and iPhone alone though, it still covers a wide user base!

Anyway, to tie in with my college project, I’ve decided that SQLite will be the official database technology of the iPhone app. I’ve used mySQL before so have experience with using SQL statements and SQLite uses most of them, with the exception of GRANT and a few others that I won’t be using anyway!

Is there a better database solution than SQLite for lightweight, portable, speedy applications? Let me know…


Memory, Constructors, Destructors, new, alloc and init

iOS | Wednesday December 22 2010 13:44 | Comments (1)

Quite the catchy title, eh??

I have been looking into some memory management techniques in Objective-C. I’m used to the way C/C++ and many other languages do it, by using the “new” keyword.
In Objective-C, this is done differently.

While you CAN declare a class variable like this:

myClass *object = new myClass;

it is not the most common way. Instead, its more commonly seen like this:

myClass *object = [[myClass alloc] init];

The “new” keyword allocates a space in memory to hold the object. It then initialises it, probably with a constructor and can give variables a default value. So thats 2 things it does. Allocates and initialises. In Objective-C, these are done independantly.

Also, note the nesting of the square brackets. Its making 2 calls, but just doing it in a more readable way.

I mentioned constructors above, and I’ll show you now how to pass a variable to the “constructor”.  Note, I don’t think they’re actually called constructors and destructors outside C++, but just go with it anyway…. 😉

So, in C++, you would create an object and initilise some string/variable like so:

myClass *myObj = new myClass(“Hello World”);

In Objective-C:

myClass *myObj = [[myClass alloc] initWithString:@”Hello World”];

See how we are initialising with a string? This can also be done with contents of a file or URL, as well as many other options (In XCode, press ESC to see a list when it prompts for auto-completion). For example,

myClass *object = [[myClass alloc] initWithFormat:@”Hello, my name is %@ and I am %d years old”,name, age];

Obviously you also need the back-end to handle these initialisations.

Autorelease Pools

Lets say you create an object that contains a method which in turn creates a new object called myAddress, assigns it a value, then return this value, eg “return myAddress”. You will obviously have to release this object to obey proper memory management rules. Since you need to do your tidy up before calling the “return”, how can you destroy the object but still use it on the next code line without getting a compile error? In Objective-C, we use [myObject release] instead of “delete myObject” like in C++. For example, in C++ pseudocode:

myClass *obj1;
myClass *obj2 = obj1.returnAddress();

myClass obj1::returnAddress
myClass *myAddress = new myClass("123 City Road");
delete myAddress;
return myAddress;   // Will cause error

So, instead of delete myAddress, Objective-C would read [myAddress release]. Now, stay with me here for a minute while I explain the answer to this problem! Objective-C has the “Pool”, which is like a queue of objects that need to be deleted. When you release an object, it gets deleted straight awat. Now, if you use the “autorelease” keyword in place of “release“, you’ll see some magic happening. You see, autorelease puts the object into the pool for deletion but indicates that its still needed for the moment. The Pool will simply wait a few milliseconds and then just go ahead and delete it. The thing here that I am uncertain about is if it just takes a guess and deletes it whenever, or if it watches the object to wait until it goes out of scope. I’d imagine the latter is how it happens, but I’ll need to look into it. Here’s the corrected code in Objective-C(note the return type in the brackets):

-(myClass) returnAddress
myClass *myAddress = [[myClass alloc] initWithString:@"123 City Road"];
//[myAddress release];    // Will cause the return statement to crash
[myAddress autorelease];  // Works fine
return myAddress;


We saw above how to initialise data types in constructors, using the initi keyword. Now I want to quickly show you destructors.

The default destructor is always called “dealloc” and is also always predefined, in case you don’t supply your own. Since its already defined in the header file “Foundation.h”, in Objective-C we need to tell the compiler which one we want to use, so it doesnt get confused. This is done with the “super” keyword. See below:

-(void) dealloc {

// Clean up

[super dealloc];


And there you go!

« Previous PageNext Page »