Some years ago, I put together a suite of applications which form a support call logging and admin system for my company's technical team. This suite includes PC & Mac standalones, Web services and lately, Android and iOS apps. Everything is written with livecode and the whole thing has proven to be extremely reliable. Every element 'talks' to each other and all users know exactly what's going on at all times.

When my company decided to upgrade our mobile phones to iOS devices, push notifications promised to add some icing to the cake and improve response times so, with a little time over the holiday period, I set about learning how it works and putting something together to make it a reality.

 

There is no sense in recreating the wheel, so I did not create my app from the ground up, rather, I based it on the push notification elements of APNs Assistant from Splash21.
Naturally, I had to modify it to suit my purposes but my manual notification is literally pulled from APNs Assistant scripts and the auto system is largely a wrapper around that , grabbing data from server pages, deciding what to do with it and then using the APNs Assistant scripts (with the help of libJson) to send the actual notifications. You can check out this great free resource here.

First thing I found out was that push notification for iOS is not a trivial thing to do but, as anyone who uses Livecode will know, lessons from the 'mother ship' and Livecode support forums are an amazing resource so I soon had a checklist of what had to be put into place.

• Push notification certificate for the app – created via the Apple Development site. There are actually 2 certificates which have to be bundled together. I did this manually but APNs Assistant.livecode can simplify the process
• Get the list of device ID's which want to receive the push notifications – in my case I used the pushNotificationRegistered message in the iOS app to post the mobileGetDeviceToken to a Livecode server page which in turn, populates the ID to a database table. My push notification server will find it easy to access this table
• Determine when and what to push to the mobile devices – in my case, a simple server page which finds unallocated requests in an existing database table gives me all the info I need
  
• Convert the message to the expected format – libJson by Mark Smith does everything required and is another example of the generosity of livecode users
  
• Send the push notification – separate notifications have to be sent to each device so a repeat for the number of devices has to be set up
  
• Other necessities are – periodically check for new device ID's, regularly check for new requests, make sure that the device list is intact, only send notifications when a new request is logged on the system, set the badge number to reflect the number of outstanding requests, a facility to manually send extra notifications to one or all devices

The application polls the server page every hour to check if there are any new devices to be included in the list. It checks for the number of outstanding requests every minute and compares this number with the last number. If it is greater, there must be a new one so the badge is set to the total number of requests, the message is set to reflect this and the push notification is sent to all devices. Really simple.

I found it convenient to use a Mac to develop the application and soon had everything working well as a Mac standalone but, as I needed this to be functioning 24 7, I did not want to use up my only Mac. I considered doing it from Livecode server but preferred to have it running locally and that's where the Raspberry Pi came in. It's cheap, small and Livecode supports it. While it is possible to load livecode on a Raspberry Pi and build the application on that, I preferred to use the Mac and just build the standalone for Linux ARMv6-HF. This works really well.

So I now had a fully functioning push notification server, running on a Raspberry Pi bolted to the back of a monitor on my wall. Trouble is, it looked really boring and the holiday period wasn't over yet so I set about blinging it up with a nicer UI. I'd found on the internet a set of Photoshop brushes which creates elements for a heads up display and, having just watch a sci-fi film, decided on a look as if viewing the Earth from a spaceship. A background image of the Earth horizon overlaid with the HUD gives the basic look. All elements of the application are made transparent and moved into position over the HUD elements. The server on/off button becomes a HUD element which changes colour to indicate its status and a nice spiral element appears every time the server checks for new entries. Extras like the total number of server polls add extra data to the HUD elements.

Finally, just because its so easy to do, every time a set of notifications are sent, the spaceship Enterprise flies across the background (an image following a path) The layer level of this image is set below the HUD to make it a bit more realistic and the passage time was adjusted for an effective look on the Raspberry.

Totally over the top for this kind of back office application but as it's on full view on the wall of my 'toyroom' it's much prettier to look at. With the exception of some image editing in Photoshop, Everything was created using Livecode.