Titanium Community Questions & Answer Archive

We felt that 6+ years of knowledge should not die so this is the Titanium Community Questions & Answer Archive

my current take on titanium mobiles state

dear ti mobile dev-team, please consider 2 branches of titanium mobile for the future. one called "stable" that is used for bug fixes only, and another one for unstable or new features like supporting a new mobile platform. in its current state titanium mobile for me has too many bugs to simply just develop an app. while features that are stable can be implemented within minutes, others are too buggy to use or are not quite there. an example:

  • the tableview code in its current form is far too slow for using it with 1000 rows or more, takes 8 seconds on iPhone 3GS, up to 1 minute on older iPhones, for my app this is very critical
  • the header-index overlaps the searchbar in tableview
  • selections of group-styled tableviewrows at the top or bottom of tableviews are displayed as rectangles while they should have rounded corners.
  • packaging for ad-hoc distribution

these are bugs you cannot explain to customers by using words like "might be fixed soon"

i think instead implementing new features, the next release should be used for fixing bugs only

to those having a professional subscription, do bugs like these get fixed really within days for you?

— asked April 6th 2010 by Christian Sigl
  • bugs
  • iphone
  • mobile

3 Answers

  • We've done 6 major releases in the past 90 days:


    We've just pushed the 1.2 release with a ton of fixes from the 1.1 release we did 2 weeks ago.


    We've been almost solely focused on bug fixes. However, yes, we're focused on premium subscription bug fixes mostly. We're still fixing wide spread, community issues as we find them and as they're reported.

    To guarantee your issue will get looked at, I'd invite you to subscribe to Pro subscription.

    You could of course help with several other ways:

    (1) Fork the code at http://github.com/appcelerator/titanium_mobile and submit patches with any number of your own fixes. We'll gladly review them and consider them for inclusion

    (2) Write more test cases and try and reduce the issues above (except issue, which we already have reported) into reproducible test cases w/ logs

    Or, you can wait until we fix them. Sorry, we can't address all issues at the same time. We gotta prioritize somehow.

    In a totally separate question, a table view that loads 1000 rows is really silly. a user cannot practically scroll through that many rows. Really. You should really re-think your app design. Even big apps like Facebook only display 20-30 rows at a time of data since most humans cannot deal with that much data in one task.

    — answered April 6th 2010 by Jeff Haynie
  • using 1000 rows might not be the best option, but it's what my customer wants. he wants to display a table of famous quotes and scrolling through it should be done by using an index, or by searching within the results. what i'm talking about is, that it's taking too long for it to get displayed, which i think is related to the code used for creating tableviews (as fetching the rows is done after 1 second)

    don't misunderstand me, i think you are doing a great job with titanium mobile (i'm watching its progress since 0.6), however i think you should really fix some bugs first found in the non-paid community area, that are critical for its reception. display bugs like wrong displayed selections, index overlapping a searchbar, non-functional ad-hoc distribution are very critical to customers. i'm regulary watching the buglist on lighthouse and found that some bugs are pushed to future releases 2 or even 3 times. it's no problem with your priorities, but one isn't able to give exact dates for updates a customer might want to see, because of some bugs still in the app (like the mentioned "index overlapping the searchbar")

    regarding pro-subscription: paying for one month, does it mean, i'm subscripted for one year, or is it possible to buy support for one month, and quitting it afterwards? because i'm not only developing mobile apps i might not need first-class support every month. as a pro-customer do i get a compiled version of the sdk, after a pro-subscription bug has fixed?

    please open up the professional helpdesk section for reading those tickets, as i found that linked issues in the lighthouse-app can't be opened for community members

    — answered April 6th 2010 by Christian Sigl
  • Hi Jeff, Thanks for responding, I think there's a 'big picture' to this. Having worked for CIO/CTOs in several major corporations I found they place greatest faith in what their best devs tell them, many of whom will probably be getting familiar with Titanium through the community as we speak (prob in their own time, out of a personal fascination for new technologies).

    What's interesting to me here is whether Titanium is a 'product' or a 'service'. If the codebase is regarded as a product and yet use of that product in it's totality, implies purchase of a service. In that respect it seems like there's a misconception somewhere that fixing issues is part of the 'service', not the 'product'.

    I guess that says to me that the distinction between bugs and changes needs to be clearer, so that Appcelerator can point to the small number of 'bugs raised' (quality of product) and the large number of 'features added' (quality of service) and gain the kudos from that. Maybe (seeing that) Christian could then feel more confident, recommend Titanium to all his clients (potentially) and then subscriptions for him and his team would be a no-brainer.

    just a thought.


    P.S. I wouldn't expect access to issues raised through helpdesk to be made public, There is probably commercially confidential information/discussions that are private there.

    — answered April 6th 2010 by Chris Reed
The ownership of individual contributions to this community generated content is retained by the authors of their contributions.
All trademarks remain the property of the respective owner.