• 아티클

May 2014

Volume 29 Number 5

Modern Apps : Design a Cross-Platform Modern App Architecture

Rachel Appel | May 2014

Rachel AppelWhether you’re designing a project from scratch or modifying an existing solution, it’s important to know the landscape of the modern app. That means discerning which devices, OSes and browsers are out there that need attention. And “devices” doesn’t just mean smartphones, either—that includes tablets, PCs and large desktop screens. Smartphone sales still outnumber the sales of every other type of device, however. Some developers might even have to consider wearable devices as part of their cross-platform architecture.

The bottom line is that writing software these days means writing for a multitude of devices. The primary goal is to share as much code as possible across the various platforms so you have to write the least amount of code. This will help you get the product or app shipped more quickly. It will also be less prone to bugs caused by rewriting the same logic in different languages.

Cross-Platform Device Development

The manner in which you approach cross-platform development will depend on the type of software you already have in place. If you have a Web site from which you want to share content, a hybrid solution might be best. If it’s a mature site, you could convert it to a responsive design and support mobile devices. You could forgo the mobile site all together and simply provide a Web site and separate companion native apps. Another factor to consider is whether the app is just another way to present the site’s content or if it can stand alone as its own idea.

Build your mobile site first, and then build the native apps. While you develop the native apps, the mobile site can serve as the app until you’ve covered all the platforms. Those with sites already up and running may need to natively take that content and function to each device. You can continue to grow your mobile user base while developing native apps this way. When you’re ready to write your native apps, you might need help deciding which language to use, so be sure to check out my September 2013 column, “Understanding Your Language Choices for Developing Modern Apps” (msdn.microsoft.com/magazine/dn385713).

While it’s a popular notion to start developing for the biggest platform or the one with the most device sales, sometimes it’s a better business decision to start with the platform that has features running parallel with your requirements. For example, a fitness app that logs food and exercise might have a requirement to show a summary of your meals and activities—myFitnessPal is a good example of this on Windows Phone. This kind of data is perfect for a Live Tile, which is available only on the Windows platform.

You can figure out if your requirements match the platform by listing all your major app features. Review each by verifying it’s supported on each platform and possibly to what extent. Where you’ll see divergence is with hardware-specific features, such as the camera or OS features such as tiles or voice recognition. Your architectural options from a 30,000-foot view set you up to go in one of three directions: native apps, hybrid apps or HTML5 mobile Web.

Native This means moving full steam ahead on a separate app for each platform. The platforms are likely to be Windows Phone 8, iOS and Android. For some, platforms such as BlackBerry still apply. Each app will take full advantage of the specific features each of the individual platforms provides. Native app performance is great, but, of course, you must remember to write solid and clean code as performance degrades quickly when you’re not conscientious. You’ll have to write at least the native app UI individually for each platform, so the cost per platform rises to be the most expensive of all these options.

Hybrid Somewhere in that grey area between native and Web is the hybrid app. Hybrid apps usually integrate content from an existing Web site into an app for native packing and deployment. This is especially useful to quickly secure a slot in any of the app stores and have a presence there, perhaps while working on a full native app for that platform. Performance is notoriously slower than with native and Web apps, as hybrid apps are generally constructed by wrapping existing HTML with a container. For example, on the Windows Phone, this is a WebBrowser control. Any time there’s an extra layer, there’s also potential for performance issues.

The trade-off, however, is speedy deployment on a native platform. Creating hybrid apps requires you use any of the following tools:

  • Apache Cordova/PhoneGap
  • Visual Studio Windows Phone HTML5 project template
  • Telerik AppBuilder (formerly Icenium)
  • Xamarin Studio

Because of their nature, hybrid apps wrap Web content using the WebBrowser control (keeping with the Windows Phone example), which is a XAML element:

<phone:WebBrowser x:Name="Browser"
HorizontalAlignment="Stretch"
VerticalAlignment="Stretch"
Loaded="Browser_Loaded"
NavigationFailed="Browser_NavigationFailed" />

That’s all you need to get started building a hybrid app. On other platforms, the concepts are the same, although the controls might be different. Be cautious while building hybrid apps, as they might not have access or privileges to perform actions that a native app would. This is because of the potential for rogue script from the Web to execute on the client. That’s why HTML apps have many of the same restrictions.

When you build hybrid apps, you can use the Telerik AppBuilder or Apache Cordova in lieu of Visual Studio projects. These third-party tools help close the gaps between the hybrid Web feel and a native look and feel of your app.

