7. Views
• IDs and classes
• Platform and form
factor specific markup
• Inline events
• API parsers
8. Styles
• TSS format
• Titanium constants
• Localization
• Alloy configuration items
• Group by ID, class, or Ti API
• Device queries
• Global style
9. Controllers
• Element access via $
• Public interface via exports
• Compiler directives
• Backbone eventing
• Underscore and builtins
• Anything Titanium can do
MVC FrameworkCommon, uniform development patternSeparation of concernsViews, controllers, models… also styles, migrations, and a few other powerful featuresDeclarative UIXML-based representation of Ti APIMakes API usage much easierIncreased readability and scalabilityFree and open sourceAvailable on githubLots of contributions already (50+ forks, 250+ stars)Project transparencyHighly customizableOpen sourceWidgetsAdaptersawesome- No “why” slide, because it’s obvious- Will change the way you write Titanium apps forever
Hard to identify the overall structure of the UIComments are essentially making this readableRepetitive assignments of stylesNecessary to understand how certain APIs interact (addTab() or window as a creation time property)
UI very clearSeparation of view hierarchy and styleAPI level styling, less repetitionNo JS code yet
Single line of codeDon’t need to tell you the impact this will have on both beginner and advanced developersReducing learning curveGood developers are on a quest to eradicate code (more testing, validation, complexity)Ideas -> apps, even if you aren’t a developer by day
Brief overview of each folder in the structure.
175 lines of code Doesn’t even account for how you would interface with the widget (creating tables, handling the returned book data)You need to carry it aroundIt also wouldn’t manage the dependency on the loading widget
Alloy.CFGGenerated from your config.jsonGlobally available values based on deployment type and OSBuiltinsUseful JS libraries integrated with AlloyBackbone & underscoreGrowing list, string operations, titanium animations, social networkingOptimizationsUglifyjsEliminate dead codeCompiler directives (platform, deploy type)Errors- Catch all view, style, and JS errorsTabGroup will tell you if you aren’t adding tabs to it, or if you forget to add a window to the tabSame with navGroup
Surfaces potential errors- We’ll be able to catch errors that would occur under only certain circumstances at runtime at compile time instead. Think of the case of a Window that opens from a button click and that Window has invalid code/markup.
175 lines of code Doesn’t even account for how you would interface with the widget (creating tables, handling the returned book data)You need to carry it aroundIt also wouldn’t manage the dependency on the loading widget
