Category Archives: iOS

Migrating from Urban Airship to PushSharp

When Urban Airship (UA) announced back in June that they would be canceling their free tier for push notifications I started looking at other free & paid alternatives (e.g. Parse, Azure and others).  However, ultimately I decided to host the push notifications myself using PushSharp.

If you’re not familiar with PushSharp, it is a server side library for sending push notifications to various platforms.

The migration was really pretty easy and involved these steps:

  • Update server software that sends out push notifications to use the PushSharp libraries.
  • Update mobile apps (in my case this was just for the iOS and Android platforms)
  • Implement a mitigation strategy to handle users on old versions of the Android application

Updating Server Software

Urban Airship provides a REST API to send push notifications:

I replaced that code with something that looks like this:

If you look at the sample in the GitHub repository you’ll see there is some setup of the Push Broker that needs to be done prior to sending any messages.  If you are hosting your server code in a windows service you could put that in your main program.  In my case I’m hosting the Push Broker inside of IIS and thus have put all of that code into my Application_Startup method.

Note: you can update and deploy the server software prior to updating your apps.

A Note about Urban Airship notifications for Android

My sample code above includes a case for Urban Airship Android messages.  The reason for this is that the device token you get from their APIs is not actually a Google Cloud Messaging (GCM) device token but rather an Urban Airship generated token.  This is unfortunate as it means you’ll need to continue sending some push notifications via the Urban Airship REST API until all of your users are transitioned over to your new app.

Updating Mobile Applications

Updating my iOS application was pretty trivial as I just had to remove the code that registered my device with Urban Airship.  Nothing else needed to be changed as the device token you deal with is a standard APNS device token and not an Urban Airship token.  Additionally, as the messages that are sent by PushSharp on the server are identical to the messages sent via Urban Airship I didn’t have to change my code that parsed the notification.

Updating my Android app was a little more involved.

1.  Remove the Urban Airship binding library as well as any calls to Urban Airship.

2.  Add the GCM Client component to the project.

3. Edit the AndroidManifest.xml and remove all lines that deal with Urban Airship.

4.  Edit the startup application code (e.g. MainApplication.cs) and remove any calls to Urban Airship and replace with GCM.Client calls:

Old:

New:

 

4. Remove the BroadcastReceiver service and replace it with a service as shown in the GCM.Client sample.  Migrate any code from the OnReceive handler in the BroadcastReceiver class to the  OnMessage handler in GcmService.

One extra piece of work that I had to do was because I was using a Urban Airship specific class for displaying notifications (CustomPushNotificationBuilder). I replaced that with Notification.Builder.

Mitigation Strategy

To handle the fact that Urban Airship uses their own device tokens on Android, my approach was to treat device registrations using GCM.Client as a new device type on my backend (and thus leave in place Urban Airship GCM device registrations).  Thus until the end of the year my server software will continue to send push notifications to any users that are still on an older version of the Android app via the Urban Airship REST API.  Users that install the new application and subscribe for push notifications will receive their notifications via PushSharp.  I’ll continue to monitor how many devices are still on Urban Airship as I approach the year end and may choose to send a broadcast notification to those devices to tell them to upgrade.  After 12/31 I will update the server software to quit handling Urban Airship GCM tokens.

Final Thoughts

If you’re thinking about adding push notifications to your app but weren’t sure what to do take a look at PushSharp.  Jon Dick has done a great job with the software and continues to support and enhance it (he tells me he is working on a new and improved version that will be out before too long!)

Why the iPhone 6+?

Why

I’m writing this a week or so after the release of the iPhone 6/6+.  I hold in my hands the 6+.  Let me backup.

iPhone 6+

As the information came out on the new iPhones at the Apple press event on September 9th I wasn’t all that excited about either phone.  I’ve had larger phones, having used various Android phones as my second phone, most recently a Nexus 5.  So a larger iphone in and of itself isn’t something I’ve been waiting for.

However, coinciding with the announcment also came the GM release of iOS 8.  I updated my devices to the GM and downloaded the dev tools and started testing my apps on the simulator.  Up to this point I had been running my apps on the various iOS 8 betas but these were apps that had been built using the iOS 7 SDK.  With the apps built now for iOS 8 I started seeing more sizing bugs (due to changes in MainScreen.Bounds), etc.  That’s when I decided I should get a 6/6+.

