Mobile Application Development Theorems

Mobility is so ubiquitous that it is almost not even a separate thing anymore. I have had some experience building mobile apps and wanted to ponder some self-proclaimed theorems which are outlined in this article.

Mobility is so ubiquitous that it is almost not even a separate thing anymore. This creates a challenge for enterprises that offer BYOD mobile devices and corporate data access. How do you enable the mobile workforce with enterprise applications? One way is to roll your own mobile application to get the necessary data into the mobile user’s hands. I have had some experience with this and wanted to ponder some self-proclaimed theorems which are outlined below.

Theorem #1

Mobile applications developed for native devices with native code are superior.

The following is an example of what you might need to build native mobile applications for various mobile devices:

Platform Development Framework Language IDE
iOS iOS SDK Objective-C Cocoa, Xcode
Android Android SDK, Android NDK Java, C/C++ Eclipse, NetBeans, IntelliJ IDEA
Windows Phone .NET C# and others Visual Studio
Window 8 Metro Style Apps WinRT C++ / C# / VB.NET / Javascript Visual Studio
Blackberry Java ME + Optional Packages + API extensions Java Eclipse
ChromeOS Webkit HTML / CSS / Javascript Many

Unfortunately, BYOD makes Theorem #1 hard. If you are going to go the native code route, you have to maintain a separate code base (with separate IDE’s) for all possible devices your users will bring in. There are some other frameworks that I’ll talk about in another article that help with this, but there is always a tradeoff.

Theorem #2

Apps that Look Better are Perceived to be Better.

Looks matter. Period. If you give an application to a user that has limited functionality but looks sexy, that application will be perceived as better than an application that has more functionality but is ugly. You know it’s true.

Therefore, do yourself a favor and use a framework like one of the following:

These frameworks make it easy to make it look like you know what you are doing (at lease design-wise)

Theorem #3

Inverse Proportions are Everywhere.

inverse proportions

There is always a tradeoff somewhere. Referencing the picture above, think about painting a room. I can paint a room with a paintbrush and not waste too much paint. However, to speed things up, I use a paint roller and waste more paint. Therefore, the ease/speed in which I paint a room is inversely proportional to how much paint I waste.

The same thing is true for security. If everyone in the world had a public IP address with wide open ports, things would be pretty easy if there were not bad guys/girls out here. In the real world, there are bad guys/girls out there, so we have to attempt to keep them out. The security measures can be a burden on the user. Therefore, security is inversely proportional to usability.

That last picture up there is the icon for PhoneGap. PhoneGap is one of many frameworks that attempt to make Theorem #1 easier. You can read an introduction to PhoneGap here.

There, of course, is a tradeoff. Building mobile apps with abstraction layers like PhoneGap introduce translation. You may not have access to all mobile device features immediately, there can be a performance tax, and apps will tend to be bigger. Not all mobile frameworks are created equal and I will talk about some pros and cons of different frameworks (like Xamarin, Citrix Mobile SDK for Windows Apps, Intel XDK, etc.) in a separate article.

 

Wrapping Up

So, there you have it. My self-proclaimed theorems for mobile app development. Agree? Disagree? Or, have something else to add? Just leave a comment below.

 

Introduction to PhoneGap

Your end users expect mobile access to enterprise resources now. Unfortunately, our traditional remote access methods do not lend themselves easily to mobile form factors. So, we are left with the choice to use 3rd party apps, “mobilize” existing apps, or build our own. This article will address one of the players aimed at helping you build your own mobile apps with less effort.

Mobile Enterprise Apps – Virtualize, Buy, or Build?

When it comes to mobile enterprise applications, you basically have 3 choices:

  1. Virtualize what you have (via Citrix HDX, RDP, VMware PCoIP, etc.)
  2. Buy something from a 3rd party
  3. Build something yourself

There are use cases for each of these, but I’m going to focus on one way to build something yourself.  In this case, I’m going to cover PhoneGap.

 

What is PhoneGap?

PhoneGap is a framework for building mobile applications using only HTML, CSS, and Javascript.  This removes the complexity of using multiple programming languages for the various mobile platforms out there.  The PhoneGap framework gives developers access to almost all of the device’s features such as GPS, Camera, Accelerometer, Notifications, etc. via the included Javascript library.

The easiest way I think of it is like this – PhoneGap is a specialized web browser without a user interface.  There is a specialized web browser for each native platform – iOS, Android, Windows Phone, Blackberrry, etc.  This allows you to reuse your code across platforms; however, this does not allow you to use one IDE for all platforms.  Each PhoneGap app you build gets complied into this chrome-less browser and delivered just like any other native application.  The end result is an individual .ipa (for iOS), .apk (for Android), .xap (for Windows Phone), etc..  Therefore, you still have the ability to use all your EMM and MAM tools you may already have to manage these apps. Each time you build a new PhoneGap app, you get a new .ipa, .apk, .xap, etc. that includes the chrome-less browser and your HTML, CSS, JavaScript, etc.

PhoneGap

What’s needed to develop with PhoneGap?

You still need to use the various platform IDE’s to develop an app with PhoneGap.  For instance, I developed a simple app for iPhone and Android.  For iPhone, I used Xcode to create and compile the PhoneGap application.  For Android, I used Eclipse to create and compile the application.  I had to set up each IDE to use the PhoneGap framework, but that is all documented pretty well.

I started with Xcode and got things working liked I wanted for iPhone.  Then, I literally just copied and pasted my HTML, CSS, and images over to Eclipse and the Android app just worked.  My app is very simple, but here are the results:

What is the catch?

PhoneGap is free.  Even though Adobe acquired PhoneGap in 2011, the PhoneGap code was contributed to the Apache Software Foundation (ASF) under the name Apache Cordova and graduated to top-level project status in October 2012.

I have noticed that some PhoneGap apps seem to run a little sluggish when dealing with animations as compared to traditional apps.  I’m assuming this is due to the chrome-less browser nature of PhoneGap applications.  However, when dealing with enterprise applications, I do not see this as being a big issue.

The other issue I see for enterprises (and this is not unique to PhoneGap) is data access.  Your application is really just another front end for data.  You have to provide enterprise data access somehow.  This can be done via VPN, or using local device storage and sync strategies.  Like I said, this isn’t unique to PhoneGap, but it is something to think about.

Conclusion

PhoneGap lowers the bar of entry into “native” device applications because there are a lot of HTML, CSS, JavaScript developers out there.  Oftentimes, enterprises may already employ people with expertise in these areas.  If not, it is more budget-friendly to hire a Web developer as opposed to developers that specialize in Objective-C and/or Java and/or .Net languages.  You get the benefits of maintaining one code base across multiple devices.  All of your EMM/MAM products should work with PhoneGap applications.

On the contrast, you are not developing “real native” code and devices may come out with features faster than the PhoneGap framework can accommodate.  You still have a data problem.  If your app requires a lot of fancy animated graphics, then PhoneGap may or may not suit your needs.

So, there you go.  If you have experience with PhoneGap or just something to add, feel free to leave a comment below.