Over a million developers have joined DZone.

The Best Way to Leap into Mobile Development [Part 2]

· Java Zone

What every Java engineer should know about microservices: Reactive Microservices Architecture. Brought to you in partnership with Lightbend.

DSCN4393

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

At the end of my last blog post I described an enterprise mobile app that could give a sales professional notifications and suggested actions based on several seemingly unrelated facts – geographic location, a calendar opening, and a prospect’s progress through the sales cycle. It’s a compelling idea, but that scenario has a lot of moving parts, making it tough to build an app like that. You have to use the right tools to get relevant data from multiple sources, prepare it for the device, and present it in the right form. To handle complex scenarios like this, enterprise mobile app developers today typically use web services, REST APIs, and JavaScript. (More about why in a few paragraphs.)

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.

So now we have REST APIs, which allow you to get connections to those same Web services via a URL and then use JavaScript to consume them. This means you don’t have to include big libraries in your mobile development efforts. Apps perform better because you don’t need to load libraries into memory, and it’s both easier and quicker to connect to web services. The HTTP connections needed for the REST API are already built into mobile operating systems, so your app has a much lighter footprint. REST APIs have so many benefits that they’re becoming popular with webpage designers and desktop application developers.

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.


Microservices for Java, explained. Revitalize your legacy systems (and your career) with Reactive Microservices Architecture, a free O’Reilly book. Brought to you in partnership with Lightbend.

Topics:

Published at DZone with permission of Michael Singer, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}