I don't need to be the one to explain the importance of analytics in your mobile app. What I believe to still be up for debate is the best analytics platform. Obviously, there is no silver bullet. It all depends what you are looking for. If you want to integrate analytics with your backend, you may go with something like Azure Mobile Services, Parse, or Buddy. Perhaps you go with a more traditional and familiar provider like Flurry or Google Analytics. For me, I just wanted a simple provider that has straightforward pricing, a beautiful web dashboard, and a simple API without all of the complexities of the usual analytics services. That's when I found Localytics.
Integrating Localytics into your product can take as little as ten minutes. Localytics doesn't come with the option for a Xamarin.iOS SDK, so I bound the Objective-C one myself in less than thirty minutes using Objective Sharpie. With this, you can now easily integrate Localytics into your Xamarin.iOS apps in as little as ten minutes.
Get Localytics for Xamarin.iOS on GitHub
Setup
The setup process is the same, regardless of the app you are building. All of the steps have to be repeated in order for your application to get up and running with Localytics. A detailed guide on the setup process can be found on the GitHub repository for the binding.
Events
Have you ever seen a promotional line around the following "Over 1,000,000 tasks completed!" for an app? This information can be collected via events. Events can provide valuable insight into what users are doing within your application. You can see what features the users like, as well as the ones they don't like (or don't know about).
Integrating events into your application can be done via one line of code:
LocalyticsSession.Shared.TagEvent ("EventName");
Localytics offers a detailed guide on when to use events, as well as some general best practices.
Screen Flow
Screen flow can provide valuable insight into how exactly your users are interfacing with your application. Screen flow can help track down the reasons behind a particular feature being used, or help show that a particular process is too tedious. Again, Localytics outdid themselves. You can integrate screen flow with one line of code (AGAIN!?):
Localytics is an analytics vendor with a simple API that doesn't bog me down with tedious information that would be tough to find useful. Many of the integrations are just one line of code, making the entire process of collecting data within your app painless. They even have some marketing APIs you can tap into, though the binding doesn't support those yet.
For additional integration information, check out Localytics website, or the Xamarin.iOS bindings on GitHub. If you have questions, feel free to tweet me at @pierceboggan or email me at [email protected], and I would gladly answer them.
Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.
✓ Live Streaming✓ Interactive Chat✓ Private Shows✓ HD Quality✓ Free Actions
Free to watch • No registration required • HD streaming
With the recent rise of Pinterest, waterfall-styled layouts have also seen a rise in popularity. Because I like to stay in style, I decided there was no reason I couldn't use this design style in my Xamarin.iOS apps. However, there was a barrier. Apple doesn't ship a layout like this. So naturally I scoured the web for some Objective-C layouts that I could bind so that I could play around with it in Xamarin.iOS. I eventually came across a library called CHTCollectionViewWaterfallLayout by Nelson. After thirty minutes or so spent on the binding process, I had this up and running on Xamarin's tooling.
I liked the control so much that I decided to use it in my app and convert it 100% to C#. The result: WaterfallCollectionViewLayout - a simple layout for Xamarin.iOS that allows you to leverage the styling of the waterfall layout made famous by Pinterest.
You can download a release-ready version from Github, and view the documentation that accompanies the library. However, for your convenience, I will also walk you through the complete process of integrating WaterfallCollectionViewLayout into your app.
For starters, you will need to be familiar with UICollectionViews. They aren't a particularly difficult topic to conquer (especially if you have worked with UITableViews). Additionally, you will need to download the latest release so that you can reference the assembly in your project. Finally, download the CollectionViewTemplate project that will serve as a base moving forward. There are several parts to a successful integration, so I will walk you through piece-by-piece.
A Walkthrough of CollectionViewTemplate
Open up the solution file for the CollectionViewTemplate. This project is a non-functional (yet) template for getting started with UICollectionViews. All of the necessary pieces for a regular UICollectionView are already in place, so all that needs to be handled is to add in the layout-related stuff. This is intended to teach you exactly what makes implementing a PBCollectionViewWaterfallLayout different than other layouts.
If you open up AppDelegate.cs, you will find the FinishedLaunching method, the entry point for our application. There are currently some unused fields I've defined, as well as some methods that we will fill in later.
Next, the Tag class that has been defined serves as a data model for our cell. There isn't really anything special about it. The collection view will present a series of hashtags (represented by the Name property) with a corresponding image below (represented by the Image property).
WaterfallCell isn't really that different from any cell that you may have come across, however, there is one small thing that makes it stand out. I'll point that out later.
WaterfallDelegate will be the delegate for our layout that will be implemented at a later time.
Finally, WaterfallCollectionViewController is like any other UICollectionViewController, except I have added an UpdateLayout method, which I call in ViewDidAppear.
1. Populating Data & Calculating Heights
The first step to a successful implementation of WaterfallCollectionViewLayout is figuring out exactly how tall each cell should be. In this custom layout, the widths are a fixed height (to be set later), while the heights are flexible (hence: waterfall). However, the layout isn't smart enough to know exactly how high each cell should be. This provides the user with more opportunity for customization.
For our app, we are going to want to access some data stored in a database or pull it from a web service. For simplicity's sake, this data will generated in the DownloadData method of AppDelegate.cs. This data will be used by both the layout's delegate, and the collection view's cell to draw WaterfallCell.
Using the data field of AppDelegate as our object to which we are storing data, we can just mock up some quick fake data. Note: Images #1-3 are in the Resources folder, and were provided by the template. As I said earlier, pretend we are drawing this data from something like the Google or Bing Images API. Unfortunately, the images I've provided don't really match the tag, but I suppose that's not the point.
Next, we need to calculate the height for our cell using the information we find in each Tag object of the List<Tag>. Using a foreach loop inside of CalculateCellHeights, we will base the cell's height off of the Image of the Tag object, and store it in the cellHeights field. This will serve as the height of each cell.
You may ask: isn't this something we should do in the delegate class itself? You certainly can. The reason for me not doing so is that it slows the drawing process of the UICollectionView, which makes it look pretty laggy. I would rather have the heights pre-calculated, and pass that to the delegate. If this was a normal application with more views, I would probably download this data and calculate this asynchronously and store it until needed.
Finally, let's setup the layout. To clean up the code a bit, I'm doing this inside of the SetupLayout method. Let's start out by calling DownloadData as well as CalculateCellHeights. Once we have our data and heights, next setup the delegate by initializing the field with the new operator, and pass in the cellHeights into the delegate's constructor (which we haven't setup yet).
Next, we will setup the layout by doing the following:
Notice the four properties we set. ColumnCount, which defines the amount of columns the layout has is by default set to two. For good measure, I've also set it to two. ItemWidth is the width of each cell. As I noted earlier, one restriction with this layout is that widths are fixed. Finally, SectionInset provides some padding around the UICollectionView so that our cells aren't drawn right on the edge.
Important: Keep a class-level reference to both the layout and the delegate. If you don't, one of these (if not both) will be garbage collected, and your app will crash.
2. The Collection View Cell
I mentioned there was something special about WaterfallCell that makes it unique. That one thing can be found within the PopulateCell method when I set the PlaceholderImage's frame to the height of the image. This auto-resizes the UIImageView so that it will match the value we set in our cellHeights field of the AppDelegate.
PlaceholderImage.Frame = new RectangleF (0, DisplayLabel.Bounds.Height, 129, image.Size.Height);
Of course, your cell may require no additional configuration changes. But if it does, remember that the delegate draws the cell of the appropriate size, it doesn't resize content to the size you specify. That will need to be done here (unless you have AutoresizingMasks on).
3. The Layout Delegate
The delegate for the layout handles the heights of each cell, as mentioned earlier. Open up WaterfallDelegate.cs and add a "using WaterfallCollectionViewLayout;" compiler directive to the top of the file. This will allow us to access the custom layout delegate type.
Next, make WaterfallDelegate a subclass of PBCollectionViewDelegateWaterfallLayout and add a constructor that takes in a List<float> as a parameter and pass this to the base class. This will be where we can access the heights we calculated earlier. Add a class-level field of type List<float> that will store the incoming information from the constructor. Finally, override the GetHeightForCell method and return a float using the indexPath parameter. Your implementation should look something like this:
Obviously, this delegate could be implemented any number of ways just as long as the HeightForCell method returns a correct value for the corresponding cell.
4. The Collection View
Finally, we will make some changes to the WaterfallCollectionViewController class to make it waterfall-layout-ready. In the UpdateLayout method, insert the following code:
var layout = (PBCollectionViewWaterfallLayout)CollectionView.CollectionViewLayout;
This will allow the layout to adjust drawing based off of a change, such as a flipped orientation. Notice that this is called in ViewDidAppear, which allows some recalculations to be done when the view appears, if necessary.
Finally, return to the AppDelegate class and pass in the layout, followed by the data. Compile and run the project, and you should have a functioning waterfall UICollectionView!
Reviewing the Steps
The process is quite simple to replicate.
1. Calculate each cell's height.
2. Pass this height into the layout's delegate.
3. Update your cell so that it matches the height in HeightForCell.
4. Configure your layout to match your specific needs.
5. Update the UICollectionViewController to deal with re-drawing, such as when the orientation changes.
Final Thoughts
Custom UICollectionViewLayouts are a great way to spruce up your boring collection views. Integration really isn't that different from implementing a normal layout.
For further documentation, please visit the GitHub repository for the project. I plan on packaging this as a component for the Xamarin Component Store soon.
Also, a huge shoutout to Nelson for writing the original library, and Chris Hardy (@chrisntr) for helping me track down a garbage collection issue.
As a new writer, I always appreciate constructive feedback, positive or negative. This can be mailed to [email protected]. Additionally, if you have any other topics you would like to see covered, feel free to email me as well.
After much consideration, I finally decided to give in and create a video tutorial for creating bindings. I don’t really do much presentation-style stuff, so you’ll have to bear with me at times. However, I think the video expounds upon what I mentioned in my blog post, and can provide some helpful visual cues in difficult areas (such as setting up an Xcode static library).
Some things to remember:
This is an introductory-level tutorial, if you have already bound Objective-C libraries, it probably isn’t for you.
There are many ways of binding a library, this is just the best way for me, so therefore it is the formula I’ve chosen to share with others.
Objective Sharpie is a very new tool. It isn’t even to version 1 yet! So be patient with it. If you have issues, feel free to post in the Xamarin Forums or file a bug.
Slides
Video Direct Link
Any feedback would be great, as I’m rather new to this! Constructive criticism, as well as ideas for future blog posts/videos, can be emailed to [email protected]. Thanks guys!
Binding Third-Party Objective-C Libraries in Xamarin.iOS
Third-party libraries are great. They cut down on the development time significantly by allowing developers not to have to worry about building certain things, like a custom UI control. Unfortunately, many of these controls are written in Objective-C. However, this isn't a deal breaker for those developing iOS apps in C# with Xamarin, because we have something known as bindings that allow us to reproduce libraries in C# in a minimal amount of time.
Simplicity
People often don't realize the simplicity (on the user-side) of binding a third-party library. When working with smaller libraries, it is possible to bind them without really any Objective-C knowledge, which comes to a surprise to most. This wasn't true until recently. Xamarin recently announced the release of Objective Sharpie, a tool that does all the heavy lifting that would normally accompany the binding process. Sometimes, I feel like we make things much harder in the software world than they need to me. It isn't really required to have an extensive knowledge of how the binding process works or be a NSHipster to bind simple things (though it would certainly be helpful to learn these things). In larger libraries, things can get complicated fast, but for the majority of UI-related libraries, as well as smaller SDKs, you can bind these on your own with little to no Objective-C knowledge. Many times, it can be done in as little as fifteen minutes, especially because the process is pretty reproducible once you get it down.
Binding vs. Converting
One important distinction to be made is that it may be in your best interest to convert a particular library to C# and Xamarin.iOS, rather than bind it. There are certain strengths of each approach, as well as particular circumstances when each technique is particularly useful!
Binding:
Little to no Objective-C knowledge
Quick and straightforward
Less customization
Converting:
Objective-C knowledge
Tedious
More customization
Another helpful technique is to bind the library first, and then convert the library to C# such that the API definitions are the same, so you can seamlessly integrate the C# version into your application. This approach allows you to get a library up and running quickly in Xamarin.iOS, and then grant yourself more control and customization with with a C# version later.
Things to Remember
This guide doesn't really target those trying to create Android bindings, but Xamarin does have a doc detailing the process quite nicely
This guide is targeted primarily towards beginners, especially those without much Objective-C knowledge
The intended result is for you to be able to bind small libraries, nothing to complex (you have to start somewhere)
The license for the project you are trying to build is permissive (something like MIT)
The monotouch-bindings repository is always open for your contributions, big or small
The Xamarin Component Store is waiting for your controls to be submitted! Just make sure the license is permissive, your control has been heavily tested, and that you've double-checked with the original author to make sure it's okay
Let's assume a few things before we started. First, I assume that the library you are trying to convert is fairly small (one or two classes). Second, I assume that you have at least an introductory level of knowledge of Xamarin.iOS. Finally, I assume that you have all of the latest updates and such from Xamarin.
Before we get started, there are also a few things I want to ensure we have downloaded:
Objective Sharpie: This is the tool we use to generate bindings for our library
Command Line Tools: Xcode -> Preferences -> Downloads
Once those are downloaded and installed, it's time to pick a library to bind. QBFlatButton is a simple project that the rest of this tutorial is going to use. Certainly, you can bind more complex libraries, but I believe the library serves as a great starting point (without all the complexity).
Note: I'll be adding a video tutorial later, but this was an in-demand tutorial, so I wanted to get it up ASAP!
Static Library
The first step in binding an Objective-C library is to create what is known as an Objective-C static library. This generates a file with the extension ".a" that you may have seen around. The static library is what is linked against when the binding process takes place. Sometimes, we are given this, but more than often we have to build it ourselves.
The type of static library we are going to be building is called a "FAT" static library, because it contains options for all of the possible architectures (armv6, armv7, armv7s, and i386), instead of just targeting one. The armv7 and armv7s architectures have to do with the device, while the i386 has to do with the iOS Simulator. Note that the downside to this is that we are given a very bloated static library (in most cases, you would create separate static libraries for each architecture, and link those), but it is great for testing and demonstration purposes.
Note: If you ever get lost, or can't quite get your binding to work, I suggest working with the BindingSample project and changing around your settings to work with your library!
Open Xcode and create a new project by navigating to File -> New -> Project. Under the section, make sure you are under iOS (as opposed to OSX), select Framework & Library, followed by Cocoa Touch Static Library. Give the project a name and location, and then it's time to get started.
Right-click and delete (Move to Trash) the auto-generated .h and .m files. Add our own that we downloaded earlier by right-clicking the project name, followed by Add Files.
Click the project, and then navigation to File -> New -> Target. Follow the same steps as before, except this time add the suffix Universal to the name (this is a naming convention, nothing that is required). In the project settings, change the setting "Build Active Architectures Only" to no for both Debug and Release. Also, make sure that for the Link Binary with Libraries section you add the UIKit and CoreGraphics frameworks by clicking the + button and searching for the frameworks (Foundation should be in there already).
Next, go to the Build Phases tab. Add the .m file to the Compile Sources section, and add that .h file to the Copy Headers section (you may have to add this section by going to Add Build Phase -> Add Copy Headers.
Now, we need to add a run script so we can create a universal static library. Xcode doesn't really have an ingenious way of doing this, so we use a build script. I like to use the build script found in the BindingSample repository of monotouch-samples, but we can use them from other sources as well.
In the Build Phases tab, click the + button in the lower-right hand corner labeled "Add Build Phase", then click Add Run Script. Copy over the script from above into the box.
When you try to build, you will get an error about a pch file (pre-compiled header). To remove this, for each target, search "pch" and delete the field that appears. Recompile and you should be given a .a file. Make sure you click the build scheme and change it to our universal static library! This will generate the .a file used during the binding process.
Navigate to Build/Products/Debug-Universal/ and you should see our .a file! All of the heavy lifting is done!
Binding Project
Open up Objective Sharpie. Click next and set your Target SDK to iOS 6.1 (or whatever the default iOS setting is for you). Next, you must add your header files. I've found the most foolproof way is to just select the directory we downloaded, and cut out the junk we don't need (for example, it may bind an AppDelegate if there is a sample project).
Add the directory for QBFlatButton, enter a namespace definition (you can change this later), and enter a name for the auto-generated file. You should come out with no errors.
Next, open Xamarin Studio and create a new iOS Binding Project. I've named mine FlatButton. Now, add the universal .a file we created earlier to our binding project. A drop-down button should be next to the .a once it is loaded into the project. Click this dropdown and open the .linkwith file. Add the frameworks that were under the Link Binary with Libraries section by adding the following to the file, after one of the commas (make sure to add one after this statement):
Frameworks = "UIKit Foundation CoreGraphics"
Open ApiDefinition.cs and copy over the body of the namespace that Objective Sharpie created for us. In our project, an AppDelegate was also added (because we selected the entire directory), so we can delete that. Note that sometimes the interface name gets a bit screwy, so we may want to fix this. Additionally, as a community, can we loose the whole initials prefix in our libraries. It's riddled with pride, and just looks stupid. To do this, lets rename our interface to:
public partial interface FlatButton
Inside the attribute above the definition for FlatButton, change the contents to:
[BaseType (typeof (UIButton), Name = "QBFlatButton")]
Note that this name attribute must be the original name used for the class (in Objective-C).
Next, build the project and a .dll will be generated for you to use in your project!
Demo Application
Now that the binding has been generated, it's probably a good idea to test it (as well as other reasons I'll mention later). I would suggest trying to recreate the demo application provided with the original library.
PROTIP: If you get an error saying "The native class hasn't been loaded" on runtime, this usually means your .linkwith, although appearing, is not actually building with your project. You should add this file to your project like you would any other file, recompile, and you should be good to go!
You can see FlatButton on my Github, including the static library project, the binding project, and the demo application.
Moving Forward
Once you are comfortable binding simple libraries and want to grow, here are some things I would recommend:
Read the Programming with Objective-C introduction by Apple. You can skim over most of the document, but pay special attention to the topics of method, property, and delegate declaration in Objective-C. Basically, you only need to be able to read the contents of the header (.h) file of the class!
Read the Binding Objective-C Libraries and Binding Types Reference Guides from Xamarin. Read them all the way through to get a good overview, and then you can use the document as more of a reference later!
Be aware of the design paradigms of the C# language, and apply these when you are binding libraries (make it C#-ified!). If you have any experience with C# or .NET, this shouldn't be a problem. Example: Knowing that properties are better than accessor (getter) and mutator (setter) methods in Objective-C.
Then, once you understand these things:
Look at other bindings in the monotouch-bindings library. Download the accompanying Objective-C source and compare the two.
Make small corrections or updates to the bindings in the monotouch-bindings library. (Sidenote: Contributing to open-source projects is one of the best things that has happened to me. You should try it too, even if it is something simple such as a one-line fix!)
Bind progressively larger libraries until you are doing whole SDKs and complex UI bindings
Closing Remarks
Certainly, there is lots of room for improvement in the binding process. But as it stands, I believe this is the simplest way to get into binding Objective-C libraries. You won't be an expert on the binding process, nor will you be able to be able to bind extremely complicated libraries, but this is a solid starting point. The source code for FlatButton (including the static library, the binding, and the demo) is available on Github. Feel free to do what you like with it.
Sebastien Pouliot has also posted a wonderful blog post about producing better bindings for both Xamarin.iOS and Xamarin.Mac.
I'm more than happy to write about lots of different iOS topics, you just have to let me know what you want. I also love constructive feedback of any kind, positive or negative. Just send me an email at [email protected] (Please do not email me for binding help, that is better off for the Xamarin Forums).
Following my previous blog post on push notifications, I was asked by Xamarin to do a little more in-depth look at push notifications, as well as some small demos!
The seminar was recorded yesterday (February 27th), and we finally got it up today (February 28th). In comparison to my previous blog post, I would recommend that you read through the pricing analysis and such that was included in the blog post, but the demos are much more comprehensive in the seminar and show off Xamarin's 2.0 release, including Xamarin Studio and the Component Store.
If you have any questions or comments regarding the seminar or push, please feel free to email me at [email protected]
Anya is live and ready to show you everything. Watch her strip, dance, and perform exclusive shows just for you. Interact in real-time and make your fantasies come true.
✓ Live Streaming✓ Interactive Chat✓ Private Shows✓ HD Quality✓ Free Actions
Free to watch • No registration required • HD streaming
Push notifications have become an almost untold "required" component of your app. Behind a plethora of reasons you may want to send a push notification to a user, there are also many choices for choosing a service to get the job done. I'm going to be outlining two main options that I personally like to use, Parse and Urban Airship (and a little bit of PushSharp).
Price
It's important to note that both services offer 1,000,000 push notifications free (per month). For most indie developers, that should easily hold you off. Price probably won't be the main selling point between the two services for you. But if you manage to go over 1,000,000 pushes, the pricing structure is a tad more interesting.
Parse: You can either pay $0.07/1000 extra pushes (at the free plan level), or pay $199/month for 5,000,000 push notifications and a $0.05/1000 overage fee.
Urban Airship: You pay $0.001 per extra push (as opposed to $0.00007 per extra push with Parse) at the free plan level. You can upgrade to another level, but pricing information isn't available as you have to "contact sales" for further pricing information.
Let's see how this breaks down graphically:
As you can see, Parse offers a much more viable solution if you surpass the 1,000,000 free plan limit. To be fair, Urban Airship probably has a more economical solution for pushes over 1,000,000, but I'm just working with what pricing is given on their website. Additionally, with Parse you get 1,000,000 free requests (to the data browser, with social plugins, etc.) with each plan. The moment you should switch from the Parse free to the Parse premium tier is when you're sending 1,285,700 pushes a month. Parse wins the pricing round!
Ease of Setup
Note: I will be doing a push tutorial for iOS only, although both services support push notifications for other platforms.
General Setup:
First, visit the iOS Provisioning Portal and click on the tab labeled "App IDs." (Skip to the next step if you already have created an App ID for the application you wish to add push to.) In the top-right corner, click "New App ID." Fill out the information on the form as recommended by Apple. You should be redirected to the main App IDs tab.
Find the application that you just created and click on the "Configure" button. Click the checkbox for "Enable for Apple Push Notification service." Two options should appear for configuring push SSL certificates. In this tutorial, we will only setup the development certificate, although the process for creating the production certificate is exactly the same. Follow the instructions given by the dialog.
After completing the process, download your certificate. Open it and Keychain Access should also open. In the entry created in Keychain Access for the certificate, right-click and chose the "Export" option. Make sure the specified file format is .p12.
You are also going to want to setup a Provisioning Profile for your app, so you can send test notifications to your device. Apple provides a document detailing exactly how to do this.
You're now done with the general process.
Parse:
Go to the Parse dashboard and create a new app. Navigate to the Settings pane and chose the "Push Notifications" tab on the left-hand side. You can enable client-push, which basically means that push notifications can be sent from within the app itself (and not just from the web dialog). Upload the .p12 you have generated, and you are good from the setup end.
Time to get the third-party bindings for the Parse library setup. Navigate to the MonoTouch Bindings repository on Github. You can clone the repository, or download the .zip file. Once you've done that, copy the Parse folder to the Desktop (or an easy-to-access location). Download the Parse iOS SDK (chose the "SDK Only" option), and put it in the Parse/binding/ directory. Open up Terminal and type the following command:
cd ~/Desktop/Parse/binding/
make
You should get a "Compilation succeeded" message. Check the /binding/ folder and you should find Parse.dll.
Open up MonoDevelop and create a new iOS application. Add the newly-created Parse.dll as a reference in the project. Update your Info.plist with the information you provided when you created the App ID (bundle identifier mainly).
Open up your AppDelegate.cs file and add a reference to the Parse library (ParseLib). The following code should be placed in the FinishedLoading method and will ask the user if it's okay for the application to send push notifications. Generally, you ask for permission for all types of push notifications in case you decide to use that type at a later time.
You are also going to want to setup your application to work with Parse, of which you use the following code. You can retrieve your Application and Client IDs from your application's Parse Dashboard.
Additionally, override the following two methods to get you up and rolling.
public override void RegisteredForRemoteNotifications (UIApplication application, NSData deviceToken)
{
ParsePush.StoreDeviceToken(deviceToken);
}
public override void ReceivedRemoteNotification (UIApplication application, NSDictionary userInfo)
{
ParsePush.HandlePush(userInfo);
}
Deploy the application to your device for testing, access the Parse Dashboard for your app, and fire a test notification!
Bonus: You can do loads of other cool stuff and targeting with Parse Push Services, of which they have created a detailed guide on their website.
Urban Airship:
Create a new application with Urban Airship and provide all the necessary information, including uploading your .p12 certificate and click "Create your app."
If you haven't already, download the MonoTouch Bindings repository and navigate to the Urban Airship folder. Move it to a more accessible location, like the Desktop. Download the Urban Airship iOS SDK and move it to the /binding/ folder. As with Parse, run the following command in Terminal to build the .dll.
cd ~/Desktop/UrbanAirship/binding/
make
You should now have a .dll to work with! Open up MonoDevelop and create a new iOS project. Add the .dll we just built as a reference.
Add a new .plist file to the project and call it AirshipConfig.plist. Set the following values depending on whether you are building for production or using the development sandbox.
DEVELOPMENT_APP_KEY = "Your development app key";
DEVELOPMENT_APP_SECRET = "Your development app secret";
PRODUCTION_APP_KEY = "Your production app key";
PRODUCTION_APP_SECRET = "Your production app secret";
Open up AppDelegate.cs and reference the Urban Airship assembly. Add the following code (Note: taken from Urban Airship's tutorial. All I've done is converted the code to C#).
NSMutableDictionary takeOffOptions = new NSMutableDictionary();
takeOffOptions.SetValueForKey(new NSString("launchOptions"), new NSString("UAirshipTakeOffOptionsLaunchOptionsKey));
UAirship.TakeOff(takeOffOptions);
This is all the configuration code necessary to get push up and running. Now we need to add the code to ask the user for permission to send push notifications.
Great! Almost done! Now override the following methods to complete setup.
public override void WillTerminate (UIApplication application)
{
UAirship.Land();
}
public override void RegisteredForRemoteNotifications (UIApplication application, NSData deviceToken)
{
UAPush.Shared.RegisterDeviceToken(deviceToken);
}
Now deploy to the device, visit the app's Urban Airship page, click Push Composer, and push your heart out!
Conclusion:
I gotta say I think that they are both pretty close on the setup end, but I have to give the edge to Parse. No .plist is required (not that that is a big pain) and line-wise Parse is simpler to setup and understand.
Ease of Use
Parse wins here I think. Although I think Urban Airship has a cleaner Push Compose page, I have to give the edge to Parse based on their documentation. Parse's docs team did a fantastic job and every feature of their product is thoroughly documented. But you could really go either way here.
Evaluating Other Options
There are certainly plenty of other services that do the exact same thing as Parse and Urban Airship's. Certainly, these are the two most encountered from what I've seen, and I believe them to be the best two options.
That being said, push notifications are an essential part of your app and you may want as much control as possible over the process. The only way to achieve this is to send your own notifications, which you can do through a tool like PushSharp. It is an open-source, server-side library that allows you to send push notifications to iOS, Mac OSX, Android, Windows Phone, and Windows 8. For those who have outgrown Parse or Urban Airship, or it is becoming too pricey, then PushSharp is a great option. There is even a Xamarin seminar about it.
Conclusion
Honestly, you can't go wrong with either option. I lean towards Parse. I think they are much more up-front with their pricing structure, have great docs, and provide a great overall experience. Urban Airship isn't necessarily bad, but against Parse I would certainly chose the latter.
