Chapter 1

Choosing the Right Architecture

What's In This Chapter?

• Recognizing mobile development challenges
• Evaluating mobile architectures
• Developing for multiple platforms

Enterprise development is changing. If you are like most of the developers we talk to at our corporate clients, you've probably been asked to evaluate one or more mobile development platforms. You may even have been asked to write an application — probably on short notice — to support some business unit or executive who decided your organization needs a mobile application — and needs it now.

Mobile development is different from other areas of enterprise development. You need to have a clear understanding of the challenges that are unique to mobile development, particularly cross-platform mobile development. In this chapter you explore some of the architectural considerations any enterprise developer should think about when making the transition to building mobile applications. You explore (at a high-level) the technical aspects of mobile development, including device connectivity, storage and processor limitations, application deployment, and more. The goal of the discussion is to help guide you down a path to implement a cross-platform mobile architecture that works best for your organization. Each environment is different, and yours is no exception. Making architecture decisions is always a game of trade-offs. This chapter helps you on that journey into mobility and mobile software.

Understanding Mobile Architecture

For software developers, designing and implementing good application architecture is paramount to success. Enterprise software architecture activities must take into consideration myriad concerns when choosing an approach: everything from technology standards to deployment options, potential user profiles, expected user loads — and don't forget scalability, extendibility, and maintainability. Software application architecture is ultimately a game of trade-offs between all these considerations. You often must compromise in one area to accommodate another to arrive at a workable solution. Three considerations may be unfamiliar to most enterprise architects, which represent the most important points to evaluate when architecting mobile applications.

The first consideration is connectivity. Mobile applications are, by definition, mobile. When users carry a device with them wherever they go, there are times, sometimes frequently, when they have no connection. Wireless technologies have come a long way in recent years, but “always connected” is still not a reality. The best you can expect is “usually connected,” meaning more often than not users have a network connection. However, your specific situation may vary greatly depending on the application and the profile of your users.

Mobile devices also exist largely outside of the corporate network, while many enterprise applications are maintained behind the corporate firewall. If you expect mobile users to access your application using their existing cellular service, you'll need to expose your application outside the Local Area Network. Although most enterprises have already addressed this requirement via enterprise web applications, it may present a challenge for mobile applications. If enterprise web applications are for internal use only, the infrastructure to support connectivity over the Internet may not exist, and will need to be procured and configured.

The second consideration is device access. Modern smartphones and tablets have some whiz-bang features that make mobile applications uniquely useful, and fun to write! Geo-location services enable “find near me” features or geo-fencing; accelerometers and gyroscopes enable you to create motion-sensitive applications. Still and video cameras, audio recording and playback, and interactive touch screens can make for fully-immersive multimedia experiences.

Finally, the third — and perhaps the most important consideration — is usability. The smaller form-factors and multitouch interfaces of modern mobile devices represent a shift in user interface design for most enterprise architects. User experience in traditional enterprise applications is often an afterthought — if it's even thought of at all. Mobile applications require a more thoughtful approach, and your design should reflect the best-of-breed applications available in the various mobile app stores.

You should keep these three considerations in mind when evaluating a mobile architecture on other dimensions. These three items represent the most critical points of any evaluation and should take precedence wherever possible to enable a workable mobile architecture. You may decide to compromise on one of these three items for a legitimate architectural reason, but you should be particularly thoughtful when making such a compromise. Understanding the implications of such a decision can mean the difference between success and failure.

Now that you have a better understanding of mobile application architecture, following are some additional considerations that can help you design a solid mobile architecture for your applications.

Connecting to the Network

As mentioned previously, network connectivity is one of the most important considerations when designing a mobile application. Most enterprises have wireless connection options while on premises and offer access to company information via isolated, secure WiFi hotspots. This approach offers a great option for mobile users while they're in the office and may be adequate for many internal applications. This scenario represents the closest achievable approximation of an “always connected” state and can offer great flexibility for your proprietary enterprise mobile applications.

However, more often than not, you face situations that require mobile users to access corporate information and run their applications from outside the tightly controlled and security-minded enterprise wireless network. Mobile users don't just want access to information from the office; they want it at home, in the car, or on the train. They want it when and where they want it; and they expect it to work on their terms. This often represents a significant challenge for any organization when mobilizing its workforce.

