Titanium Conf Baltimore Keynote 2013
16 likes11,907 views
This document summarizes key points from the Titanium User Conference held on June 27th, 2013 in Baltimore, MD. It discusses how mobile is disrupting businesses and requiring new development approaches. It also provides an overview of Titanium platform updates, including 30 million new users in the past quarter and plans for iOS7 support. Future releases of Titanium are previewed, including performance improvements and a preview of the next generation Titanium platform code-named Ti.Next.
Titanium Conf Baltimore Keynote 2013
- 1. TiConf.us Titanium User Conference June 27th, 2013 Tremont Hotel Baltimore, MD USA h"p://www.flickr.com/photos/ktylerconk/3181331268/
- 4. Mobile is disrupting everything Huge opportunity & massive disruption Mobile is redefining speed Rate of change and disruption is unprecedented The User is King Users are the driving force behind the mobile revolution
- 5. Mobile Requires a Fundamentally Different Approach
- 9. 30,000,000 New Users of Titanium apps in the past quarter
- 10. iOS7 Update
- 11. Yeah! :< • We all get to change our apps, all over again! • Great thing for Titanium developers (sort of) • Lots of interesKng capabiliKes – Background processing – Auto layout – Fullscreen
- 12. When? • We are in progress on it now: – Complete regression under way – Early Apple beta(s), tools pre"y buggy – trying to understand their stabilizaKon efforts – First priority is making sure current API and Apps works • We will make a release available as soon as we can – assuming Apple gives us all Kme • iOS5 support will be deprecated with release
- 13. Ti.Current
- 14. Recent updates – 3.1.1 • Official Tizen support • BB10 Beta • Google Maps v2 • Android 2.3.3 • 3.1.2 targeted for August
- 15. Ti 3.2
- 16. 3.2 Release • EsKmated availability: Fall (or as soon as iOS7) • Major impacts: – Android animaKon improvements – Improvements around Studio Experience – Expanded CLI capabiliKes – iOS7 • Win8 in progress – but will be on Ti.next
- 17. Big items we’re focused on • Developer ProducKvity – Speed of development (such as Alloy, ACS) – Speed of app execuKon – Improved tool chain, flexibility – Improved Studio experience – Development workflow
- 18. Cloud Update
- 19. ACS + Node.ACS Success • Massive adopKon happening – especially by big companies. – Approaching billion API calls – One app recently did 2M+ API calls in ~30M – Autoscaling to ~3,500+ virtual servers • Big capabiliKes coming: – SynchronizaKon – More enterprise data connectors – Monitoring / management
- 20. The Appcelerator Platform The only platform build for a mobile first world
- 22. Warning: This is not free and can be quite expensive
- 23. Dashboard DEVELOPMENT PRODUCTION Users Cloud Test Performance Analytics Cloud Foundation PRODUCT MANAGER DEV MANAGER QA MANAGER EXECUTIVE APP App Studio Appcelerator Platform DESIGNER DEVELOPER QA ENGINEER DEVELOPER
- 28. Warning! Disclaimer! 100% of the informaKon about Ti.Next is likely to change and will change. It’s sKll a lab experiment today.
- 29. How Titanium feels as an App developer?
- 30. How Titanium feels as an App developer?
- 31. How Titanium feels as a core platform developer?
- 32. How Titanium feels if you’re Jeff Haynie?
- 33. Ti.Next • Next generaKon architecture for Titanium – Leverage over 4 years of learning – Complete re-‐write of core engine – Ti API compaKble (for the most part) – One JS engine and core runKme to rule them all
- 34. Ti.Next Goals • Massive performance gains – Reduce footprint in terms on physical size of binary and in-‐memory footprint – Reduce garbage collecKon overhead to minimal – Simplify threading model and context switching – Increase per operaKon performance by several orders of magnitude: ~20+ms/op -‐> ~100+μs/op – Move from naKve language to ASM generated code (ObjC-‐>ASM via libffi) – Faster than naKve code (in most situaKons)
- 35. Ti.Next Goals • Massive maintenance improvements – Today: • separate teams per plamorm + core runKme team. Many different skills sets required. • TesKng is very hard, laborious, error prone. • Linear increase in cost for each new plamorm, version combinaKon – Tomorrow: • One main skillset: JavaScript • Be"er ability to reduce footprint in core runKme which will offer ease of maintenance and upkeep, easier to test • Adding new plamorms, features, version -‐ much faster, easier
- 36. Ti.Next • Extensibility – Today: offers same challenges. Each module requires naKve language skills and complexity. – Tomorrow: leverage same JS API to create cross-‐ plamorm modules – Impact: Module API will change dramaKcally, require new modules. Trying to find a way to have some level of module API for portability – but will likely only work in small % of modules.
- 37. Ti.Next • Tooling – Unique tooling per plamorm -‐> one set of tooling for all plamorms. Invest our Kme in new capabiliKes vs. maintaining mulKple integraKons – Much faster build Kmes and packaging. – Increased deployment and authoring opKons
- 38. Quick Demo?
- 39. Ti.When? • No idea at this moment J – Likely will be called Ti 4.0 – As usual, release oqen, release early – and transparently. – Want to have first set of developer builds available soon to GitHub repo – possibly in the next 45-‐60 days. – ProducKon builds are a ways away
- 40. Ti.Next Approach • StarKng with iOS, Android and Win8 as reference architecture. • Core runKme is based on JavaScriptCore (VM part of WebKit). – Leverage new iOS7 ObjecKve-‐C Framework – Ported new ObjecKve-‐C APIs to C#, Java – Built gyp-‐based build tools for Win, Android
- 41. Ti.Next Architecture • Small footprint “core runKme” based on JavaScriptCore and libffi – <5,000 LOC (vs. 100K+) – Micro-‐kernel design – Heavily opKmized for performance, memory footprint – Very stable, won’t change oqen – Exposes 2 APIs: • Core RunKme API same for plamorms, very few methods • Core Plamorm API different for each plamorm based on underlying plamorm API (Cocoa, Android, Win8) • Same design pa"erns and idioms
- 42. Ti.Next Architecture • Titanium APIs all implemented in JavaScript • Compiler at opKmizaKon phase will convert plamorm APIs into naKve code (ASM) • New plamorm APIs can be accessed without upgrade to new APIs (before Ti API work). • Similar to how node.js is built (from an API standpoint) • During development phase, no (naKve) compiler required