Isn't it amazing how quickly those mobile development teams manage to bring their mobile applications to life? It's not unusual for an enterprise Java application to take a year or longer to architect, design, build, test and deploy, yet in that same time frame, mobile developers will have an identical application not only hosted in the app store, but they'll likely have deployed two updates as well and a handful of meaningful feature enhancements.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
"If I have a choice between jumping on a mobile project or jumping on an enterprise Java project, I find myself opting for the mobile project," says Jason Tee, an enterprise Java developer and mobile developer based out of Montreal and Toronto. "Enterprise Java projects can get bogged down in the design phase, or developers start losing their motivation after milestone three or four. With mobile applications, it seems that the energy level remains high from start to finish, and there's always a continued focus on getting the software out the door and made available through an app store."
Mobile development teams are struggling just as hard to learn the latest Android or iOS APIs as the typical enterprise developer who is struggling to get up to speed with OSGi or Scala. But there is something inherently easier about developing a native application for a mobile device when compared to bringing together a software project deployed across the Internet.
Mobile development vs. enterprise development
This comparison between mobile and enterprise development isn't intended to ruffle the feathers of the server-side Java developers who are pecking away at their browser-based JSF or SpringMVC applications. The fact is, Android and iOS operating systems are fundamentally different architectures than the miserable one we currently use to deliver Web-based applications, and it's this significant architectural difference that makes it so much easier to develop and deploy a native mobile application. And, yes, as much as we all love the browser-based experience, the underlying architecture is miserable, a fact which is evidenced by all of the failed attempts to fix it, be it Adobe Flash or Microsoft's Silverlight.
With mobile applications, it seems that the energy level remains high from start to finish, and there's always a continued focus on getting the software out the door.
Jason Tee, enterprise Java developer
Android and Apple offerings in the mobile space were never built within the limited confines of hypertext and the http protocol from which our modern Internet browsers elute. The Web was created long before social networking was the norm and before every teen had a preoccupation for sharing pictures and tweeting their every activity.
On the other hand, mobile operating systems have been developed with every modern human-device interaction in mind. Developers of mobile device applications don't have to reinvent the wheel every time they want to perform what has become a standard operation, whether it's accessing an image taken from a camera or uploading a file to an external Dropbox account.
"Android has a different architecture in that it's designed to delegate tasks to other apps," says Ulf Dittmer, a JavaRanch Marshal and head of development and IT at Besser Betreut GmbH, with regards to how developing mobile applications is different from developing for other systems.
"You don't need to write a file selector, because any installed file manager can be used for that," Dittmer said. "You don't need to write an image picker, because you can use the built-in gallery app for that. You don't need to do map stuff because you can delegate to Google Maps or embed it. You don't need to write a search UI because you can tap into the system search, etcetera, etcetera."
Embedded architectures and the benefit of hindsight
Google and Apple both have the benefit of hindsight, meaning the iOS and Android operating systems have been designed from the get-go with the intention of accommodating the manner in which modern mobile gadgets are used. This significant architectural advantage can't be understated. Over at TheServerSide.com, one of the most popular articles, even in 2012, is one written almost ten years ago about how to upload a file using a Web browser. It's a task that is relatively simple when using desktop APIs or native mobile APIs, but it's not at all intuitive over the Web.
Of course, there's more to the speedy and adept manner in which mobile applications are developed than the simple fact that the underlying architecture is better suited to that task. Mobile applications tend to focus on a more discreet set of features than their enterprise counterparts. The mad dash to acquire a presence in the mobile market often means producing a first release with a limited feature set.
The lifecycle of an enterprise application is much different from a mobile app. The expectation is that a Web-based deployment of corporate software will be feature full, and this expectation provides allowances for a lengthier time to market.
"Version lifecycles definitely are much shorter because the mobile app space is so dynamic, so you tend to put out something that addresses a need and then move on to the next thing," said Dittmer.
In the end, though, the success of a project or the ability to bring software releases in on time will never be driven simply by the underlying architecture. Even with the simplest set of requirements and the best set of APIs, a team that has no cohesion, no leadership and no methodology is far less likely to succeed than the one that does. The real key to development is people, not just the platform to which the software is targeted.
Head First Mobile Web by Lyza Danger Gardner
Professional Android 4 Application Development by Reto Meier
Mobile Development with C#: iOS, Android, and Windows Phone by Greg Shackles
What's New in Java 7? by Madhusudhan Konda
The Well-Grounded Java Developer By Martijn Verburg