This “work from anywhere” attitude requires a mobile enterprise to provide functionality over less-than-reliable public networks. When you make the decision to support this capability, it prompts many more questions regarding what information you can or should provide on the device and what functionality you need in a disconnected state.

For applications that primarily deliver information (that is, executive dashboards, product catalogs, sales brochures), you can use data-caching schemes to maximize the amount of work that a user can complete while disconnected, but if your application requires any transaction processing (for example, field product sales or inventory management), providing disconnected capability is more complex. Users often need to queue transactions on the device for processing at a later time, which may or may not be an acceptable trade-off.

Recognizing Storage and Processor Limitations

The mobile devices of today have come a long way in terms of processing power and storage. Moore's Law remains in effect, and we all benefit from the incredible power available in the palm of our hands. But mobile devices are still resource-constrained when compared to the increasingly scalable cloud environments in place at most large companies.

This constraint becomes an especially important consideration when evaluating application data and data services. Most organizations take a decidedly “outside-in” perspective for enterprise data. Enterprise data services tend to package and present information in ways that closely mirror the back-end data store where the information resides. The ubiquity of relational database systems resulted in service-oriented architectures that deliver information in a highly normalized fashion. Multiple service calls piece together a clear representation of the data required for the application to function. This can result in placing an undue processing load on the device, which can severely impact performance and usability.

Another unfortunate side effect of the easy availability of storage on enterprise servers and desktops is the structure of the presented data. Most enterprise data services use XML, and a majority of those use SOAP to deliver information. XML is a notoriously verbose way to represent data, and many back-end systems use highly descriptive names for the presented data elements. Couple this verbosity with the additional overhead of a SOAP envelope, and storage resources on a mobile device can quickly become overwhelmed, especially when working with large data sets.

To mitigate this risk, you should be diligent about providing the correct amount of information to the device only at the time it is needed. Think carefully about what the user needs to see. Scrolling through a list of 5,000 customers is not a good mobile experience, so think of ways you can partition or filter this information to present it in smaller chunks. Setting up a workflow that organizes customers by country, region, state, and city may result in a few more touches than delivering the entire list at once, but the additional touches might also result in a more responsive application with a smaller resource footprint.

Securing Data on the Device

Consider three areas for data security in your mobile applications: authentication and authorization, data encryption, and data destruction if a device is compromised.

Authentication and Authorization

You can currently accomplish authentication and authorization in most large organizations using an implementation of the Lightweight Directory Access Protocol (LDAP), such as Active Directory. These mechanisms can provide seamless authentication services across applications, but most mobile development platforms lack integration with them, so you need to plan to develop your own authentication scheme to manage access to corporate information.

By taking advantage of unifying technologies, such as Mono, you can create cross-platform single-sign-on (SSO) modules to drop wholesale into your various mobile applications to provide this service. You can standardize authentication using traditional username/password, or RSA hard or soft tokens. You can then embed a token in the header of your service requests, where it is subject to SSL encryption over the wire. You can set these tokens to expire at various intervals to ensure appropriate security and require re-authorization on a periodic basis. Implementing a unified SSO approach in your applications and associated data services is a significant investment in your mobile application strategy, but when correctly done can pay dividends in future development efforts as your mobile application portfolio grows.

Data Encryption

Think of data encryption from two perspectives when designing a mobile architecture: communication encryption and encryption of data at-rest.

To enable communication encryption, various SSL and VPN options are available out-of-the-box with most commercial hosting vendors and services platforms, ensuring a level of encryption adequate for most situations. In addition, most enterprise development platforms, including .NET and Mono, offer flexible cryptography APIs that support the latest algorithms, such as AES256, enabling you to double-encrypt information shared between the device and server if you deem that level of security necessary.

You can use these same cryptography libraries to provide software-level encryption of any data to be cached or stored on the device. Some vendors offer additional encryption capabilities. Apple, for example, offers data protection services in iOS that use a combination of the device passcode and hardware-level encryption to provide a strong key. You should explore implementations that take advantage of these features wherever possible, while maintaining a balanced approach and common security API across applications and platforms.

Data Destruction

Traditionally, enterprises have managed data destruction using device-centric approaches. Mobile device management vendors provide the means to wipe all the data on a compromised device. Unfortunately, in an increasingly consumer-centric IT environment, bring-your-own-device (BYOD) is becoming more prevalent. This BYOD approach results in a conundrum for many organizations with respect to mobile application security architecture.

