SMALLER NOT TALLERDefeating the mobile application architecture giant

with Heather Downing

Titanium Sponsors

Platinum Sponsors

Gold Sponsors

http://www.slideshare.net/quorralyne/smaller-not-taller-defeating-the-mobile-application-architecture-giant

goo.gl/krfJX4

Get the goods..

IntroductionWho am I?

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

1. What is the final product?The result of your giant-defeating battle plan

What is the end product?

-Consumer-deployed vs B2B

-Self-contained app vs service-driven app

-Local storage vs data sync to server, etc

2. Pick your (tech) poisonChoose the right weapon for the job

Pick your technology poison

● Native

● Cross-Platform Compiled

● Hybrid: WebView

● Mobile Web

NativeThe original approach

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 CompiledThe “One language to rule them all” approach

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: WebViewThe quick but compromised approach

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 WebThe economic, responsive approach

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

3. Divide and (code) conquerPosition your resources strategically for battle

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

4. Find your weakest (bug) linksTest early, test often, to discover where you lack

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...

Case Study: Workflow Application

My garbage, your garbage: The Tale of Two Heaps

5. Hoist the (publish) colorsPrepare and present your polished product

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

6. The M.A.D. TreeMobile Architecture Decision Tree

Mobile Architecture Decision Tree

7. Parting AdviceFinal thoughts before charging onto the field

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

Questions

Thank you!@quorralyne

quorralyne@gmail.com

quorralyne.com

digitallightcycle.blogspot.com

Slide download: http://goo.gl/krfJX4