As you start thinking about building for mobile you should start by reading a guest post on Martin Fowler's blog entitled "Selecting a Mobile Implementation Strategy" by Giles Alexander. That post is very comprehensive and lays out a lot of the decisions that need to be thought through when deciding what mobile platforms to target and how to approach multi-platform development and feature parity. It weighs the various options ranging from pure HTML to pure native. It also talks gives good insight when thinking about going breadth or depth first in terms of target platforms and features.
The second article you should read is "The Architect's Guide to Choosing Between HTML5 or Native Mobile Apps". While I personally don't believe that HTML5 support is ready for HTML only native applications, it's a good thought exercise to go through. That post talks about the trade offs to doing an HTML5 mobile app (i.e. a mobile app that's basically a browser utilizing HTML5) versus a native mobile app. In my experience people using mobile apps expect native experiences and HTML5 just can't handle that well. One other thing to consider as well is that it isn't an all or nothing choice. You can have parts of your app using Native and other parts using HTML5.
One last area to consider in picking a strategy are single language cross compilation tools like RhoMobile, Titanium, Xamarin, and PhoneGap. While these tools offer a lower barrier to entry into the mobile space they come with a few trade offs that are very important to be aware of. I say they come with a lower barrier of entry because they require you to only learn/use one programming language/platform in order to target multiple mobile platforms.
Pros:
- Lower barrier of entry as there is only one tool/framework.
- Single codebase.
- Abstracted interaction with hardware.
Cons:
- Vendor lock in. Once you start down the path of using a tool like Xamarin's you're essentially locked in to that tool forever for your mobile app unless you re-write the app from the ground up using the native language or another tool. The cost for this would be tremendous and rises as you add features to your mobile apps.
- In most cases, you're dealing with the "lowest common denominator" issue in your code base. I.e. in order to maintain a single code base without having to fork (the big sell for these tools/frameworks) you can't use features or sensors that aren't available on ALL target devices.
- The types of developers you hire for these platforms aren't of the same caliber as those that write native code using the native frameworks. This may not sound important but IMO it's actually the most important. You want developers that "think" in terms of the platform that you're targeting. The iOS platform is VERY different from the Android platform with is VERY different from the Windows Mobile platform. What works well on one, often does not work well on the others. The patterns used on one platform do not often solve the same problems on the others (this is often the case with iOS and Android). You want developers that can think in the mindset of the target rather than the framework being used.
- These frameworks remove the "built for this device" feel of your app. Your app should not only feel native on the device it's being used on but it should feel like the device was built for your app. When you use a generic one size fits all tool to build your mobile platform you can't take advantage of the nuances of each platform. For example iOS uses a "tabs at the bottom" metaphor whereas Android uses a tabs at the top metaphor and Windows uses a "don't use tabs because we don't give you the ability to" metaphor.
No comments:
Post a Comment