Native Mobile ATG Applications

In a recent blog post, I gave an overview of some of the possible ways to deliver ATG/Oracle Commerce sites to mobile users. I’d like to expand on the subject of ATG implementations in a mobile app. I, for one, enjoy shopping on a native mobile app much more than a mobile site, and I know I’m not alone. Things like Apple Pay are only going to drive eCommerce into fully native applications. I would like to dig deeper.

With the advent of smartphones, the design patterns for applications have greatly changed.  Compared to traditional desktop/laptop environments, mobile environments have these constraints:

• Less-powerful hardware
• Smaller displays
• Slower networks, costlier bandwidth. You can’t assume all users will be on their home wifi all the time.

To account for these constraints, a new wave of methods to deliver content to mobile users has emerged. A good mobile application does the following:

• Lightweights pages as possible
• Reduces outward HTTP requests
• Only transfers what you need

The end result is an application that uses REST web services, usually in JSON, to exchange data with the main application. This is a drastic depart from traditional web design patterns, particularly ATG, which depend on round-trips to the application server for most interactions with the site.

A modern native app comes with *almost* all of the things it needs to function, except one thing, the DATA! For that we use a REST API to communicate with the app provider. By using this architecture, we can reduce the number and size of HTTP requests to the app provider.

Prior to ATG 9, the REST module that enabled this functionality was not available. While it has been around for a while, not many people are aware of its benefits. Furthermore, the number of brands writing native mobile applications that are backed by ATG/Oracle Commerce is very limited.

Because of the limited implementations of native ATG mobile applications, there isn’t a gold standard for doing things. Since the Commerce Reference Store 10, we have been given a working example of a native mobile ATG application. That app, and essentially all other native ATG apps from any mobile device follow the REST-based structure outlined below.

When you go out to write a native ATG application, you need to write more of less two components:

• A layer to interact with the ATG REST web services component of your site. This layer makes the HTTP calls and does data binding/unbinding.
• A layer of device-specific code that displays and controls the interaction with the app. This is essentially the entire app minus the data that comes from the above layer.

The Commerce Reference Store iOS app does more or less just this. That’s good, and fine, and it works great, however what if you want to deploy to iOS and Android? What if a year later you want to add the Windows Phone and Blackberry? The bigger problem with native mobile application development is making them portable across different operating systems. The Commerce Reference Store iOS app to me seemed like a proof-of-concept, but only iOS specific.

As far as making native mobile applications that work cross-platform, there are two camps most solutions fit into.

Hybrid Apps

For virtually all mobile platforms, an app can open up a bundled browser inside to display content from anywhere. In iOS this is called UIWebView and in Android, this is called WebView. This allows application developers to write all of their code in HTML/Javascript/CSS, which is what they know best. With this, you can write one application in HTML/Javascript/CSS, and it will work without having to know much about the underlying “nativeness” of the application.

Many native apps today are built using this methodology. Many frameworks exist to smooth over the quirks between mobile platforms in this fashion. They work to hook into and expose native features of the mobile devices (like contacts, camera, notifications etc). A popular option is PhoneGap, which has a strong selection of platforms and operations. The basic idea of these frameworks is shown above.

The biggest downside of this native application development method is that it’s not as fast as it could be. You’re still making trips to the far server for more data, and most of the app is running on Javascript, which is never going to be faster than a lower-level compiled language.

For eCommerce, the speed of the app is particularly of interest. As the time of a page load increases, the conversion rate goes the other direction. A webview approach is certainly a valid one, but may not be optimal for eCommerce (ATG/Oracle Commerce).

Bridging with C++

Another rather popular method people have been adapting is to pack as much of their application logic into custom C++ libraries as possible, and only writing a small amount of platform-specific code for the things that can’t be shared. This “shim” that has to be added for each platform would support much of the UI, as well as hardware-specific functions like interacting with Google Wallet, Apple Pay and Touch ID.

Why C++?

Because virtually any device ever created can deal with C/C++. You can write a lot of iOS, Android and Windows Phone in C++. You’re probably wondering about Java, however a JVM is not guaranteed for all mobile platforms.

In the context of a native ATG application, writing a common library in C++ allows portability and high performance, but comes with the need to write a baseline amount of platform-specific code.   If you’re targeting iOS and Android (let’s be honest), that work may be worth it for the native performance all the way around.

Closing Thoughts

Porting an ATG application over to a native mobile platform can take any of the routes I’ve discussed. In the long run, I don’t see value in the CRS approach of a platform-specific full implementation. It may have been a proof-of-concept, so I’ll give it some slack.

The best bet is to plan for the future and adapt an application strategy that can easily be moved between platforms without sacrificing too much performance or development and upkeep time. It’s always going to be a tradeoff between these factors.

One final factor to consider when making this decision is how fast mobile application architecture is moving. Consider how far we’ve come since only 2007 when the first iPhone was released. In another 7 years, the landscape will look much different. The bonus to writing shared application libraries in C++ as discussed is that native code is never going to be obsolete, whereas something like webview could drastically change.