Building a mobile app: The tools

Now that we've taken a look at the various aspects of building a mobile app, I thought I would end the series with a helpful resource guide.

FireOS

• Phone
• Getting started resources.
• Dynamic Perspective
• Active Widgets
• Foundation Controls
• FireFly
• Kindle
• Getting started resources.

iOS

• Building for iOS.
• Human interface guidelines.
• Build and test iOS applications using XCTool.
• Building static libraries for iOS.
• Sharing resources across applications using bundles.
• App Store review guidelines.
• Understanding iOS crash reports.

Android

• Build from the command line using Ant.
• Build from the command line or Android Studio using Gradle.
• Avoid dealing with fragmentation by using Google Play Services.
• Https and SSL.
• Tablet app quality checklist.
• Android design.

Windows Mobile

• MSDN resources.
• How to create your first Windows Phone app.
• Windows Phone Emulator.
• Nokia's Windows Phone useful links.

HTML5

• Smashing Magazine: Best of both worlds.
• Design your own mobile game.
• The Architect's Guide to Choosing Between HTML5 or Native Mobile Apps.

Building a mobile app: Picking a strategy

In my last post, Building a mobile app: Mobiles unique challenges, I explained some of the unique challenges that mobile application developers face. In this post I'd like to talk a little about picking a mobile implementation strategy.

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.

Building a mobile app: mobile's unique challanges

In my last post, Building a mobile app: Understanding the problem space, I introduced us to the problem space of building a mobile app. In this post I'd like to talk about some of the unique challenges that we face when developing mobile applications. These challenges apply to mobile in general and aren't really specific to any particular platform. It's important to understand these challenges before you start to build a mobile architecture or add mobile into your existing architecture.

Data is one of the most precious parts of any mobile application. Whether your application is a game, a productivity tool, a utility or something else, it's going to be consuming data of some sort from somewhere. You really have three options when it comes to data. First is to bake all necessary data into the app. The second is to download all necessary data from the internet. And the third is to use a hybrid approach and have some data baked into the app and some downloaded.

The first approach is the easiest as the app becomes self contained. Most platforms have even made it easy to bake certain types of data into our apps like localized strings or images. Structured data is more difficult to bake into the app as it tends to increase the apps size and can cause lag in the app as it's read from disk to memory. Using this approach requires an app update anytime the data needs to change.

The second approach solves the app update problem by storing all data outside of the app. Thus, every user always has the most up to date data available. But this decreases the apps usefulness. It means that at a minimum the user must be connected to the internet when they first run the app. It also means that the app needs to be built with a (sometimes complex) caching strategy in order to make the app usable in an offline or disconnected state. Finally, while the application package size will be smaller it means that users will have higher data usage as they use the app because they'll be downloading content for the app at the rate in which the data changes.

The last approach is probably the most common. It allows the app to be designed to work offline while also allowing the app creators to update content without having to provide an over the air update to the app. But this too comes with some challenges. It means having to create a caching and update strategy for your content. If you get that wrong it means that your users may get old or incorrect data while disconnected. This strategy requires more diligence in responding to the connection state. It also means being diligent about making your over the air content backwards compatible to any version of the app that may still be in the wild.

App updates are another unique challenge that mobile developers face. Not only does the app creator not control whether the user will install an app update, they don't control whether the user will install a system update either. What this means is that applications must be feature aware. Being feature aware means being able to update the app to take advantage of new system functionality or new data that is needed by system changes without breaking the existing apps out in the ecosystem. Even in a world where everyone updates to the latest version of your app they don't do it all at once. So there's always going to be a period, however brief, where you will have multiple versions of your app in the wild at any given time.

Interaction is another challenge that, while not unique to mobile, is more difficult on mobile. Each different mobile platform (FireOS, Android, iOS, Windows Phone, and etc..) comes with its own set of interactions, workflows, and user expectations. Your app should feel natural on whatever platform it's running on. Which means either slightly or dramatically tailoring the user experience and interaction design for each platform.

The last mobile challenge I'd like to mention is hardware. There are some types of hardware that are common on most mobile devices like an accelerometer, camera, or WiFi. But then there are some like dynamic perspective, external storage, or gyrascopes which are not going to be available on all devices. And lastly there are some that are going to be common on all devices like GPS or memory whose quality, size, or accuracy may vary greatly.

Building a mobile app: Understanding the problem space

I'd like to start a brief new series on building a mobile app. I think nowadays people think of mobile apps as a destination, a place in and of itself. A target for specific types of content. A place where specific types of content are created and made available. That may have been true several years ago when the mobile problem space was in its infancy, but it's not true now.

Take games for instance. 30, 20, and even 10 years ago an electronic game was predominantly self contained. You had a disk, you copied the bits to memory, and you interacted with those bits in memory in a fixed location. But over the last 10 years even games have changed. You now interact with bits running on other peoples computers and on server farms throughout the world. The game you start with is often not the game you end up with as levels and secrets are unlocked and downloaded. Today, if you were to sit down and write a mobile game you may start by thinking about which devices you are going to support, or what type of game play you want to offer. But it's no longer enough to ask those questions alone.

We're now at a point in time where everything is connected. But we still think about mobile as an end in and of itself. But that's the wrong way to think about it in my opinion. I'm not saying that you should ignore the unique challenges that the mobile problem space throws at you. I'm just saying that when tackling those unique challenges you have to come from a different frame of mind.

Mobile needs to be thought of as a conduit for transient data. Data has no ultimate home.  It moves and changes with us. Different contexts provide different aspects and insights. The data's meaning and relevance changes given the context from which we choose to consume or create from. Our data is part of a larger ecosystem for which mobile is just one end-point.

Today we think and talk about that ecosystem in terms of The Cloud. The predominant conversation around the cloud is as a final resting place for our data. I don't think that's the cloud's intention, but it's easy to approach it that way after decades of thinking about software that way. But I think that's an incorrect way to think about it. The Cloud is important, necessary even. But it's not a resting place for our data. The cloud is the glue that allows our data to be forever transient and disconnected.

Once you understand that you can start to see mobile for what it really is and can be in the correct frame of mind to start thinking about building a mobile app. When you understand that a mobile app isn't an end in and of itself but is instead a medium from which to consume and create transient content you can begin to ask the correct questions that will make your app relevant and useful to your consumers.

So what is the mobile problem space? It's trying to present content on a variety of screens, with a variety of inputs, in an occasionally connected state. It's dealing with a variety of hardware in such a way that the user doesn't have to think about it. It's about ecosystems that have their own user interaction paradigms and feeling familiar and friendly.

The mobile problem space is also about thinking about efficient data usage. But also thinking about how we can consume data in small chunks during brief periods of time, like while we're standing in line or sitting in a waiting room, while also having the ability to immerse ourselves for hours.

The mobile problem space is about presenting data in such a way that the important stuff jumps out at you while still giving you the ability to explore and immerse yourself in discovery. It's about understanding that we expect an app to remember the state of our data and the context around how we were interacting with it regardless of how long it may have been between uses or reboots. It's about being interrupted and multitasking.

As you can see, understanding the mobile problem space needs to begin well before you consider technologies and platforms or programming languages and data storage.