HTML5 The benefit of going this route is the immediate wide availability the HTML5 specification brings to the table. Mobile Web sites may have far reach, but lack the native look and feel users want and would normally expect from native apps. Also, an HTML5 app might not be able to access some of the hardware-specific features of its target platforms, such as the Webcam or accelerometer.

HTML5 has the lowest cost per platform, as you should be able to write once and run on most browsers. Some mobile browsers, however, aren’t up-to-date with standards support. That can be a major problem when developing HTML5 apps. If native features are important to your project, the lack of access in this area could determine that you go with native apps entirely.

While HTML5 boasts wide availability, keep in mind that in a sense, developing for the Web is similar to developing native apps. You do need to concern yourself with supporting a number of browsers. Like device development, Web developers target those browsers with the most users—Internet Explorer, Chrome, FireFox and Opera.

You want to design rich UXes on the client side on various devices, and you can’t reuse that specific device code. The following native features are unlikely to behave consistently or be available across platforms:

  • Push Notifications
  • Wallet
  • Near Field Communication (NFC)
  • Multitasking/multithreading
  • Speech
  • Navigation Schemes
  • Dialogs

In hybrid or HTML5 client apps, don’t rely on access to these native-specific attributes. If features like these are part of your app requirements, you’ll need to go the all-native route.

Architect Cross-Platform Solutions

Determining which platforms you’ll support is just one decision in the app landscape. You must also design the solution, and take into consideration things such as time to market and for which platform to develop first. How to share as much code as possible between apps is also an important consideration.

The back-end Web services and APIs work well in a cross-­platform scenario because every platform supports HTTP. Using layers of services in the back end means you only need to write the code for those services once.

As far as expanding the architecture to focus on the client, you’ll want to share as much code as possible. You can easily code on Windows 8 and Windows Phone with Portable Class Libraries (PCLs), but that leaves out other platforms such as Android and iOS. You can share code across Windows 8, Windows Phone, Android, and iOS by writing in C# and using Xamarin tools to cross-compile.

The point of going native is so users get the same look and feel of the native platform. While tools such as Xamarin will let you share some code in the UI layer, you’ll get the best UX results if you handcraft each UI separately. That usually means modifying the generated Xamarin code. This is a good time to add any platform-specific features, so users on each platform get a customized experience.

The App Code Layer maps to the controller or ViewModel parts of the Model-View-Controller (MVC) or Model-View-ViewModel (MVVM) patterns. The UI layer maps to the View in both MVC and MVVM. The Model, of course, is the data representation. This might be JavaScript classes that map to database objects in Local Storage, or it might map to remote schema back in the database. Local data isn’t something you’d normally share between devices, as it often includes device-specific information.

The path of least resistance in building your solution is to start with the back-end layers first, then create a Web site, then the apps. This way you get something out the door to the widest range possible. On the apps side, you’ll need to determine which to build first and if any should be your primary platform.

I’m fond of the Windows 8/Windows RT/Windows Phone platform myself and think it (specifically Windows Phone) has the best UX of all the devices available. That’s not just because I’ve worked for Microsoft. I think the iPhone has a good UX, too. Features such as Tiles and top-of-the-line Nokia cameras are convincing reasons to make Windows Phone your feature platform for anyone who needs that kind of functionality in an app. Also, Windows Phone seamlessly manages and merges your contacts, calendar and other vital data across Windows Phone-based devices with the built-in cloud-based people and calendar apps.

Wrapping Up

With the advent of the bring your own device (BYOD) movement in workplaces everywhere, native app development has become commonplace. As you can see, there are many variables and things to consider when building apps that can affect your success. Unless you’re working for a corporation that requires a standard desktop client, then I’d advise against it. This amounts to not being the first app on that platform.

If you have a generous budget and personnel, plus an extended time frame to build your solution, you can create a Web site with a mobile version and a complete set of native apps. That means you’re providing every possible way to access your services and data. Of course, this route is the most work and the most expensive.

Rachel Appel is a consultant, author, mentor and former Microsoft employee with more than 20 years of experience in the IT industry. She speaks at top industry conferences such as Visual Studio Live!, DevConnections, MIX and more. Her expertise lies within developing solutions that align business and technology focusing on the Microsoft dev stack and open Web. For more about Appel, visit her Web site at rachelappel.com.

Thanks to the following technical experts for reviewing this article: Frank La Vigne (Microsoft) and Wally McClure (Scalable Development)