I decided initially to get the 6+ and not the 6.  My reasoning was that the 6+ would be the harder device to design for since it supports landscape orientation, reachability, and larger layout changes.

How

So I got up at 3AM CST on Friday the 12th (yes, I overslept my alarm by an hour 🙁 ).  I logged into my AT&T business account only to find out that AT&T hadn’t enabled the option for purchasing phones (event though a person at the AT&T store had told me the day before that it would be available).  I wasted about 30 minutes trying various things until I realized it wasn’t going to happen and went back to bed.

The next day my twitter timeline was filled with reports of failures for the most part–Apple store down, timeouts, etc.  I also saw that order times for the 6+ were already into October.  I knew then that my only option would be to go stand in line at an AT&T store if I hoped to get one on launch day.

On 9/19 I got up at 5am, showered and headed to a nearby AT&T store.  I went to the same one I had gone to last year for the 5s as they didn’t have a big line and I was hoping the same this year.  I got there at 5:45am and was rewarded with being around 9th in line.

At 7:45AM AT&T employees came out and started taking down who wanted what.  When they got to me I told them I wanted the 6+ Space Gray 64GB.  They told me that was the last one available.  I heard later that they only got in a total of 6 iPhone 6+s.  At 8AM AT&T let us into the store and I rolled out of there by 8:15 with my new iPhone 6+.

Impressions

I’ve now had the 6+ for 9 days and have been pleasantly surprised.  First off, the battery life is nothing short of amazing.  For years we all have been upgrading our phones and getting basically the same old battery life.  Not so this year.  I can now use my phone from 6AM to late into the evening on a typical day (almost midnight on some days) without recharging. In comparison to my 5s for the same usage I would often need to be charging my phone by 5pm (or earlier).  With my 5s (or 5, or 4s, etc.) I always had to make sure that I had my phone charged sufficiently before going to any event.  Woe to you if you got in your car without a car charger!

The second major upgrade that I’ve enjoyed is the camera.  The pictures I’ve taken have been noticeably better than my 5s or Nexus 5.  The picture below compares the 6+, 5, and Nexus 5.  The pictures were done very quickly and there were no retakes, etc. and that is perhaps why the iPhone 5 picture is poorly focused.

iPhone 6+, 5, and Nexus 5 Left to Right
iPhone 6+, 5, and Nexus 5 Left to Right

Developer Thoughts

There is no substitute for having an actual device so you can test usability (reach) as well as readability, etc.  From a developer’s perspective, one benefit of having the 6/6+ is that they support display zoom.  With Display Zoom turned on, my 6+ behaves like an iPhone 6, with a rendered width of 375 points.   See this article by PaintCode for more information: http://www.paintcodeapp.com/news/ultimate-guide-to-iphone-resolutions

When my app runs on the 6+ with Display Zoom turned on it will exercise the iPhone 6 sized assets in my app.  This was an unexpected benefit that I’m quite happy about–it’s almost like having 2 phones (but not).

However, as I said before there is still no substitute for having a device to determine usability and readability of your application. I may still need to get an iPhone 6 for designing for the 4.7″ screen.  But for now the 6+ was a great choice.

 

 

Cross-platform Progress / HUD for Android and iOS with Xamarin

If you develop native mobile apps using Xamarin you quite likely have used BTProgressHUD for iOS or AndHUD for Android.  These are great components for displaying work-in-progress dialogs or toast messages.

While the components have similar APIs nevertheless they are different and in different namespaces and thus create an issue if you”re trying to code share between the two platforms.  I hit up Nic and Jon on twitter this week and Jon suggested writing a class that wraps both.

I wrote XHUD.HUD as a result.  It”s quite simple as it mimics the underlying APIs and unifies the slight differences between the 2 APIs.  However, I didn”t map every variation of the APIs and thus it will need to be extended.

An example usage is shown below:

 

Both Nic and Jon have added XHUD to their github repositories here: https://github.com/redth/andhud and https://github.com/nicwise/BTProgressHUD

Longer Term

Longer term it would be nice to see Xamarin.Mobile encompass more things like this.  Having said that it doesn”t seem like it is actively being developed.  So for now we have XHUD.HUD but I”m not crazy about the namespace XHUD as it seems redundant and too narrowly focused.  Perhaps XPlat as the namespace and it contains HUD, AlertDialog, etc? We”ll see.