On Saturday I was out and about with my family and found myself inspired to write an app. By Sunday evening, it was done and in the Google Play store.
We were in an area of Auckland called Parnell and needed to park the car on street, where a fairly standard “pay and display” system is operated. Since (I think) 2005 Auckland City (and some other parts of NZ) have offered TXT-a-Pay™ on their parking meters.
It’s a very simple system:
- You select TXT-a-Park™ as your payment method (rather than cash or credit/debit card),
- The meter then displays a menu of codes, corresponding to different lengths of stay.
- You send the appropriate code as a TXT msg using an SMS capable phone to the number 7275 (P-A-R-K),
- The appropriate fee is charged to your mobile phone account, and the meter then prints your ticket for displaying on your dashboard.
There is nothing particularly sophisticated about the system. The code that you TXT to 7275 consists of 4 digits that identify the particular parking meter, and the final digit is the $ spend for the indicated length of stay.
What has always bugged me about this is that smartphone SMS apps have become increasingly loaded up with features and the on screen keyboards ever more cramped with all sorts of great shortcuts for smileys and prediction and goodness knows what.
Which is great when you are TXT’ing a novel, or a love letter or trying to track down your kids. But when you just want a clean, clear, error-free way to whack in 5 simple numbers and send them to a specific SMS number, it can be a real PITA.
So I decided to write an app.
As soon as we got home later in the afternoon I set about it.
It turns out that on Android sending a TXT really is very simple. In fact, you can achieve it in a single line of code. For example here’s the Java for sending the code “66169” to the 7275 TXT-a-PARK™ number:
SMSManager.getDefault.sendTextMessage("7275", null, "66169", null, null);
Which effortlessly translates into Oxygene code:
SMSManager.Default.sendTextMessage('7275', nil, '66169', nil, nil);
There is a bit more involved if you want to provide a callback for handling confirmation of the sending of the message (or failure) and/or of delivery of the message.
But in essence, I simply needed an app with a UI to enter 5 digits and send them as a TXT.
And here it is (<drumroll />):
The app is called TXT-2-PARK rather than TXT-a-Park™ since the latter is a trademark in NZ.
I made things harder for myself by deciding that I would present my “message sent” confirmation using a custom layout for my message “toast” which turned out to be harder than I expected. I will post about that soon.
But, as I said, the app is now up in the Google Play Store. It is a free app, so if you are in Auckland or anywhere else that offers a compatible service (TXT a 5 digit code to 7275 in return for parking or whatever), then go grab it.
All In The Title
The title of this post is “Small Post, for a Very Small App”.
How small ? 22 KB + change. That’s how small.
That is the complete, fully functioning app including a UI which, although no work of art, does at least scale nicely (well, effectively at least) on devices from very small screens (240×320) up to phablets. Or at least it should do – I have tested it with a range of emulated devices as well as my own Galaxy S4 Active.
This small size means that the main goal of the app – convenience – is very well supported by the fact that it starts up and is ready to go instantly that you tap its shortcut.
Meanwhile I’m now working on an iOS version (for my wife, among others) and Windows Phone (for my work colleagues, among others).
Hi!
You can save the entered 5 digit number and the current GPS coordinates. The next time the user is within range of the parking lot they can select the previously entered number. Then make sure to distribute this info and no one will eventually have to enter any 5 digit number.
Sorry, make that a 4 digit number. And if you don’t like to make the app complicated with GPS and all, you can at least save the 4 digit number in a list for later use. People tend to park in the same locations from now and then.
GPS (on Android at least) isn’t complicated. I’m using it extensively in another app that I am currently working on. But for an app like this, it adds unnecessary complications for negligible benefit and in fact I think at significant cost, not just in complexity but also usability.
Adding pre-filling of 4 digits wouldn’t save any further time that the app already saves and would more likely actually make the process more awkward, not less due to the need to verify whatever has been pre-filled, completely negating the object of the app. 🙂
just a small curious question: this app is written with what devsystem?
I used RemObjects Oxygene for this app.
>There is nothing particularly sophisticated about the system. The code that you TXT to 7275 consists of 4 digits that identify the particular parking meter, and the final digit is the $ spend for the indicated length of stay.
Interesting. So what happens if you need to pay $10 or more? Or would that require such an excessively long stay as to be unrealistic?
Sorry, I wasn’t perhaps clear enough. Although the final digit indicates the $ cost, it does not directly determine it. There is a menu of valid codes presented by the machine, in which the final digit coincidentally corresponds to the cost:
i.e. you might be offered:
I’ve never tried submitting a code that might correspond to some other option not presented e.g. 66164.
From memory I also think that in some cases the final digit might correspond to the duration, rather than the cost.
The period of time covered by a given code may vary from location to location, but these are for “short/medium” stay parking. Longer term parking may involve charges of $10 or more, but these are not covered by TXT-a-Pay™ meters (there are other systems that provide a similar or even more convenient payment options in some cases, e.g. ParkMobile. But these operate by different means and typically have their own apps already, provided by the operator).