architect a winning mobile application
TRANSCRIPT
T10 Session 4/16/2015 3:15 PM
" Architect a Winning Mobile
Application"
Presented by:
Shadi Saifan
FIS Mobile
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073 888-‐268-‐8770 ·∙ 904-‐278-‐0524 ·∙ [email protected] ·∙ www.sqe.com
Shadi Saifan
FIS Mobile Director of engineering at FIS Mobile, Shadi Saifan is leading solution strategy and solution engineering and QA for all FIS Mobile client initiatives. Shadi is a professional technology leader with fifteen years of experience in delivering distributed, mobile, and enterprise solutions—with a focus on architecture, design, and development. With extensive knowledge in mobile technologies and platforms, he has worked with a large number of clients, cross-functional teams, and a network of service providers to implement highly scalable distributed projects for the mobile channel. Shadi previously worked for Deloitte Consulting, IBM Global Services, and Hewlett-Packard in various design and technical roles.
4/8/15
1
©2015 FIS and/or its subsidiaries. All Rights Reserved. FIS confiden?al and proprietary informa?on.
ARCHITECTING A WINNING MOBILE APPLICATION Shadi Saifan Director of Client Services Engineering FIS Mobile
AGENDA: KEY TAKEAWAYS
• Selecting your approach to mobile development
• Comparing and contrasting development options
• Importance of security considerations
• Benefits of starting with the right architecture
4/8/15
2
• Design ensures that apps look as great on the inside as they do outside
• Making design decisions at the end of a project is costly
• Design and development often fail to consider support and maintenance
• Design decisions drive adoption
Why is it important to invest in planning?
FRAMEWORK OR MOBILE APP APPROACH
DATA ACCESS
SECURITY
PERFORMANCE
CONNECTIVITY
Decisions in Building a Wining Mobile App
Val
ue
to
Cu
sto
me
r
Use
r E
xpe
rie
nce
4/8/15
3
MOBILE FRAMEWORK AND APPROACH
Selecting a framework is not about right or wrong, it’s about what’s best for your business
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//
EN" "http://
www.w3.org/TR/REC-html40/strict.dtd">
Web Code
Mobile Browser
Device API
Native Application
10011000101000101010010101001010100101010101010101010100101010100
Device API
Native Container
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/
REC-html40/strict.dtd">
Web Code
Types of Mobile App Frameworks
Mobile Web Hybrid Native Pure Native
4/8/15
4
• A mobile-friendly website designed to work with all smartphones
• Loads within a mobile browser, i.e. Safari or Chrome, and often developed to be responsive
• Typically native wrappers are used to publish on app stores
• Easy opportunity to bring content to the mobile channel
• Dependent on internet connection
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//
EN" "http://
www.w3.org/TR/REC-html40/strict.dtd">
Web Code
Mobile Browser
Mobile Web App
ADVANTAGES DISADVANTAGES
• Rapid speed-to-market
• Requires common web skills
• One code base for many devices
• Ability to leverage existing mobile sites
• Easy to make changes on-the-fly as no app push required
• Web look and feel
• Limited access to device capabilities
• Dependent on browser and performance of internet
Advantages and Disadvantages of Mobile Web App
4/8/15
5
• Smartphone app coded in specific language, i.e. Objective-C for iOS and Java for Android
• Published to and downloaded from each relevant app store
• Designed and coded for a specific device type
• Fast, reliable and provides the best responsive experience
Native Mobile App
Device API
Native Application
10011000101000101010010101001010100101010101010101010100101010100
ADVANTAGES DISADVANTAGES
• Best performance
• Consistent look and feel with other apps on device
• Full access to device capabilities
• Fast, reliable and provides best responsive experience
• Supports offline mode
• Slower to market
• Require specialized skills
• Multiple code base to support different devices
• App changes typically require a new app push
Advantages and Disadvantages of Native App
4/8/15
6
• Combines elements of native and web apps
• Cross-platform compatibility
• Capability to access device resources
• Build once, use across multiple devices
• Improvement on browser-based app, but not truly native
• Typically built with cross-compatible web technologies, i.e. JavaScript and HTML5
• Usually only a portion of native code must be rewritten to function with different kinds of devices
Hybrid Mobile App
Device API
Native Container
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
"http://www.w3.org/TR/
REC-html40/strict.dtd">
Web Code
ADVANTAGES DISADVANTAGES
• One code base for various devices/OS
• Rapid speed-to-market for multiple platforms
• Based on common web skills
• Consistent look and feel across app platforms
• Access to device capabilities as supported by third parties
• Can support offline mode
• Third party dependencies
• Certain native features require some native code
• App changes likely to require a new app push
• Wrapping native modules/ SDK can be challenging
• Potentially very complex when trying to achieve exact parity with native
Advantages and Disadvantages of Hybrid App
4/8/15
7
The Big Picture
NATIVE
Native look and feel
Developers with native experience
Per platform experience
Faster upgrade
Slower to market
HYBRID
Slower upgrade
Custom look and feel
Faster to market
JavaScript and web experience
Cross-platform experience
MOBILE WEB
Faster upgrade (if needed)
Web look and feel
Fastest to market
JavaScript, HTML5 and web experience
Web experience
Requires new submission
Easy integration with third party SDKs
Native access to all device resources
Requires new submission
Harder integration with third party SDKs
Access to devices resources
Doesn’t require new submission
Hardest integration with third party SDKs
Limited access to device resources
• Evaluate pros and cons of each approach and consider your business needs
• Factor in your audience when considering tradeoffs, i.e. consumer vs. enterprise needs
• Evaluate your needs regarding quality testing, testing automation, frequency of app releases, maintenance and upgrades
• Evaluate any white-labeling needs, multi-language support and device resource dependencies
• Evaluate data dependencies (local vs. server)
• Are your goals focused on content delivery and servicing or interactivity?
How to Decide on Your Approach to Mobile
4/8/15
8
MOBILE SECURITY
Perimeter Integrated
Time + Information + Technology
• There is an increased reliance on apps to perform critical business operations and process sensitive data
• Mobile apps run in unsafe environments; an increasing number of owners root their devices
How has mobile changed?
4/8/15
9
HARDWARE LAYER
APPLICATION LAYER
OPERATING SYSTEM LAYER Jailbreaks exploit defects in operating systems
Apps have access to your data
Using memory corruption defects to firmware
NETWORK LAYER Over-the-air interception
Mobile Security: Layers of Security Risk
• Major operating systems’ security has improved, yet hackers’ techniques have also improved
• Web services are exposed – making apps an easy target for security attacks
• Mobile devices can be lost or stolen and on-device data is always at risk
• Token-based authentication and authorization is popular
• Tokens and data can be captured via packet sniffing or any other “man in the middle” attack
• Ensuring app security is more important than securing the device
• Develop with an “application integrity” mindset and focus on app “self-protection” measures
Mobile Security Overview
4/8/15
10
Highly confidential data should never be stored on device
Use encryption when storing data on device and ensure encryption key is not stored on device
Secure end points, and ensure all communication between apps and APIs are via secure connection (SSL/TLS)
If storing sensitive data, store on server and retrieve during active session
Set expirations for all tokens used in sessions
1
3
5
2
4
Mobile Security Considerations
Mobile Security Considerations
Use layered security; mobile app, transport and communication, web services and back-end integration Leverage multi-factor authentication, beyond usernames/passwords
Identify source of request for your web services API
Utilize obfuscation when possible
Employ device capability for security management (i.e. device fingerprints)
Follow coding best practices and stay up-to-date
Secure-scan your app, including run-time scanning
ü
ü
ü
ü
ü
ü
ü
4/8/15
11
PERFORMANCE
• Performance is often ignored during rapid app development until problems arise toward the end of project
• Still lags behind desktop (approx. one-third of capability)
• Variable data connections speeds due to WiFi and network coverage
• Performance should be considered early, at design stage
• Mobile platforms and framework have app performance effects
• Designers should implement common design best practices related to performance
• Some architectural decisions can limit performance, which can be difficult change later in the project
Mobile Performance Overview
4/8/15
12
Performance Considerations
• Utilize web services API to return required data
• Only return data when the app requires it
• Early fetching and paging techniques can be used at the server layer
• Conserve bandwidth by using lightweight format, i.e. JSON
• Utilize push notifications instead of constant pulling of data and background processing. If pulling is a must, be cautious of battery life
• Keep CPU-intensive processing on server
• Follow code-level best practices for optimizing performance for your mobile platform and framework; number of unnecessary objects created, threads, releasing/auto-releasing, etc.
DATA ACCESS
4/8/15
13
• Mobile platforms aren’t designed to support remote database access for security and performance reasons
• While restriction based on client certificate, VPN, and other methods is possible, it is not cost effective and affect performance
• Justifies the inclusion and wide use of a web service layer
• With a web service layer, authentication and authorization can be used along with business roles and data validation
• While server session is active, authorization logic should continue being checked by web service layer
• Web services help connect different data systems and assist in paging, pre-fetching, etc.
Data Access Overview
• Define web services API and interaction model early in your design
• Evaluate impact of time to obtain and access required data and avoid expensive calls
• Consider pre-fetching data and server-side caching if back-end request is time consuming
• Factor in security and performance while accessing data
• Keep session alive on server when needed, and send only data essential to presentation when possible
• Evaluate your needs for logging, monitoring and analyzing data
Data Access Considerations
4/8/15
14
CONNECTIVITY
• 24/7 connection to high-speed internet is a false assumption
• Anticipate low network speed, switching between WiFi and providers’ networks and users going offline
• Mobile web, enterprise and consumer-based apps may all require different considerations
• In some cases, offline access may not be justifiable for your business
• For the majority of apps, there is business value in supporting some offline functionality or, at minimum, managing the offline experience
• Some developers struggle in managing live sessions and syncing sessions between app and web services on server side
• More complex apps load content from third parties
Connectivity Overview
4/8/15
15
• Anticipate design needs early for offline access and data synchronization using caching and queuing
• Caching enables retrieval of larger data sets, in a background thread, or copying data sets
• Implement caching expiration, be selective in what data you cache and never cache sensitive data
• Queuing should leverage local, on-device storage in case app or device shuts down
• Notify users of queuing conflict/errors and provide correction mechanisms
• Ping API method to keep session alive on server
• Include “session is about to expire” message when loading third party web view
Connectivity Considerations
Summary SUMMARY
• Invest early in architectural decisions
• Always look at the whole picture
• Mobile is more than a content delivery channel