Smaller Not Taller: Defeating the mobile application architecture giant
-
Upload
quorralyne -
Category
Software
-
view
92 -
download
1
Transcript of Smaller Not Taller: Defeating the mobile application architecture giant
http://www.slideshare.net/quorralyne/smaller-not-taller-defeating-the-mobile-application-architecture-giant
goo.gl/krfJX4
Get the goods..
Heather Downing
Passionate lover of all things mobile and object-oriented.
Experience working on Fortune 500 enterprise-level .Net and mobile applications.
Entrepreneur focused on public, consumer-facing sites and apps that enhance our everyday life.
Overview
1. What is the end product?
2. Pick your (tech) poison
3. Divide and (code) conquer
4. Find your weakest (bug) links
5. Hoist the (publish) colors
6. The M.A.D. Tree (mobile architecture decision tree)
7. Parting Advice
What is the end product?
-Consumer-deployed vs B2B
-Self-contained app vs service-driven app
-Local storage vs data sync to server, etc
Native Approach
● iOS: Develop in Objective C, using xCode environment, building app on a Mac
● Android: Develop in Java, using Eclipse environment, building app on Windows/Mac
● Windows Phone: Developer in C#, using Visual Studio environment, building app on Windows
Native Approach
PROS:
● Natural development cycle per platform
● Full access to entire native libraries and hardware
● Natural publishing cycle to app stores
● Better options for handling OS version changes
Native Approach
CONS:
● Requires learning curve per platform
● Can be costly to learn & deploy
● Duplicates code bases
Cross-Platform Compiled Approach
● iOS/Android/Windows Phone share same code base in a framework that ports all platform libraries and makes them available to code with in one language
● Custom IDE/IDE Plugin environment
● Code can be done on Windows or Mac, but a Mac is required for building iOS file
● Facilitates sharing of DAL and BLL, provides choice of a separate platform UI layers or combined UI layer
Cross-Platform Compiled Approach
PROS:
● Shares majority of business logic code base
● Ports new OS changes into DLL for you
● Allows you to code using these libraries in one language base for all platforms
● Often provides excellent support via community and software staff resources
Cross-Platform Compiled Approach
CONS:
● Cost can be prohibitive
● Requires more work than just "write once, code everywhere" mantra
● Adds layer of complexity to set-up/publish
● Recipes for code solutions widespread in community, not all available by frameworks directly
Cross-Platform Compiled Examples
-Xamarin (C#)-Trigger.io (JS)-RhoStudio (Ruby)-Appcelerator (JS)
Ported native approach preserves all the usability, performance and security benefits of fully native apps - using one language to create them
Hybrid: WebView Approach
● iOS/Android/Windows Phone app developed in a framework that wraps HTML/CSS web page in native shell, allowing limited access to native device functionality via an API
● Custom IDE/IDE Plugin environment
● Apps coded locally but built using third-party service to upload code and create deployable app files per platform
Hybrid: WebView Approach
PROS:
● Allows relatively quick turnaround time
● Popular frameworks provide remote builds of your code per platform
● Allow use of your favorite front-end styling and DOM elements
Hybrid: WebView Approach
CONS:
● Remote build services can be costly
● API options to access device can be limited
● Slow, sluggish touch response due to javascript engine
● Highest probability to be rejected from app store acceptance due to structure
Hybrid: WebView Examples
-PhoneGap-Cordova feat. Ionic, Famo.us, etc-Appcelerator Titanium-Intel XDK
A list of frameworks can be found here:
http://mobile-frameworks-comparison-chart.com/
Mobile Web Approach
● iOS/Android/Windows Phone browsers all can access a responsive web site
● Created with one code base in HTML/CSS/Javascript in any environment
● Can be developed on Windows or Mac
Mobile Web Approach
PROS:
● Does not require download, therefore does not take up space on a user's device
● Created with responsive HTML/CSS/Javascript
● Can emulate native look/feel with design
● Easily integrates with server-side for data handling off device
Mobile Web Approach
CONS:
● Slow, sluggish touch response typical of a web site
● At the mercy of internet connectivity between pages
● Very limited JS libraries with options for accessing the mobile device viewing it
DATA
Where do you want it to live?
1. On the server (delivered via web service)
2. On the device (local db storage)
3. Local and server databases kept in sync via web service
BUSINESS LOGIC
Where are the data calculations and business logic handled?
1. On the server
2. In app code
3. Third party API call or other installed application
USER INTERFACE/EXPERIENCE
How do you want to create the user experience and interface?
1. One common UI/UX to be shared amongst platforms
2. UI/UX coded separately per platform
Find your weakest (bug) links1. Incrementally test code
via platform emulators
2. Plug device into development computer
3. Distribute to beta testers
4. Use paid service
-Free
-Cost of device(s)
-Free via iTunes Connect for iOS or dropbox Android file
-Varies
Memory Management
So you’ve picked your framework, designed your user experience, selected the data approach and conquered business logic. Now just pick your favorite design pattern and start coding, right?
Not so fast...
Hoist the (publish) colors
● Study the publish and distribution policies for each platform EARLY in the process
● Remember app submission to a platform’s public store is often followed by rejection - allow plenty of time for revision and resubmission
● Involve client in purchasing store accounts early and look into tax rates
Parting Advice
● You must plan your approach. Small or large, you must plan it.
● Make a proof of concept if possible to familiarize yourself with a new framework before you build the main app
● Keep it simple, small, to the point, not large. Allow room for growth, not complexity
Parting Advice
● -Be mindful of how much you are using an internet connection, users often have limited data plans when not on wifi
● -Allow several weeks for app store submissions, and plan for revisions before acceptance
● -Stress test on low signal strength networks
Parting Advice
● Separate your must-have list from your nice-to-have list
● Don't get sandboxed - test often, catch things early, allow for mistakes and ultimately - success!
In Closing...
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
-Charles Antony Richard Hoare
Thank you!@quorralyne
quorralyne.com
digitallightcycle.blogspot.com
Slide download: http://goo.gl/krfJX4