The simplest way to handle security is to require the user to accept data destruction as a condition for using enterprise applications on a personal device. The user accepts any liability for loss of information due to a lost or stolen device and must sign a legal agreement to that effect before the application is available for use. This carrot-and-stick approach puts the onus on the users to decide what applications they want to use on their own devices.

Although the all-or-nothing approach is effective for some user profiles, it is not right for everyone. Your enterprise users have important personal information, and they may not be comfortable with an employer destroying that information at any time the organization deems it necessary. In this situation you can use a more judicious approach to data destruction by using an application sandbox.

In the application sandbox approach, you treat the device as “enemy territory” and put all controls necessary to protect sensitive information in place at the application level. You can create the sandbox for each application, or share it across applications and implement all the necessary encryption of information, access points, authorization, and authentication algorithms needed for your specific use case. By sandboxing your application data in this manner, you can include an algorithm or event hook to destroy the sandbox if a device is compromised.

Building Scalable Applications

Application scalability is an important consideration for any enterprise application — including mobile applications. Generally, you can scale your application in two ways: scaling up, or scaling out.

Scaling up involves upgrading storage and processing resources to accommodate additional load. Scaling up is not an option for mobile application capability due to the storage and processor limitations on mobile devices and the fact that most devices don't provide a mechanism for upgrade outside of replacing the device.

Scaling out involves adding additional nodes to a group or cluster of existing nodes to balance and share the load. This is the most common technique of scaling applications in the enterprise. But the news on the mobile front is not good here either because clustering mobile devices is not possible, nor would it make sense. A user has a single device, neither more, nor less.

You need to build scalability on the server-side as you've always done. You can upgrade server nodes and expand clusters easily to accommodate increased loads. With cloud services, such as Microsoft Azure and Amazon Elastic Cloud, you can configure virtual instances to scale in and out on demand to match application load at the moment in real-time.

Consider how you can take advantage of these technologies in your mobile application architecture, especially for applications with large user populations that may fluctuate greatly over time. Using hybrid application design techniques, you can deliver large portions of functionality from the cloud, but be aware of the sacrifices required in terms of connectivity, device access, and user experience before making this choice. The benefits of server-side scalability can be great, but the cost is not free. As with any architectural decision, it is a trade-off.

Planning for Deployment

One of the reasons web applications have become so popular in the enterprise is the ease of deployment. You can centrally deploy and manage a web application, and the only client-side application you need is a web browser. You can easily scale web applications as well, adding to their appeal, and cost of ownership is much lower whenever you use a web-based approach.

Deployment of mobile applications is often not as simple. Disconnected capability, device access, and user experience are all directly impacted by the decision to use a web-centric approach to application deployment. Because these are the three most important considerations in mobile architecture choice, you often land in a place where you need to manage and deploy native and native/web hybrid applications.

Most Mobile Device Management (MDM) vendors offer internal application stores as a part of their packages, which you can use to deliver applications to your enterprise with ease. Apple's over-the-air deployment model makes custom development of your internal application store simple and offers a lot of flexibility in app store design and deployment.

Device APIs, such as Apple's over-the-air provisioning and deployment, make custom-built app stores and device management solutions possible as well, if you discover the MDM vendors can't meet your specific needs.

Consider both web-based and native/hybrid approaches, but make sure you understand the implications of application deployment. Managing your mobile application deployment, whether you use MDM or choose to do it yourself, can have a big impact on the cost of ownership of your mobile application portfolio.

Writing Extendible Modules

When choosing a mobile architecture, it is valuable to take an approach that emphasizes reusable components. For example, security components, such as the SSO service mentioned previously, are among the most obvious and valuable components that you can design for reuse. Providing a shared library for functions such as authentication, authorization, and encryption enforce a consistent security model. This approach is an effective way to keep your applications extendable into the future.

Device and hardware abstraction layers can provide support for multiple functions and peripheral devices (for example, barcode scanners) and enable replacement of the peripherals as needed without re-engineering your entire application. Utilities for application configuration, logging, or analytics can provide valuable application services that enhance your deployment capability. Standardizing on basic functions can provide significant value, so you can spend less time resolving these common problems and more time building your mobile applications. Figure 1.1, reprinted with permission from Nathan Clevenger's book, iPad in the Enterprise: Developing and Deploying Business Applications (Wiley, 9781118022351, page 247), shows potential extendibility modules.

