Best Practices for Cross- Platform Mobile Apps

Kevin Whinnery

Kevin Whinnery Engineer and Platform Evangelist Appcelerator since 2008

Husband and father of three:

Web developer and JavaScript slinger turned mobile and desktop hacker.

http://kevinwhinnery.com http://twitter.com/kevinwhinnery http://github.com/kwhinnery

Agenda

•  Cross-Platform UI Approaches

•  Component-Oriented Applications

•  Modular JavaScript Techniques

•  Code Walkthrough

Cross-Platform in Titanium

•  Cross-Platform !== “Write Once, Run Everywhere”

•  Cross-Platform in Titanium means: •  100%* Non-visual code reuse •  Lots of UI code reuse, depending on

design •  Best-in-class experience on every

platform

•  “Write Once, Adapt Everywhere”**

* This isn’t always true, but we’re working in that direction ** Term coined by Yehuda Katz, SproutCore, jQuery, and Rails contributor

Cross-Platform Interface Guidelines

•  Maybe we’ll call this the C-PIG (pr. Sea Pig)?

•  The best Titanium applications are conscious of their target platforms, and meet user expectations

•  Cross-platform applications are useless unless they blend seamlessly with the best applications on a platform

•  Take the time to learn the UI conventions of the platforms you’re targeting

Characteristics of iOS Interfaces

•  Touch centric

•  Gestures are central to hiding complexity

•  Uniformity in UI conventions is encouraged with rich controls and well-defined interaction models

•  HIG is required reading

Characteristics of Android Interfaces

•  Touch and hardware interaction

•  Activities are central elements

•  Interfaces are less homogenous

•  Android Interface Guidelines is required reading

Reconciling Cross-Platform UIs

•  Focus on the primary task

•  Sketch out an information architecture for apps on all platforms

•  Based on those exercises, pick out the common components for re-use

Cross-Platform Approaches

Schools of Cross-Platform Thought

•  Immediately Familiar to platform users

•  Self-evident navigation and interaction models

•  Polished look that makes an app feel like it belongs on the platform

Platform Identity •  Evocative of emotions

around the brand

•  Able to create new, engaging experience not seen before

•  Not bound by platform UI conventions

Brand Identity

Platform Identity: GetGlue

The Platform Identity Approach

•  Different designs and interaction models for each app

•  Individual UI components could be reused, the rest would be platform specific

•  Common UI conventions and components are used

•  Win for a developers: 100% non-visual code reuse, and 50% or better UI code reuse

•  Tradeoff: Less reuse, more is done for you (UI controls)

Brand Identity: LNJF

The Brand Identity Approach

•  UI is almost identical across platforms (immersive UI)

•  Small differences: •  Android back button support •  Transitions – iOS: animated transitions, Android: new activities

•  New UI conventions are created and must be learned

•  Win for developers: 100% non-visual code re-use, 80-90% UI code re-use, strong branded experience

•  Tradeoff: More reuse, less is done for you

Which Approach is Right For You?

•  Depends on the primary goal of your app

•  If speed, data interaction, and utility are core to your app, a platform identity approach may be better

•  If emotional connection to brand and engagement are most important, a brand identity approach may be better

Component-Oriented

Applications

Component-Oriented… What’s That?

•  A large app is made up of 100s of smaller, self-contained pieces

•  Really, just good OOP

•  Regardless of your cross-platform approach, this style of thinking and programming is important

Advantages of a Component Arch.

•  100 small pieces are easier to understand and debug than 20 very large pieces

•  Easier to handle orientation changes

•  Easier to adapt cross-platform

•  Enhances reusability

•  Decouples your application, making it more adaptable to changing requirements

Modular JavaScript Techniques

Classic Module Pattern

•  Uses Ti.include to split modules into files

•  Requires steps to avoid polluting the global scope (Namespaces)

•  Can use constructor style or factory style

Classic Module Style: Example

CommonJS Module Pattern

•  Uses require to split modules into files

•  Secure by default – no self-calling function boilerplate or namespaces (strictly) required

•  Can use constructor style or factory style

CommonJS Module Style: Example

Walkthrough: Platform Identity

Style

Questions?

Thank You!