Here is another compilation of weird Titanium gotchas that we encountered while building a fairly large-scale (100+ JS modules, 40K lines of JS) app with Titanium Mobile SDK 3.4.x.
- Under some circumstances (when in a TableViewRow with touchEnabled=false) the standard ImageView will not fire its load event.
- TextField and auto-focus/keyboard issues on android: if you add a textfield to a view, it will auto-focus, and the keyboard will come up onscreen when the view is loaded. To prevent this, set the text field’s visible property to false when you create it. Then in a postlayout event handler for the parent view, you can show the textfield.
- If you use a wrapper view to hold a series of vertically laid-out controls and then put that wrapper into a ScrollView, be sure to set height = Ti.UI.SIZE on that wrapper view, or else the ScrollView won’t work on iOS (it will work on android, though)
- If you use a view with a background color as a child of a TableViewRow, and you tap the row, the selectedbackground color will kick in and will wipe out the background color of all child views. Solution: use a backgroundImage of a solid color PNG with backgroundRepeat = true
- If a view has opacity = 0, it won’t respond to touch events! However, you can set the background color to ‘transparent’, and it will still respond to events.
- Watch out for adding event listeners to navbar buttons — you need to do these *after* the window is opened, or the listeners may not fire
- Also watch out for garbage collection on navbar buttons; you may need to make a global reference to those buttons so that they don’t get garbage collected. If they get garbage collected, the buttons will still be onscreen, but they will not work at all.
Icon fonts don’t work consistently. I had issues like:
- can’t use them on android in ActionBar menu items
- certain character ranges would cause emoji to show up on ios instead of the desired character
- even when I found a good character range, iOS 6 was showing empty boxes
- Scrollviews inside TableViewRows work on iOS, but not on android. Generally, this is not a good idea anyway, but there are some edge cases that I believe warrant this kind of approach. My solution was to use touch events on android and implement the drag-scrolling of the view myself.
- Speaking of this approach for implementing drag-scrolling with touch events, touchend/touchcancel/click fire inconsistently on android. Sometimes you would touch, move around, and let go, and you’ll get a touchend and a click. Other times, you would not get the click. Sometimes touchcancel would fire, and in those cases, you never get the click. Because of these inconsistencies, I don’t try to use the click event when I’m doing this sort of dragging; just use touchend, and then track the time between touchstart and touchend; if too long, assume the user was trying to drag, and don’t register a “click”. Also, if the user drags more than some very small amount, no “click”. It’s a royal PITA to implement all this, but it works.
- convertPointToView() doesn’t honor defaultunit setting in tiapp.xml; instead, it uses some horrible mashup of systemunits and default units as if it’s using system units to get the base rectangle of the parent view, and then using defaultunits to get the relative offset of the child view, and then adding them together!
- Touch events don’t honor defaultunit setting in tiapp.xml; instead, they use system units.