cross platform mobile application architecture
Post on 03-Feb-2015
2.068 Views
Preview:
DESCRIPTION
TRANSCRIPT
The Business of IT®
www.parivedasolutions.com
Cross Platform Mobile Application Architecture
September 2013Provo, UT
Our consulting strategy is built around developing our people into “Trusted Advisors”
2
Talent Development
Relationships
Qualityof
Life
Variety of Projects
UnmatchedCareer
Development
RelationshipDrivenSales
CollaborativeEnvironment
LimitedTravel
TransparencyTrusted
Advisors
SmallTeams
Pariveda is different from other consulting firms in the talent that we provide
We grow smart people who can combine knowledge across functional boundaries
• We bridge the gap between business and technology• Develop talent first, focused on your career development
Generalist instead of Specialist• Our consultants are not deep in one subject and then flown across
the country chasing niche opportunities• Your skills will not become obsolete or silo’d in a single technology
Relationship-driven sales• Find business through networking• Build our presence in the local market
Small teams to deliver complete solutions• We strive to build small teams to take complete ownership of a
project and successfully deliver it• Success is driven by responsibilities at all levels of the team
Earn trust of clients through successful delivery• “Seller-doer” model• Repeat clients are our biggest source of revenue
Clearly defined career path• Developer → Architect → Trusted Advisor• Judged against own merit, not percent promoted at each level
3
Boredom Growth Burn Out
TIME
Ass
ign
me
nt d
iffic
ulty
Our people choose Pariveda because of the rewarding lifestyle
4
Pariveda Stats315 employees
273 consultants
9 offices
10 years old
20.3% headcount growth in 2012
7.5% headcount growth in 2013 so far
24% revenue growth in 2012
5
The Mobile App Developer's Dilemma
There are lots of cool mobile devices
You want to get your content onto as many as possible (or you don’t want to exclude any users)
Native Development• Expensive (time, $$$ and support)• High Quality user experience• Full API support• High cost per platform
Mobile Web App• Restricted feature set• Limited offline capabilities• Missing app store marketing pull• Supported by most if not all mobile devices
Cross-Platform Frameworks• “Native” apps• Lower cost per platform• Lowest-Common API support• App may not follow conventions of the platform• Uncanny Valley
6
Getting the UI to “almost” match can be a very bad thing
Uncanny Valley• Concept from robotics/AI design• Differences that seem small add up to create subconscious dissonance• In mobile development
- The screenshots look good but it doesn’t feel the same to use- Usually caused by Web Views
See http://en.wikipedia.org/wiki/Uncanny_valley
7
Is the app a product in its own right, or just one of many channels by which the user consumes your services?
The decision of which architecture strategy to use largely depends on the tradeoff between User Experience/functionality and development cost. Two common categories of mobile apps fall on either side of this spectrum.
Product• The mobile application is the main product that customers use to interface with the company/system• Improved User Experience/functionality is more likely to be worth the cost of separate native applications• User discovery happens by word of mouth, app store search, social media ratings• Example: Mobile game, media consumption app, specialized utility app (Speedometer, Instagram, Augmented Reality)
Channel• The mobile application is not the main product for customers, but rather one of many ways to interface with the
company/system• Want to be able to reach more customers for a lower cost, no matter their mobile platform choice• Discovery driven by other channels• Example: Mobile ready shopping website, banking app, airline check-in/flight status app
How do you feel when you follow a link to a news site/blog and a pop-up encourages you to download their app?
See http://martinfowler.com/articles/multiMobile/#product-or-channel
8
Architecture Layers in Mobile Apps
Partially connected mobile applications can be separated into six architectural layers
ServerData
ClientDomain
Server Domain
(Web Services)
User Interface
User-Client
Layer
Client-ServerLayer
Sync
9
Architecture Layers in Mobile Apps … continued
Native mobile development only shares the two server layers
Most cross-platform Mobile Enterprise Application Platforms (MEAPs), such as RhoMobile, PhoneGap and Kony share all 6 layers, but can result in the "Uncanny Valley"
Some frameworks (Xamarin) allow us to share the 5 application layers, while writing separate user interfaces, but they can be more toolsets/adapters than full frameworks
User-Client Layer
Client Domain
Client-Server Layer
Server Domain
Server Data
Application Presenters
SQLite DB
Client-side Value Objects
Web ServicesAdapter
AuthenticationAdapter
REST Services
Content DB / Source of Truth
User Interface
Native UI (Android, IOS,
Windows Mobile, Blackberry,
Website, etc)
HTML 5
RhoSync Server
UI BODY SERVER
10
Separate Native Apps for Each Platform
Pros• Simple for IT and business to understand• Best possible User Experience• Less expensive when only requiring 1 or 2 platforms• Can be listed in application store for the platform
Cons• Each additional platform requires a lot of effort• Many applications to maintain• Need expertise in the native development
environment of each platform
Notes• Need a separate strategy/framework for server-side
components. If you don’t already have a Services Oriented Architecture this can be a major challenge to implementation.
UI Body
UI Body
UI Body
11
Full Cross Platform Framework (Most MEAPs)
Pros• A single application to maintain• Each additional platform does not require much additional effort• Can be listed in application store for the platform• A number of platform choices available• Simple Business/CRUD applications can be built rapidly• Many MEAPS include server-side/sync components
Cons• Uncanny Valley (UI feels slow/wrong on every device)
- Often achieve cross platform UI by using HTML views, in effect making your native app actually a web app in disguise- “UI-Translation leads to fatal compromises in user-experience” – Martin Fowler
• Requires expertise in the particular Cross Platform framework of choice, and results in framework lock-in• Restricted feature set (Lowest Common Denominator)• Full cross-platform application development failed on the desktop (Java Swing) and is unlikely to become
mainstream in the mobile space for the same reasons• Not ideal for applications that are graphically intensive (fine for graphs/simple animations, not for games)
Examples• RhoMobile (Motorola Solutions)• Titanium Appcelerator• Kony (does allow better per platform customizations
than some others)• Antenna AMPchroma
• PhoneGap/Cordova• JQuery Mobile/Sencha/Dojo• Verivo (Pyxis)• IBM Worklight• http://en.wikipedia.org/wiki/Multiple_phone_web_bas
ed_application_framework
UI Body
12
All but the UI Cross Platform Toolkits (AKA Separated Presentation/Portable Body)
Pros• Allow reuse of much client code while still allowing the use of true
native controls• Can design UI to match standards of the platform • Can be listed in application store for the platform• Can write unit tests for shared libraries• Valuable when library (shared) code is likely to be extensive
Cons• Often more of a platform rather than a full framework
(May have to write your own MVC framework, DB layer, etc)• Require expertise in the particular toolkit chosen• If library (shared) code is small, this strategy may introduce
unneeded overhead• May not include server-side/sync components
Examples• Xamarin• Kony with Native/Hybrid views that use per platform customization• Calatrava• Custom webview wrapper for each platform, libraries for business
logic/authentication/webservices written in javascript and shared.• Mix of native and webview controls within an application (AKA
Native Veneer)
UI
UI Body
UI
13
Full Mobile Web Application (separate mobile site, or responsive design)
Pros• Easy to access on any mobile device• Expected functionality/look and feel is lower than a native application• Web programming experience is common – small ramp up to transition desktop web developer to mobile web• Some experiences are better suited to the web browser, even on mobile devices (news browsing, blog reading,
window shopping, etc.)
Cons• Restricted feature set (not all sensors are available to a web application)• Not able to list application in the application store for the platform• Reduced ability to save state between sessions
Note• Some gestures are ok, but don’t try to make a web application feel like a native application – that puts you back in
Uncanny Valley. Instead focus on following the principles of responsive web design.
Q&A
Questions?
14
15
References
Martin Fowler “Patterns of Enterprise Application Architecture”
http://www.gartner.com/technology/reprints.do?id=1-1I8627T&ct=130807&st=sb
http://xamarin.com/
http://martinfowler.com/bliki/CrossPlatformMobile.html
http://martinfowler.com/articles/multiMobile/
http://en.wikipedia.org/wiki/Multiple_phone_web_based_application_framework
http://martinfowler.com/articles/mobileImplStrategy.html
http://calatrava.github.com/
top related