Blog

>A few days back, uAlertMe v1.2 hit the app store. This version added a browse function for setting up a bonjour connection to your Mac, plus a history of location in the map view. It also fixed a number of issues relating to the way uAlertMe stored images in your camera roll.

Since the release of v1.2, I’ve noticed a small (<10) number of crashes from the new version that seem to be happening when people try to use the new browse feature. I haven’t been able to reproduce them here, no matter what I do, but I think I can see what might be happening.

To this end, I’ve submitted v1.3 to the app store, which I’m hoping will address these issues.

If you are having trouble with uAlertMe, please use the support email address (support@pkclsoft.com) so that you can let me know what you were doing when you had the problem.

Likewise, if there are features you’d like to see, email me or post your suggestions here.

It’s done. I’ve just finished updating the webpages for uAlertMe, having submitted v1.2 to Apple tonight.

v1.2 brings with it a number of corrections that should address some stability issues that people may have been experiencing, especially on older versions of iOS, or on devices with large videos in their camera roll.

v1.2 also adds two new features:

When a location is sent to uAlertMe, it is now kept as part of a history, unless it is the same as a previous location. This way, you can see a history in the map view, of where your Macbook has reported it’s alarm going off. As a part of this, the annotations that popup when you tap a pin, now sport a button (right arrow) that allows you to navigate through the history, and an iAlertU icon that when tapped will retrieve the photo taken by your Macbook when the location was reported.

These pins may be deleted from the options screen if you desire.

Some people reported that it’s too hard to configure. As a step to help out with this, I’ve added a browse button next to the hostname field. Tapping this will cause uAlertMe to scan the local network for any Macbooks running iAlertU that have their internal server running, and configured to use Bonjour.

Any Macbooks found will be listed in a picker for you to choose from. If there’s only one, then it will automatically be put into the hostname field for you.

I hope that this version of uAlertMe proves to be more stable for those of you having had problems.

If you like uAlertMe, please review it in the app store. If you have problems, please, before you make a negative review online, contact me and I’ll try to help. As some people know by now, I’m very responsive to help requestes.

>It’s done. I’ve just finished updating the webpages for uAlertMe, having submitted v1.2 to Apple tonight.

v1.2 brings with it a number of corrections that should address some stability issues that people may have been experiencing, especially on older versions of iOS, or on devices with large videos in their camera roll.

v1.2 also adds two new features:

When a location is sent to uAlertMe, it is now kept as part of a history, unless it is the same as a previous location. This way, you can see a history in the map view, of where your Macbook has reported it’s alarm going off. As a part of this, the annotations that popup when you tap a pin, now sport a button (right arrow) that allows you to navigate through the history, and an iAlertU icon that when tapped will retrieve the photo taken by your Macbook when the location was reported.

These pins may be deleted from the options screen if you desire.

Some people reported that it’s too hard to configure. As a step to help out with this, I’ve added a browse button next to the hostname field. Tapping this will cause uAlertMe to scan the local network for any Macbooks running iAlertU that have their internal server running, and configured to use Bonjour.

Any Macbooks found will be listed in a picker for you to choose from. If there’s only one, then it will automatically be put into the hostname field for you.

I hope that this version of uAlertMe proves to be more stable for those of you having had problems.

If you like uAlertMe, please review it in the app store. If you have problems, please, before you make a negative review online, contact me and I’ll try to help. As some people know by now, I’m very responsive to help requestes.

When I first started on this game I thought it would be a simple matter of taking the ‘golf’ code and applying new photos, and a few changes to images.

Footy is a very different game to Golf in the real world, and this translated into the iPhone world as well, even with these game. What was originally going to be a simple task took on new life as the scoring, animation, game play, and general behaviour of the game changed to suit football as a game whilst still maintaining the original concept.

One simple example of this is the shape of the ball. A golf ball is spherical, and as a result it’s easy to wrap a texture around it to get a nice animation of the ball. No such luck with a football. I had to find a way to respect the shape of the ball, move it around the screen, and still use it effectively.

When I first started on this game I thought it would be a simple matter of taking the ‘golf’ code and applying new photos, and a few changes to images.

Footy is a very different game to Golf in the real world, and this translated into the iPhone world as well, even with these game. What was originally going to be a simple task took on new life as the scoring, animation, game play, and general behaviour of the game changed to suit football as a game whilst still maintaining the original concept.

One simple example of this is the shape of the ball. A golf ball is spherical, and as a result it’s easy to wrap a texture around it to get a nice animation of the ball. No such luck with a football. I had to find a way to respect the shape of the ball, move it around the screen, and still use it effectively.

OK, so as I’ve said previously, version 1.1 of uAlertMe added support for Push Notifications. All it needed was for iAlertU on the Mac to send them

Last night I released v0.74 of iAlertU which adds the required functionality for all of this to work.

Getting all this to happen was actually not all that hard; Apple have made it fairly easy for us.

Originally, iAlertU was going to act as the actual provider, connecting to Apple’s APNs directly. I had the whole thing working, with the entire push notification provider written in Objective-c.

