Optical Storage Amy Kate Mahaney Shakar Zachary McNulty Graham Northup Jeremy Whinnery.
Kevin Whinnery: Best Practices for Cross-Platform Mobile Development
-
Upload
appcelerator-inc -
Category
Technology
-
view
3.100 -
download
0
description
Transcript of Kevin Whinnery: Best Practices for Cross-Platform Mobile Development
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!