Friendlydeveloper.com

Posts Tagged ‘push notifications’

Hello everyone,

I’ve recently been playing with UILocalNotifications and really love them. When Apple first introduced Remote notifications (aka. push notifications), they were a real treat to both developers and users. Applications could receive information, even though they were not running at that time. However, it was (still is) a bit painful to implement them. You need to create certificates, run your own server or sign up with some company, that does the message forwarding for you.

Now, in case you only want to remind your users of something or allow them to schedule an event inside your app, UILocalNotifications are what you’ve been looking for. They are quite easy to set up and you don’t have to hassle with certificates, etc…

I’ve decided to release a little class, that easily allows you to schedule an event, delete a specific event or simply delete all events.

Ok, here we go:

My UILocalNotificaionsWrapper class consists of 3 different methods:

+ (void)addLocalNotification:(int)year:(int)month:(int)day:(int)hours:(int)minutes:(int)seconds:(NSString*)alertSoundName:(NSString*)alertBody:(NSString*)actionButtonTitle:(NSString*)notificationID;

+ (void)cancelLocalNotification:(NSString*)notificationID;

+ (void)cancelAllLocalNotifications;

The first method is the most complex one and allows you to submit several different values to customize your notification event:

• year (integer) – e.g. 2011
• month (integer) – e.g. 4 (April)
• day (integer) – e.g. 29
• hours (integer) – e.g 10 (= 10 am) – use 22 (military time) for 10 pm
• seconds (integer) – e.g. 0
• alertSoundName (NSString) – . e.g. nil to use custom sound name or @”NameOfTheSoundInsideYourAppBundle.wav”
• alertBody (NSString) – e.g. @”This is a LocalNotification”
• actionButtonTitle (NSString) – e.g. @”view” – This will appear on the button, when your local notification fires
• notificationID (NSString) – e.g. @”12345″  (has to be unique. you could keep track of your IDs inside an array, dictionary or SQLite database

Now you can simply make a call like this to schedule a new event:

[UILocalNotificationWrapper addLocalNotification:2011 :4 :4 :19 :17 :0 :nil :@"This is a LocalNotification!":@"View":@"12345"];

In order to delete the notification you just scheduled, you could make a call like this:

[UILocalNotificationWrapper  cancelLocalNotification:@"12345"];

Finally, to delete all scheduled notifications:

[UILocalNotificationWrapper cancelAllLocalNotifications];

One more thing…

Don’t forget to add #import “UILocalNotificationWrapper.h” inside the class you are making the calls from and always test on your device (UILocalNotifications don’t work on the simulator)

Grab the source file here and enjoy

Feedback always welcome.

 

When implementing a push notification feature into your application, you usually create two different types of certificates: One for development (sandbox) and one for your customers/testers (production).

As you might already know, your device will automatically run in sandbox mode when launching the app directly from XCode.

So, the following method inside your app delegate will receive a device token, which is different than the one it receives, when you install it via iTunes:

- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)devToken;

You have to keep in mind, that your push messages will not get delivered on this device, if you’re not running the development (sandbox) certificate on your server. Another important thing is the fact, that in case your server is running the production certificate and you try to send a push message to a device in sandbox mode, it will break connection to APNS. This means, that even push messages using the correct certificate will not get delivered any longer, until you reset connection to APNS.

So, if you sometimes wonder why push notifications fail during development of your app, consider the above.

Implementing Apple push notifications into your iPhone/iPod Touch or iPad app can be quite the challenging task. You really have to pay close attention to the official docs when setting it up and even then it might not work right out of the box.

If you’re new to APNS, you might want to check out the tutorials, I mentioned in one of my previous posts:

http://blog.boxedice.com/2009/07/10/how-to-build-an-apple-push-notification-provider-server-tutorial/
and
http://mobiforge.com/developing/story/programming-apple-push-notification-services

I can only repeat myself by saying, that these tutorials really rock and should definitely get you started.

If you don’t plan on running your own server, check out Urban Airship. They currently offer two different plans, which should perfectly fit your needs.

However, implementing APNS on your own server is most fun, as you’re likely going to face some issues

Rule #1, if nothing you tried so far works: Get some open source package and learn from the professionals: EasyAPNS is exactly what you might want to check out in this kinda situation.

Don’t forget to watch the video tutorial, which can be found right on the landing page.

Some additional hints and suggestions:

If your iPhone/iPod Touch/iPad app communicates with your server (maybe via php scripts), check out ASIHTTPRequest. This is some awsome package, that you can easily integrate into your existing XCode project. It’s perfect for contacting your server via POST requests. However, ASIHTTPRequest can do much more – just check out the official docs, which can be found on the developer’s website.

If you’re testing push notifications with your beta testers, make sure that you’re using the correct APNS certificate on your server. By correct I mean: Development certificate or Production certificate. In case you followed the tutorials above, you probably created both. In order to clear things up, check out the steps below:

• If your iPhone/iPod Touch/iPad app communicates with your server (maybe via php scripts), check out ASIHTTPRequest. This is some awsome package, that you can easily integrate into your existing XCode project. It’s perfect for contacting your server via POST requests. However, ASIHTTPRequest can do much more – just check out the official docs, which can be found on the developer’s website.
• If you’re testing push notifications with your beta testers, make sure that you’re using the correct APNS certificate on your server. By correct I mean: Development certificate or Production certificate. In case you followed the tutorials above, you probably created both. In order to clear things up, check out the steps below:

1. Find your Provisioning certificate and the AdHoc one, you are using for your beta testers: Open up XCode and go to “Window”->”Organizer”. Now click on your Provisioning certificate, then right click -> “Reveal in Finder”. Do the same for your AdHoc certificate.
2. Open up both files with TextEdit (DON’T EVER CHANGE ANYTHING IN THERE!!!) and look for the following string: “Environment”.
3. Right below you should see either “Development” or “Production”.
4. If you want your beta testers to receive push notifications and their AdHoc certificate says “Production”, you now know that you will have to use the APNS Production certificate on your server. Otherwise push messages won’t get delivered.

Happy pushing