The Best Way to Leap into Mobile Development [Part 2]
The Best Way to Leap into Mobile Development [Part 2]
Join the DZone community and get the full member experience.Join For Free
Get the Edge with a Professional Java IDE. 30-day free trial.
Previously, Actuate’s Daniel Melcher (seen above making a 17-story bungee jump) shared his thoughts on the differences between consumer and enterprise mobile apps and identified some trends in mobile app development. Today, he writes about the tools, techniques and expectations mobile developers need to succeed.
By Daniel Melcher
But the development model you choose is just as important – maybe more important – than the tools. The choices are Native, Mobile Web, Hybrid, and Native-Hybrid, and you can read more about them here. The Native-Hybrid model rules in enterprise mobile apps because it delivers the best balance between device functionality and platform independence.
Native-Hybrid works like this: Developers create a native app specific to the mobile platform (Android and iOS, typically), and within that app they build a component that communicates over the Internet with a server to grab content and functionality. That content is transmitted to the app in HTML form and displayed in a WebView object – basically, a web browser built seamlessly into the native app.
This development model places security (which most enterprises require above all else) within the native portion of the app, and also enables the app to tap into mobile features like the GPS and camera. But because much of the data-driven work is done on the server side, the mobile network and processor get a lighter load, and the content is accessible and flexible for a range of devices. Another benefit is that many software updates can be done on the server side, meaning your users don’t have to constantly download and update to add new features.
Native-Hybrid dominates now, but things can change. Developers are able to build pure browser-based apps that leverage device functionality using jQuery mobile – for example, such apps can detect which device the user has, or activate functions like location awareness. This is in early stages, though, and most enterprises still choose the Native-Hybrid model and Web services.
Getting Some REST
The biggest reason enterprise mobile developers choose the Native-Hybrid model with Web Services is the same reason why Web Services are important to desktop apps: language- and platform-independence. Web Services accept input parameters – that is, selections made by your mobile users – and return information based on those parameters. That information can be used in an app, and it doesn’t matter whether you’re doing this through Android or iOS.
Because as we noted earlier, the key to a successful enterprise mobile app is to put as much functionality as you can on the server. Then the native device that displays the data doesn’t really matter. The device acts as a security shell, and the server side takes care of all the multiple data source connections and building the overview. The server can even build the display for WebView.
Another nice thing about using Web Services in this scenario is that you can build your functionality once, and then serve many types of end-user platforms – including conventional apps, desktop browsers and mobile apps – without making changes.
With all this in mind, the question becomes this: What’s the best way to consume Web Services in a mobile app? Not so long ago, you had to include a library (like Axis2) to create stub classes. This method gave application developers lots of capabilities – for example, once the stub classes are created, the library then marshals the web services requests, retrieves the content and puts it in proper form for the application. This is fine on a desktop computer with a fast connection, on mobile devices it’s a lot of overhead.
Some Closing Thoughts
Everything I’ve written up till now has been generalizations, but developers know that each enterprise – and each enterprise app – has unique needs and requirements. Their audiences are smaller, and their goals are different: Companies don’t post their internal corporate apps on a public app store, invite the masses to try them, and expect to rack up five-star reviews. That’s one reason why enterprise apps have come later in the mobile app game: They’re intended for a smaller number of people, so the cost per user can be high. But those costs can be justified when mobile apps deliver productivity benefits and user engagement.
The gap between consumer and enterprise apps is closing, thanks to greater understanding of the ways people use mobility and evolving technologies for app creation. And also evolving mindsets: When developers make mobile apps for consumers, they typically try to get functionality as close to the device as they can. But as we’ve noted, enterprise mobile developers look at the overall app architecture differently: Their goal should be to put as much functionality on the server as possible, and just use the mobile app as a container. That way, functionality on the server can be reused in other mobile apps (remember, mobile apps are often task-specific) as well as in desktop and browser-based apps.
To make that happen, vendors need to provide code that conforms to (or establishes) best practices. Developers should demand this – especially when it comes to security – because quality vendor-supplied and -tested code speeds up mobile development and makes apps more reliable. Developers need to thoroughly check out a vendor’s APIs, as well as the related documentation, examples and extensions. Are they thorough and complete, or oversimplified and untested?
Enterprise mobile developers need answers to those questions, because they have a long road ahead of them. Fortunately, there are lots of opportunities along that road – opportunities to create great apps that help your organizations perform and grow. So I encourage you to take what you’ve learned here, dive in, and get started on your own enterprise mobile apps. Do this fearlessly, and have gentle confidence that things will go well and result in a happy outcome.
Dan Melcher is an Internet Application Architect at Actuate.
Published at DZone with permission of Michael Singer , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.