Introduction
28 views
Skip to first unread message
Matt Dean
Dec 21, 2012, 3:07:04 PM12/21/12
to titanium...@googlegroups.com
Hello everyone. You are probably wondering why this group exists given the fact that it's gone unused. I apologize for that and am working towards improving the communication and collaboration surrounding titanium-backbone.
This project grew out of my desire to add structure to the large apps I was building using Titanium. While Titanium allowed me to quickly become productive using my existing web development skills, it quickly started to feel like the early days of client-side javascript in the browser where code became unwieldy and business logic was scattered throughout the application. As a fan of Backbone.js in the browser, I sought to integrate the same structure with Titanium and was pleasantly surprised at how well that structure worked within the mobile apps. As an added benefit I was able to reuse the non-view Backbone code (mostly models) in the web interfaces that paralleled those mobile apps (in my case, we build mobile banking apps and online banking).
We now have three large apps built using Backbone with Titanium. While the concepts within titanium-backbone serve as the foundation for those apps, I semi-abandoned the open source portion of the framework so that I could move quickly and not worry about the repercussions to other users of the framework. For example, I found that memory leaks were a problem due to 'zombie' views and eventually discovered Chaplin (https://github.com/chaplinjs/chaplin) as a complementary architecture. In my own projects I used portions of the Chaplin architecture but it was several months before I convinced myself that it would be a good addition to titanium-backbone and not just my own apps. I was also a bit late to start using test driven development for the framework but have experienced huge gains from doing so.
What I'd like to do over the next year is:
1. Start from scratch with a test-driven development approach. Yes, much of the code will be copied and pasted from the existing code but it will be done so in a methodical way to make sure that the API is consistent (see #3 below) and that everything is well-tested.
2. Reduce the need to create custom versions of existing frameworks. For example, the 'View' class (https://github.com/trabian/titanium-backbone/blob/master/src/views/base/base_view.coffee) which serves as the parent of every view in the current version of titanium-view is based on Backbone.View but does not actually extend Backbone.View. This makes it difficult to integrate updates to Backbone. The refactored version will actually extend Backbone.View: https://github.com/trabian/titanium-backbone/blob/refactor/src/tb/views/base/index.coffee. This requires a zepto- or jQuery-like library so that Backbone can continue using $-based helper methods but those won't need to be updated on the same pace as Backbone.
3. Improve documentation and consistency. Right now I'm personally the only regular user of the framework, so most of the 'how to' is in my head. Not only does that make it harder for someone else to use it, but it also means that I find myself reinventing functionality because I can't remember how I accomplished something similar in the past (or even the fact that I did so).
4. Improve and share tools for developer productivity. This will initially mean a rewrite of the bootstrap process for starting a new project, but I've also built tools such as Sublime Text plugins that vastly improve my productivity when working with titanium-backbone and may be useful to others.
This project grew out of my desire to add structure to the large apps I was building using Titanium. While Titanium allowed me to quickly become productive using my existing web development skills, it quickly started to feel like the early days of client-side javascript in the browser where code became unwieldy and business logic was scattered throughout the application. As a fan of Backbone.js in the browser, I sought to integrate the same structure with Titanium and was pleasantly surprised at how well that structure worked within the mobile apps. As an added benefit I was able to reuse the non-view Backbone code (mostly models) in the web interfaces that paralleled those mobile apps (in my case, we build mobile banking apps and online banking).
We now have three large apps built using Backbone with Titanium. While the concepts within titanium-backbone serve as the foundation for those apps, I semi-abandoned the open source portion of the framework so that I could move quickly and not worry about the repercussions to other users of the framework. For example, I found that memory leaks were a problem due to 'zombie' views and eventually discovered Chaplin (https://github.com/chaplinjs/chaplin) as a complementary architecture. In my own projects I used portions of the Chaplin architecture but it was several months before I convinced myself that it would be a good addition to titanium-backbone and not just my own apps. I was also a bit late to start using test driven development for the framework but have experienced huge gains from doing so.
What I'd like to do over the next year is:
1. Start from scratch with a test-driven development approach. Yes, much of the code will be copied and pasted from the existing code but it will be done so in a methodical way to make sure that the API is consistent (see #3 below) and that everything is well-tested.
2. Reduce the need to create custom versions of existing frameworks. For example, the 'View' class (https://github.com/trabian/titanium-backbone/blob/master/src/views/base/base_view.coffee) which serves as the parent of every view in the current version of titanium-view is based on Backbone.View but does not actually extend Backbone.View. This makes it difficult to integrate updates to Backbone. The refactored version will actually extend Backbone.View: https://github.com/trabian/titanium-backbone/blob/refactor/src/tb/views/base/index.coffee. This requires a zepto- or jQuery-like library so that Backbone can continue using $-based helper methods but those won't need to be updated on the same pace as Backbone.
3. Improve documentation and consistency. Right now I'm personally the only regular user of the framework, so most of the 'how to' is in my head. Not only does that make it harder for someone else to use it, but it also means that I find myself reinventing functionality because I can't remember how I accomplished something similar in the past (or even the fact that I did so).
4. Improve and share tools for developer productivity. This will initially mean a rewrite of the bootstrap process for starting a new project, but I've also built tools such as Sublime Text plugins that vastly improve my productivity when working with titanium-backbone and may be useful to others.
5. Build a feature-rich 'Kitchen Sink' which demonstrates usage of the framework. This should include view-related items similar to what's available in Titanium's kitchen sink but should also show how to do things such as interact with a backend using Backbone's models and handle challenges that arise in large apps (how to prevent memory leaks, etc.).
You can currently follow the progress of these efforts in the '
I'd be interested in hearing from you -- what are your pain points when building apps for Titanium? What drew you to titanium-backbone in the first place and what are you hoping to get out of it?
Thanks and I hope everyone has a happy holiday!
Matt
You can currently follow the progress of these efforts in the '
I'd be interested in hearing from you -- what are your pain points when building apps for Titanium? What drew you to titanium-backbone in the first place and what are you hoping to get out of it?
Thanks and I hope everyone has a happy holiday!
Matt
Matt Dean
Dec 21, 2012, 3:09:00 PM12/21/12
to titanium...@googlegroups.com
Sorry, left an incomplete sentence in there:
You can currently follow the progress of these efforts in the 'refactor' branch: https://github.com/trabian/titanium-backbone/tree/refactor
Reply all
Reply to author
Forward
0 new messages