Maintaining Application Code

Designing and writing maintainable object-oriented code often involves a strong focus on proper encapsulation of functionality and a logical organization of concerns within your application domain. Writing maintainable mobile application code also includes consideration of whether the code is meant to run on the device or in the cloud, and for cross-platform mobile applications, what platforms it is intended to execute on.

.NET and Mono provide a clear advantage for developing maintainable code at the architecture level due to the unification of language and APIs, but the implementations across platforms vary according to the lower-level capabilities of the targeted platform. MonoTouch, for example, cannot support certain C#/.NET conventions that require dynamic compilation and execution at runtime.

In addition, Windows Phone 7 uses the Silverlight concept of isolated storage in place of the traditional System.IO.File concept on other platforms. When accessing storage it is necessary to use a different approach for each platform. You should minimize the need to maintain multiple algorithms in common code by separating your platform-specific approaches in components compiled specifically for the platform in question.

Choosing an Architecture

Now that you identified and assessed your architectural options, you're ready to choose the approach that best fits your specific application use case. You can take several approaches, depending upon the decisions you make for your specific cross-platform requirements. You can divide the approaches into three high-level categories: native applications, web applications, and hybrid applications.

Building Native Applications

If you choose a purely native approach, chances are you determined an overwhelming need to satisfy requirements around disconnected functionality, device access, and/or a rich, immersive user experience. Native applications can uniquely meet these requirements, which is their biggest advantage. But there are also disadvantages.

Advantages

The first advantage of writing native mobile applications is full access to richness and flexibility of the native user interface APIs. Today, mobile devices are extremely personal devices, and the touch interface experience is unique. Users are attached to their devices and expect an exceptional experience that they cannot duplicate using technologies other than the native capabilities of the native device API. If your application requires sophisticated graphics or custom controls to deliver the experience, a native app is often the best choice.

Secondly, native applications provide full access to all the unique functions available on the device. Geo-location services, accelerometer and gyroscope, camera, video recording, audio recording, compass, and so on are all exposed via the native device API and platform. If you require one or more of these functions, a native application can deliver.

Finally, native applications offer the capability to work in a disconnected mode, either intermittently or constantly. You can cache and retrieve data from the device, execute business logic, and present information to the user without the need for a network connection. If you need to run your application when the device is in airplane mode, using a native application is your only choice.

Disadvantages

Taking a purely native approach has some disadvantages. First, the development of a native application requires some form of application management to facilitate deployment of your application, which means an internal app store, provided as a feature of MDM or built from scratch. It also requires some way to manage provisioning of new devices that users periodically add. Be sure to make updates to applications available to the user population, and refresh provisioning profiles. This generally leads to an increased cost of ownership surrounding the deployment and management of a native application portfolio.

Building Web Applications

Mobile web applications are centrally deployed and run on the server just like their enterprise counterparts, and many tools and frameworks specifically address the challenges of mobile web application development. The convenience of web applications, however, comes with a price of limited device access stronger connection dependence.

Advantages

The first advantage of adopting a web-based approach for your application is that existing web applications often work as-is on the newer tablet form-factors. Beyond that, you can easily port most web applications, if they are written with cleanly separated user interfaces, to the smaller form-factors of the various smartphones with relatively little effort. Web development skills are prevalent in most organizations, and the learning curve for a web developer to write mobile applications is short. So, developing new applications using this approach is often attractive.

Web application deployment is centrally managed and offers the second significant advantage over native applications. You do not need device provisioning and deployment strategies, and the questions of device management are much simpler when the application is in the cloud. When the application runs fully in the browser, there is little difference from a management and security perspective from a traditional desktop web application. Your organization likely already has a security policy and development best practices that support this approach.

The final advantage of taking a web-only approach is the cross-platform capabilities of HTML 5. Leveraging HTML 5 to deliver a satisfying user experience to multiple platforms offers great advantages. Capabilities such as hardware graphics-accelerated transitions supported in iOS and rich CSS support can create application experiences that can rival the native experience for out-of-the box, data-driven controls. HTML 5 even supports geo-location services to enable location-aware applications, and the HTML 5 cache manifest standard enables caching of application resources to support offline functionality.

Disadvantages