The only problem was that doing it this way meant including my private certificate for the SSL connection to Apple in the iAlertU bundle. This as my conscious and several helpful souls pointed out was a great way to ask for trouble if someone decided to misuse that certificate (although I had gone to some lengths to make this harder).

So, the next step was to add to the pkclSoft web server a provider that iAlertU could then interface with. This all looked too easy as there is a great package called easyapns that does just this, and it would have worked fine except for one thing. My web host blocks outgoing connections on the ports that Apple use for connections to their servers.

This effectively killed my ability to use easyapns which was a shame, but there were other options in the form of Push service providers.

The first I looked at was UrbanAirship. They looked great, but there is a potential cost as only the first million pushes per month are free. Although I thought it unlikely that the users of iAlertU would end up using more than this, I didn’t want to take the risk; after all I get nothing for my time on iAlertU, and uAlertMe doesn’t do well enough to pay any bills.

So I looked for another alternative, and found Xtify who offer a straight out free service to developers. I then set out to spend the next couple of days getting iAlertU to talk to Xtify, but found that whilst their service was great, and the customer support was excellent, being able to send a notification payload that could be localised by uAlertMe so that the notification can be displayed in the appropriate language was too hard. Basically, Xtify get you to send a payload in their format that is then translated into Apple’s format. This just wouldn’t work.

Back to UrbanAirship for me. Whilst they do something similar (so that you can send a single push to both iOS and Android devices) to Xtify, their interface is much more natural, better documented, and supported by packages of code that are easily obtainable via their website.

What about that cost-risk? We’ll I’ve decided to test the waters so-to-speak. I figure that with only a few thousand users out there, and that normally, the only time the push will happen is when the alarm goes off, people would have to be triggering their alarms hundreds of times per month. Given what iAlertU is, I don’t see this as likely.

We’ll see I guess. I’ve read blogs where people have bemoaned the cost of push notifications. If there does turn out to be a cost, then I’ll revisit how it’s done.

I hope to get my original objective-c push provider into somewhere like github soonish. Let me know if this is of interest.

For now, I’ll keep an eye on UrbanAirship, and hope that everyone finds the new functionality helpful.

>OK, so as I’ve said previously, version 1.1 of uAlertMe added support for Push Notifications. All it needed was for iAlertU on the Mac to send them

Last night I released v0.74 of iAlertU which adds the required functionality for all of this to work.

Getting all this to happen was actually not all that hard; Apple have made it fairly easy for us.

Originally, iAlertU was going to act as the actual provider, connecting to Apple’s APNs directly. I had the whole thing working, with the entire push notification provider written in Objective-c.

The only problem was that doing it this way meant including my private certificate for the SSL connection to Apple in the iAlertU bundle. This as my conscious and several helpful souls pointed out was a great way to ask for trouble if someone decided to misuse that certificate (although I had gone to some lengths to make this harder).

So, the next step was to add to the pkclSoft web server a provider that iAlertU could then interface with. This all looked too easy as there is a great package called easyapns that does just this, and it would have worked fine except for one thing. My web host blocks outgoing connections on the ports that Apple use for connections to their servers.

This effectively killed my ability to use easyapns which was a shame, but there were other options in the form of Push service providers.

The first I looked at was UrbanAirship. They looked great, but there is a potential cost as only the first million pushes per month are free. Although I thought it unlikely that the users of iAlertU would end up using more than this, I didn’t want to take the risk; after all I get nothing for my time on iAlertU, and uAlertMe doesn’t do well enough to pay any bills.

So I looked for another alternative, and found Xtify who offer a straight out free service to developers. I then set out to spend the next couple of days getting iAlertU to talk to Xtify, but found that whilst their service was great, and the customer support was excellent, being able to send a notification payload that could be localised by uAlertMe so that the notification can be displayed in the appropriate language was too hard. Basically, Xtify get you to send a payload in their format that is then translated into Apple’s format. This just wouldn’t work.

Back to UrbanAirship for me. Whilst they do something similar (so that you can send a single push to both iOS and Android devices) to Xtify, their interface is much more natural, better documented, and supported by packages of code that are easily obtainable via their website.

What about that cost-risk? We’ll I’ve decided to test the waters so-to-speak. I figure that with only a few thousand users out there, and that normally, the only time the push will happen is when the alarm goes off, people would have to be triggering their alarms hundreds of times per month. Given what iAlertU is, I don’t see this as likely.

We’ll see I guess. I’ve read blogs where people have bemoaned the cost of push notifications. If there does turn out to be a cost, then I’ll revisit how it’s done.

I hope to get my original objective-c push provider into somewhere like github soonish. Let me know if this is of interest.

For now, I’ll keep an eye on UrbanAirship, and hope that everyone finds the new functionality helpful.

uAlertMe v1.1 has been released to the app-store. This important update provides support for push notifications.

In the near future, I’ll be updating iAlertU such that it will, if uAlertMe has previously connected to it, send out a push notification to that same iPhone each time the alarm is triggered.

This helps to get around the problems some people have experienced when their Mac is behind a firewall, or on a network where uAlertMe can’t see it. Soon, you will no longer need an active connection with your Mac for the Mac to let you know something is happening.