Native Code is Dead AKA Cross Platform Development with Unity3D
Best Practices for Cross-Platform Native Applications
-
Upload
kevin-whinnery -
Category
Technology
-
view
1.928 -
download
1
description
Transcript of Best Practices for Cross-Platform Native Applications
Kevin WhinneryEngineer and Platform Evangelist
Appcelerator, Inc.
@kevinwhinnery
Best Practices for Cross-Platform
Mobile Apps
Kevin WhinneryEngineer and Platform EvangelistAppcelerator since 2008
Husband and father of three:
Web developer and JavaScript slinger turned mobile and desktop hacker.
http://kevinwhinnery.comhttp://twitter.com/kevinwhinneryhttp://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!