Extremely easy to do, but extremely easy to mess up. I’m assuming with this post you have already configured Azure Mobile Services with your certificates. If not, there are plenty of tutorials around which can help you through the process. (I personally like this one for APNS.)

The classic Mobile Services examples all involve the Todo List app, which expect you to be using the full Mobile Services backend. It’s certainly slick if you can, but what if you only need the push notification capabilities? This is the problem I was trying to solve. The data for my mobile application is already managed elsewhere, I only need Mobile Services to manage the push subscriptions for my end users. The Javascript API portion of Mobile Services will be called from my backend and by some other applications using C# to generate the push notifications. It’s maybe not a common scenario, but it’s certainly there to allow you to do it. No amount of Google/Bing attempts landed me on a nice tutorial which satisfied my questions, so I’ll do my best.

Go to the API tab in your mobile service in the portal, and either click on the Create option at the bottom or click the big message in the center of the screen. Enter the name you want for the API, I choose Godzilla. (There was a marathon on El Rey last weekend, so I have Godzilla on the brain still.) Set the app permissions appropriately for your API, I’ll to stick with “Anybody with the Application Key” for the example and click the Checkmark button.

Screenshot 2015-07-09 15.39.09

Once it’s done creating the API, click on it to view the code. You’ll have the starter API with a Post and a Get.

There’s no need for the Get, so delete it. The Post has a hint of what you need to use on the third line of comments, “var push =…”. Let’s uncomment that line so we can use it to generate the push. (I’m only going to write the code to send pushes to iOS (APNS) to keep the example nice and simple, the code for Android should be fairly trivial to add.) After the line with “var push = …”, paste in the following code over the remaining body of Post.

push.apns.send("atombomb", {
        alert: request.body.msg       
        success: function(result){
            //console.log("Godzilla push success");
       }, error: function(error){
           console.log("Godzilla push failed, error: " + error);
    response.send(statusCodes.OK, "{msg: 'Push executed, check log for results'}");

So what is this doing? It will push a notification to only the users subscribed to the “atombomb” tag. If you want to push to all users who have allowed push notifications for your app, change that parameter to null, without quotes around null. The next parameter is the JSON content which will be the contents of the push notification. (Here’s a great reference for more options you can put in it.) You see many other examples where they only use the payload property, which is certainly nice if you need to send some data with the push, but won’t actually pop a message on the user’s device. Alert is what you need to pop a message up, and the contents of the Alert parameter get displayed on the top of the user’s screen when it is received.

Quick side tangent. If you only provide the Payload property, as I did at first, it’s hugely confusing why there isn’t a notification popping up on the device. The portal will show the push succeeds, but nothing shows up on the device. The reference link above was the light bulb moment when I realized what I had done wrong. If there is no alert property as part of the content parameter, the user will not be notified in any way. You only want to use Payload by itself when you want to push an update in the background, without the user being prompted. You can certainly use both Alert and Payload at the same time, however.

On my alert parameter, you can see I’m actually sending in the content as part of the body of the API call. If you know your push message will always be the same, you can change this out for a string right there, but I think a parameter from the body makes for a better real world example. The final parameter contains the success and error functions, which are really useful for debugging. They will write to the mobile service log using console.log, which I’ll get to next. So here’s the final result:

Screenshot 2015-07-09 16.22.22

I also edited the response message, but you can leave it as the default if you like. Now click the save button at the bottom to save your changes. If you want to check the logs once you have called your new API, click the back arrow after saving and it’s the last option in the top menu. You may need to uncomment the body of the success function to get anything to appear there, if it all works right away.

Screenshot 2015-07-09 16.24.33

So now we need to call our API. This is when Mobile Services really flexes its muscles, it’s so incredibly simple. I’ve got a fairly reusable method for this which lets me pass in the API I want to call, and the message I want to send. So when invoking the method below, I use the parameters “Godzilla” for Api and “I knew that tuna-eating monster was useless!” for Message. If you’ve swapped out the message in the body for a string as I mentioned earlier, it gets even easier as you can then remove two lines which deal with the body variable.

public async Task SendPushNotification(string Api, string Message)
            JObject body = new JObject();
            body.Add("msg", Message);
	    MobileServiceClient client = new MobileServiceClient(appUrl, appKey);
            return await client.InvokeApiAsync(Api, body);

You can go much further with that method if you want, such as passing in your own custom object rather than using a JObject. If you’re looking to do something like that, I would recommend reading “Custom API in Mobile Services,” it goes nicely into a scenario like that, and includes a little bit on handling authenticated users.

Wow, that’s a long title. I didn’t know how to find it in Google when I was searching for terms similar to that earlier, so hopefully this post helps. So you’ve gone ahead and added push notifications to your Xamarin app using Azure Mobile Services. There are tons of tutorials out there to show you how to do it. The next logical step (if you love your users) is to add a setting someplace to allow users to turn off their push notifications. So then you go looking for good documents on how to update the tags that you subscribed to… and if they’re out there, they’re really hard to find. Here’s the quick and easy recipe: do the exact same thing as the initial registration, but with an empty (or updated) list of tags.

Setting this up with the boilerplate declaration:
var push = new MobileServiceClient(url,key).GetPush();

So to register one tag:
push.RegisterNativeAsync(deviceToken, new List<string>() { “tagname” });

And to unregister:
push.RegisterNativeAsync(deviceToken, new List<string>());

If I had to choose between using the Apple Developer Portal and going to the dentist, I’m going to the dentist. At least I know what pain to expect there. Here are some tips that I wish I had gotten before I had done any iOS development.

Developer vs Enterprise Account
The Enterprise account does not include the benefits of the Developer account, despite costing $200 more. And you need to set up two separate Apple IDs (email accounts) to have both. It’s buried in their program enrollment support page.

Push Notifications
You need two different certificates for this, dev and production, both of which need to be added the to the application in the portal. Then you’ll create a provisioning profile for development, ad-hoc, and app store. Ad-hoc will be used to test push notifications through the production server before the app hits the app store. You can only test push notification on a physical device.

If you use Azure Notification Hubs, never let a device with a development provisioning profile connect to the hub with the production push cert on it. The hub will be eternally ruined at that point, and you’ll have to recreate it. It will not give you any error messages about this, it will instead just stop working for no apparent reason.

Beta Testing
This should be done through TestFlight or another service. The IPA through iTunes method is a crapshoot at best.

iTunes Image Assets
These seem to only be used for the IPA through iTunes beta testing deployment, so don’t even do them.

Apple Developer Portal
It’s not just you, it really is an unusable disaster. Whoever built it should have been a dentist.

I’ll never remember this, so I’ll brain dump it here.

Because iOS formats phone numbers as hyperlinks, I was seeing errors in the IIS event log saying “A potentially dangerous request was detected…” when I was doing an ajax post. The content I was trying to post was just a confirmation, so the phone number was held in a span rather than a textbox. It worked fine on all PC browsers and most mobile devices. Most of the posts I found on Stack Overflow and elsewhere talked about solving it by setting validateRequest on the page level to false. I didn’t want to do this, because I want that added security.

So here’s my fix: add a hidden input that holds the phone number as its value and post that rather than the content from the span.