Multiplatform App Architecture

Editor's Notes

1. A blog about the Multiplatform App Architecture in Dutch is published at http://www.nl.capgemini.com/blog/mobility-blog/2013/11/de-beste-ontwikkelstrategie-voor-mobiele-apps
2. Native Applications: best user experience and performance, distributed via app storesHybrid Applications: cross-platform app running in a container on all supported platforms, distributed via app storesMobile Web Applications: web application with responsive design to support many devices, runs in browser, hosted on web server, direct deploymentNative Development: multiple development environments, results in higher development costs, expertise may be hard to getMultiplatform Native Development: one development environment, shared .NET codebase with Microsoft (Windows platforms) and Xamarin (iOS and Android platforms) technologyMultiplatform Framework Development: one development environment, eg. PhoneGap (supported by IBM Worklight, SAP Mobile Platform) or Kony, shared HTML5/CSS/JavaScript codebaseMobile Web Development: one development environment with shared HTML5/CSS/JavaScript codebase, UI frameworks for responsive designMore info: http://www.nl.capgemini.com/bronnen/mobile-development-think-to-the-future-today
3. Development type determined based on requirements.Challenges for Mobile Development:The Agile versus Quality paradoxIncreasing demands for user experience, performance, security, innovationTime to Market difficult for multiple platformsMultiple target platforms result in multiple development environmentsAnd multiple sets of development toolsResulting in higher development costsSeparate maintenance for multiple target platformsPlatform-specific expertise is hard to get
4. One advanced development environment .NET with C#Full Microsoft Visual Studio and Team Foundation Server integration for all mobile developmentXamarin out-of-the-box offers .NET environment for both iOS and Android, but offers platform-specific classes to create apps: iOS UIViewControllers vs. Android Activities.
5. Architecture and framework needed for optimal code sharing and separation of concerns.Core of the app is shared across all platforms. UI and platform-specific services are developed separately for each platform.All advantages of native development still applyOptimal performance and user experience through native compilationFull access to devices and platform servicesFull control to implement security countermeasuresShared code base for iOS, Android and Windows platforms90% code sharing between platforms75% development effort reduction from second platform onwards
6. A multiplatform mobile architecture offers the possibility to create mobile applications for multiple mobile platforms and at the same time offer the flexibility to use all native functionality of the mobile operating systems to realize an optimal user experience. Combined with a powerful development environment and a comprehensive programming language it offers an excellent way to develop and maintain rich mobile applications.Core of application is shared, while navigation differs between platforms.
7. Uniform architecture based on Capgemini’s CASA reference architectureProven way to guarantee quality, reduce cost, assure fast time to market and deliver exactly what is neededShared design patterns and way of working across multiple platforms and applicationsOnly one development environment requiredOne skill set for developers
8. Model-View-ViewModel pattern is appliedanddependencyInjectionis usedfordynamic binding of platform specific services.
9. The Presentation layer contains packages responsible for the user experience (UX) and the corresponding presentation logic. The Model – View – ViewModel (MVVM) pattern is used for separating the responsibilities for the visual layout and the presentation and business logic. The Business layer contains packages that realize the business logic of the application. The business logic is realized in business entity classes. The business entity classes form the Model from the Model – View – ViewModel pattern. These classes have functional meaning in the business domain of the application and aggregate the functional data. The data can be present as attributes in a business entity class and/or can be aggregated as one or more domain entity classes.The Resource layer contains packages that provide the data for the application and realizes connections to the device, its peripherals and external systems. This layer abstracts all data and connections via platform-independent interfaces, using domain entity classes to transport the data. These platform-independent interfaces are realized by platform-specific services.The Domain Entities frame consists of domain entity classes that contains the data shared between all architectural layers. Domain entity classes contain only data and do not contain business logic. Data can be aggregated as attributes and as nested domain entity classes.  The Common frame contains packages for the implementation of functionality which is shared between all layers. Examples are base classes to support the Model-View-ViewModel pattern and utility classes for security, network connections, multithreading support, configuration settings etc.
10. SetupPlatform-specific class that is responsible for hosting the application for a specific platform. It handles platform-specific initialization and instantiates the platform-independent App class.AppPlatform-independent class that implements the application. This class is responsible for the platform-independent initialization and performs the navigation to the initial view of the application. Besides this startup code, this class does not contain any more presentation and business logic. This class owns the Model from the Model-View-ViewModel pattern, which is represented by the BusinessEntity class.MyViewModelPlatform-independent class that implements the presentation logic for a specific screen. The ViewModel class implements binding properties and command handling to realize platform-independent binding to platform-specific Views.This class uses BusinessEntity classes to retrieve and/or change business data. Services from the Resource layer are never directly accessed from a ViewModel class. MyViewPlatform-specific class that is responsible to realize a screen. The View does not contain code-behind to implement presentation logic. The presentation logic is implemented by the associated MyViewModel class and is accessible via property binding and commands.
11. MyBusinessEntityPlatform-independent class that actually represents the Model in the Model-View-ViewModel pattern. The model consists of multiple business entity classes that contain the business logic of the mobile application. Implementing the business logic in separate business entity classes gives an additional advantage. It offers the flexibility to move the business logic to a mobile web client or business service implementation on the server side when desired. Platform-specific and also platform-independent services are accessed via specific IMyService interfaces.MyDomainEntityThis class represents a class model of platform-independent domain entity classes, which contain the business data in the form of properties. A property has a value of a uniform type or consists of one or more nested domain entity classes. A domain entity class does not contain code, except to initialize properties with a default value.
12. IMyServicePlatform-independent interface which is specifically designed to interact with a platform-specific (or platform-independent) MyService. It is not necessary to expose complete platform services, but only implement the methods actually needed for the mobile application in an agile way. Only uniform (value) types and domain entities are used to exchange data via the interfaces between a service and the business layer.MyServicePlatform-specific (or platform-independent) service that realizes access to specific platform services, persistent data, the device resources, device peripherals or external systems. These service realizations will be kept small, because only the methods are exposed which are actually needed for the mobile application. Note that a lot of platform services are exposed in a uniform way for multiple platforms, which makes it possible to also share services across those platforms.
13. Open source framework MvvmCross is used (but not required) to realize this architecture.