Lack of access to device functions can be a big drawback in using a web-only approach. If your application requires access to the device beyond geo-location, you must use a native or hybrid approach. Users expect features that take advantage of these services; they know what their devices can do and often demand that functionality. If your application needs these capabilities, a web application can't deliver.

Connection dependence is another drawback of web applications, especially if users need to manage offline transactions on the device. Although the HTML 5 cache manifest standard provides for offline access to web resources (for example, markup, images, multimedia, XML or JSON data), it is designed and optimized for resource consumption only. You cannot easily modify or create new resources for processing by a centralized system using HTML 5, and access the native API functions, such as storage and threading, are necessary to manage these items.

Finally the cross-platform HTML 5 standard does not support the rich, immersive user-experiences mobile users have come to expect. The mobile web framework space is currently immature, but it is evolving rapidly. More creative solutions using CSS and JavaScript emerge every day, but the native APIs evolve as well. Whether HTML 5 and the mobile frameworks that use it can catch up and deliver a user-experience that matches the native platforms remains to be seen, but for now, it is a significant drawback to a web-only approach to mobile development.

Building Hybrid Applications

A hybrid application is one that uses both native and web-based functionality to deliver a unified experience within a single application. Taking a hybrid approach can offer great flexibility in delivery of use cases that don't fit well into a purely native or purely web-based approach. Hybrid applications can offer best-of-both-worlds architecture, but they also carry with them the same disadvantages of native and web applications.

Advantages

By taking a hybrid approach, you can choose to deliver some portions of your application using web technologies and other portions using native controls and APIs. If you can easily deliver most of your application centrally via a web application, you can do that while building native custom views to deliver the few features that require native access or improved user experience. Conversely, if you have a small amount of information available on the web that you can style to fit your mobile application, you can deliver that content using web controls within an otherwise native application.

Hybrid applications also offer limited deployment choices. Because a hybrid app is essentially a native “wrapper” application that delivers some content via the web, the same deployment and provisioning requirements of native applications apply. But you can limit the amount of information delivered natively to mitigate some of the risk of deploying a fully native application. If, for example, there is a particularly sensitive class of information that requires an exception to data security policies to deliver at-rest in a native application, you can choose to offer that information only online via existing web security policies. You can natively deliver the rest of your application where data security is less of a concern.

Ultimately, the flexibility of a hybrid approach is its greatest advantage. By judiciously applying this architectural style, you can realize the advantages of both native and web applications, while minimizing the compromises necessary in taking either of those approaches independently.

Disadvantages

Hybrid applications require device deployment. All the deployment and provisioning requirements previously mentioned with regard to native applications are in play. There is no way around it. You must consider increased costs of management, whether via MDM vendor or internal IT departments.

Because hybrid applications need to navigate between native and web components, they can sometimes suffer from decreased performance. Device access through web pages requires a JavaScript abstraction to mitigate the mismatch between the native APIs, and content delivered via the web can suffer from bandwidth constraints. Carefully consider the need for application responsiveness and performance before taking a hybrid approach.

Finally, the web content delivered in a hybrid application cannot match the native user experience. Be careful when designing the transitions between approaches because an obvious degradation moving from native to web can severely impact your user experience in a negative way. Hybrid applications can be flexible, but you should carefully consider the user experience you deliver using this approach.

Building for Multiple Platforms

The goal of cross-platform development is to maximize the amount of code shared while maintaining the native look and feel of each platform. Each native platform has its own unique flavor; you must consider a few things when choosing which platforms to support with your cross-platform applications.

Choosing iOS Applications

MonoTouch provides for C# compilation to the native functions and also includes the core Mono .NET assemblies compiled specifically for iOS. You can write C# code in the Integrated Development Environment (IDE) of your choice, but it must be compiled and deployed from a Mac using the MonoDevelop IDE. The resulting assemblies are compiled to static code, which results in limitations surrounding dynamic generation and execution. As a result, MonoTouch does not support .NET APIs that require dynamic code generation or execution. These include Reflection.Emit(), Generic Virtual Methods, and P/Invokes in generic types, among others. Full details are available from the Xamarin documentation site at http://docs.xamarin.com/ios/about/limitations.

You can also bind to native iOS libraries to take advantage of existing or third-party components written for iOS. Mono supports binding to native Objective-C libraries using the .NET P/Invoke framework (as long as the classes you bind to are not generics). You can find details at http://ios.xamarin.com/Documentation/Binding_New_Objective-C_Types.

