By Carlos Chang on Apr 14, 2014
Author: Shay Shmeltzer, Director of Product Management and Strategy
When talking to customers about their mobile development plan, I can't help but feel a slight flashback feeling to the type of discussion we had when people got serious about Web development 10-15 years ago. While mobile is definitelly a new technology, there is no reason to repeat the mistakes of the past and not to learn from the experience we gathered in the application development community. Here are three things that I noticed were solved in the past, and where the approach to the solution can be applied in the new mobile paradigm.
Cross Platform Development
Back in the 90s there was no single OS that controled the server world. Windows, Linux, and various flavors of Unix were mixed together in various IT shops. Today this is the situation on the mobile client side - there is no single mobile OS that rules the market. There are two clear front runner - iOS and Android - but others are in the mix too, and any organization who adopts the BYOD (Bring Your Own Device) approach will need to target more than a single platform.
So how do you solve the need to develop with a single language and run on multiple platforms?
In the 90s we solved this with Java, a language that ran inside a container that was available for each platform. Today we take a similar approach for mobile apps - using an approach called hybrid mobile - relying on a container that runs your mobile application on the mobile OS. With Oracle's Mobile development framework, we are providing a container that runs a single mobile app on multiple platforms. By the way, one part of our container is a mobile-flavored JVM that runs your business logic on the mobile device. This concept of a container that runs your code, is also extended to the UI layer where our framework uses the Webview component to render cross device UI layers.
By picking up this approach you are able to reduce your development effort to building just a single application and running it on multiple devices.
A fear we sometime hear is that this type of in-container apps will be slow because of the container overhead. Again this is a flashback to the early days of Java, when there was a fear that because of its architecture it won't be able to handle the performance load required from enterprise apps. This fear has completely passed now, and Java powers every type of system. This is the same thing we are seeing in the mobile space. While it is true that there is a slight edge to native apps in terms of performance - the difference compared to the hybrid approach is so negligible that you'll only notice it if you were trying to build a real-time gaming system. For enterprise style applications the hybrid approach is performing great. In fact if we encounter slow hybrid apps - the problem is almost always in the way that the app talks to the backend, rather than at the client side.
Architecture and Modularity
With our mobile framework, we incorporated the Model-View-Controller (MVC) design pattern into the way we build mobile applications. User interfaces are defined in one file, business logic and data access in another. Making your application easier to maintain. In addition we put a lot of effort into enabling reusability with the ability to package functionality you build as "features", and then integrating various features into a single application, or reusing features in other applications.
Simplifying UI Development
This approach is faster because it reduced coding drastically. With a rich set of components - like the set of over 60 components provided by Oracle's mobile framework - developers can simply pick and arrange components on the page to create advanced UIs.
In addition, UI technology has a tendency to change and evolve rapidly. For example in the world of web development Flash was the "de-facto" standard for rich internet application just 5 years ago - but today it is rarely used anymore for these type of application and HTML5 is replacing it.
The nice thing about working with components that generate markup language is that the markup that is being generated can be changed or evolved over time. We already did this in our ADF Faces components - components that started by generating PNG files evolved to generate Flash and today are generating HTML5 markup. All through those changes there was no need to re-write the application that were created with those components.
Basically using components can provide protection from technology changes down the road - and this is true for mobile apps too.
A wise man is the one who learns from others mistakes. Make sure that when you consider your mobile development approach you are wise. Learn the lessons of the past and apply them to the new world - choose your development framework wisely.
More Mobile? Checkout the mobile dedicated blog at blogs.oracle.com/mobile