Tag Archive for development

Xamarin Review

http://xamarin.comRecently, we at Fingertip Tech, INC have been doing a lot of work in Xamarin and Xamarin.Forms. All in all, things have been going fairly well and the tooling seems to get better everyday! Still, nothing is perfect and at the end of the day working with the Xamarin toolchain is a decsion that has to made on a per project basis and will greatly depend on the overall budget for the project and its maintenance. We are still evaluating Xamarin.Forms but the following are my findings and observations of working with Xamarin classic.

The Good: C# is an absolutely amazing language and every .Net developer ought to apologize to every Java for not spreading the word on just how phenominal the langauge really is. I know that will be a controlversial statment and the Java VS C# debate is a post for another day, but if you haven’t ever done any work in a modern version of C#, then I urge you to give it a shot and try to have an open mind.

Xamarin Studio is a pretty good IDE on Mac OS X and XCode developers will be familar with the IDE’s layout and overall setup – additionally, if you have ever used a modern version of MonoDevelop, you’ll be in pretty good shape. Additionally, the setup process on Mac OS X was pretty straightforward and I was impressed the Xamarin was able to tie into my iOS development tool-chain, pulling up my simulators and my code-signing credentials. On the iOS side, Xamarin does a great job of supporting storyboard and nib files for user-interface design and is no too shabby on the Android side also; however, Android UIs are still best done in the XML layout files directly.

Despite being in C# rather than Objective-C or Java, Xamarin is a faithful port of just about all of the native iOS and Android APIs. In fact, if you know how to do something with say UITableView in Objective-C, then you pretty much are good to go in Xamarin.

The Bad: Working in Xamarin Studio is great! Well, that’s as long as you are working on Mac OS X. The Windows version of Xamarin Studio is nowhere near as polished or as reliable as its Mac sister. For example, on my Windows 8.1 machine, there is an issue in Xamarin Studio that incorrectly highlights correct code as erroneous. Additionally, the intellisense and related features just aren’t as reliable on Windows. AlthoughIt is likely that a good number of developers using Xamarin on Windows would prefer to work in Visual Studio, there is little excuse for the way Xamarin Studio runs on that platform and frankly it makes it seem like Windows users who have not paid for access to the Visual Studio integration are not as much of a priority as those using Visual Studio or Mac.

The Ugly: Once upon a time, developers the world over were used to paying for by the seat licences for software development tools and even progreamming languages. Xamarin is trying pretty hard to bring that back but I’m not sure it works. Something about the per seat pricing model rubs me the wrong way. Additionally, up until just the other week, no form of mothly subscription billing was available and even to date there is no monthly pricing for anything beyond the ‘Indie’ plan. As the owner of a small but still bigger than five person software development company, I find their drawing the line between ‘Indie’ and ‘Business’ at the seemingly arbitrary number of five just a bit too well… arbitrary for my tastes. Additionally, there are plenty of companies like mine that would probably prefer to not be billed seperately for iOS and Android. All of this creates a sort of complexity that just doesn’t jive with what is otherwise a clean and very customer friendly offering.

Overall, I am pretty happy with how well Xamarin is working out for us and plant to continue working in it. Follow me on Twitter or Google+. Interested in getting your app project off the ground? Then, contact Fingertip Tech, INC and forget to follow us on Twitter!

A Look at PFQuery

Querying data is a pretty common task for most if not all mobile apps. iOS and Android have made the work pretty easier for developers, but Parse has thrown their hat into the ring to make it even easier for developers who choose to use their development tools and backend system; yes, I know this sounds a little like a commercial, but I am genuinely excited about this functionality and no I have no business or personal relationships with Parse or anyone therein.

PFQuery is a simple class that, as its name suggests, allows you to query your Parse dataset and getting data returned based on certain criteria. No need to stand on ceremony, let’s take a look at some code:

- (void) someMagicalFunction {
	PFQuery* query = [PFQuery queryWithClassName:@"SomeClass"];
	[query whereKey:@"SomeProperty" equalTo:@"MagicString"];
	[query findObjectsInBackgroundWithBlock:^(NSArray* objects, NSError* error) {
		// do something with the objects


And now for you Android fans:

void someMagicalFunction() {
	ParseQuery query = new ParseQuery("SomeClass");
	query.whereEqualTo("SomeProperty", "MagicString"
	query.findInBackground(new FindCallback() {
		public void done(List< ParseObject >objects, ParseException e) {
		// do something with objects

Yup, that’s it. It really is that simple. If you want to know more take a look at the Parse docs. For those of you that are critical of Parse, I will be doing more than just code samples with it; in fact I have found a few deficiencies that I will be discussing in a future blog post.

Phonegap the Bad and the Ugly

Times are tough and development budgets seem to be getting smaller and smaller, assuming that you are not Draw Something or Instagram. My experience has been that clients who are interested in supporting both Android and iOS do not generally want to develop two native applications. The reasons are obvious: cost and time.  So the conversation tends to turn to cross platform solutions. Currently, there are two types of cross platform mobile solutions for non-games: web based ones and Mono. I am currently doing a little work in Mono for Android and will write about that at a later date.

The most obvious web based solution is probably Phonegap. Phonegap has been around for a while and allows developers who have HTML/CSS/JS skills to leverage those to develop rich cross platform mobile apps. That’s all true. However, there are a few issues with Phonegap: it is not a mature platform, is a huge dependency, and is nowhere near as performant as native code.

This will probably be the most inflammatory issue I have with Phonegap, but I stand by it. Phonegap is not mature and it shows. A lot of the more complex and useful functionality comes from community plugins. However, the platform has to date been in such a state of flux, that you are likely to find that many plugins don’t work or at least don’t work without some form of modification on the most recent version of the platform. This may seem like a relatively small issue but if you look at it in terms of developer efficiency, then it becomes a bit more serious; do you want to be hunting down the right version of the right plugin for your version of Phonegap?

Dependencies are a necessary evil on any project and plugins are dependencies. Even if you are developing a native app you are taking a dependency on at least a language and one or more frameworks. Using a tool like Phonegap adds a big dependency on Phonegap itself which also depends on those native dependencies you were trying to avoid. Worse still, since the Phonegap must interact with Cocoa Touch or Android, there is a chance that you will have “mystery meat crashes” on one or both platforms. One example on iOS is that Phonegap does not do a great job with memory management, so your choices are use ARC (only recently an option), dropdown to Objective-C and write some “release” statements, or run the risk of seemingly random crashes in the wild.  Another issue with such a large dependency that depends on one or more distinct dependencies is that you end up with the lowest common denominator between all platforms. For example, there is no iCloud support in Phonegap nor is there Newsstand support. Someone could write a plugin for these but those would be yet another dependency in your app and any changes to Phonegap or worse Newstand or iCloud could break your plugin.

It is unlikely that you will be developing the next Infinity Blade, but performance still matters even outside of the games space. Phonegap is not as fast as a native app. It can’t be. Normally, this isn’t a huge issue for most apps but it is important to consider during the planning stages of your app especially if you want to use the camera or have a flashier UI; the camera is noticeably slower in Phonegap. As always, your app’s tolerance for the performance hit will depend a lot on the spec, but it is something to keep in mind.

Having said all that, there are cases in which Phonegap is a good choice. If budget is a huge issue, cross platform is a must on day one, the app will be pretty plain, and performance is not a chief requirement. As always, you need to pick the right tool for the right job, but remember there are no silver bullets. Questions? Comments? Rage? Find me on Twitter or Google+.