If you prefer to statically link your Objective-C libraries, that option is also available. You can check it out at http://ios.xamarin.com/Documentation/Linking_Native_Libraries.

Choosing Android Applications

Mono for Android provides C# compilation to the native Android SDK, much like its iOS counterpart, MonoTouch. It also includes the core Mono .NET libraries, along with access to native Android APIs via the Mono.Android namespace. You can also write Mono for Android code in the IDE of your choice and compile it in both Microsoft Visual Studio and MonoDevelop on either a PC or a Mac. Mono for Android applications run in the Mono runtime environment and sit side-by-side with the native Android Dalvik virtual machine. Figure 1.2 shows a diagram of this architecture.

Whenever you need communication between the Mono and Dalvik runtimes, Mono for Android uses wrappers (represented by the arrows in Figure 1.2) to bridge the gap. Mono for Android generates Managed Callable Wrappers (MCWs) and uses them whenever managed code in the Mono runtime needs to invoke native Android code. All the APIs exposed via the Mono.Android namespace make use of MCWs. Conversely, Android Callable Wrappers (ACWs) are a native Java bridge used by the framework whenever native Android code needs to invoke managed code in the Mono runtime. You need ACWs to overcome the lack of dynamic class registration in Dalvik at runtime. You can find details of the Mono for Android architecture at http://android.xamarin.com/Documentation/Architecture.

Because Mono for Android must generate ACWs at compile time to support calls from Dalvik to Mono, you cannot use dynamic languages, such as IronPython or IronRuby, to subclass Android Java classes. The Android.OS.IParcelable and Java.IO.ISerializable interfaces are not implemented, and there is limited support for generics. You can review details on all Mono for Android limitations at http://android.xamarin.com/Documentation/Limitations.

Choosing Windows Phone Applications

The Windows Phone SDK is the only fully native .NET environment. It is built on top of both the Silverlight and XNA game platforms published by Microsoft. You must write Windows Phone applications using the Microsoft Visual Studio IDE. The free SDK download includes Visual Studio 2010 Express for Windows Phone. You can download the SDK at http://create.msdn.com/en-us/home/getting_started.

One of the most significant areas in which a Windows Phone application differs from other platforms is the use of isolated storage for IO operations. Because the foundation of Windows Phone is Silverlight, you must perform IO using the asynchronous isolated storage methods exposed there anytime you want to directly access storage on the device. Windows Phone also has support for structured data using the SQL Server Compact Engine. Access to the structured store is available via Language Integrated Query (LINQ), which greatly simplifies access to device storage. You can find full details of the Windows Phone SDK on MSDN at http://msdn.microsoft.com/en-us/library/ff402535(v=VS.92).aspx.

Choosing Web Applications

Writing cross-platform web applications is often the simplest way to provide support across a wide variety of platforms. Both the iOS and Android mobile browsers include support for HTML 5 via the Apple WebKit rendering engine; Windows Phone does not, so the examples in this book do not work in mobile Internet Explorer. Fortunately, many available rapidly evolving mobile web frameworks offer robust support across devices. The MonoCross pattern introduced in this book is ultimately framework-agnostic for web applications. You can experiment with other implementations as you become familiar with the concepts.

The examples in this book are based on the WebApp .NET micro-framework. You can find details on the framework at http://webapp-net.com. WebApp .NET offers a mobile optimized HTML user experience based on the Apple iOS paradigm. It makes extensive use of the styling elements available in WebKit and uses hardware graphics acceleration to simulate the sliding transitions of an iPhone application. The framework has robust AJAX support, which manages the navigation stack for you.

Summary

In this chapter you learned about some of the basic tenants of mobile architecture. You now understand how network connectivity, device access, and user experience form the foundation of mobile architecture decisions. You explored the various mobile application considerations surrounding device limitations, security, scalability, and more. Then, you explored various architectural approaches including native, web, and hybrid applications discussing the pros and cons of each. Finally, you learned more about the four platforms explored in this book: iOS, Android, Windows Phone, and Web. You learned about the specific nuances of each platform with an eye toward choosing the right ones for your organization.

In the next chapter you learn how to design your mobile application user experience using proven prototyping techniques. This design is the foundation of the samples used throughout the book, and represents the first step into cross-platform mobile development.