I am completely confused as to how Android handles window and field focus and blur events vs. iOS. If I set up a simple window with one text input field, and set focus and blur event handlers on both the text field and the window, and just open the window, here's how the two OSs work:
[INFO] WINDOW FOCUS event: src=[object TiUIWindow], typ=focus, val=undefinedThis is as I expect.
[INFO] [397,1067849] TEXT FOCUS event: src=[Ti.UI.TextField], typ=focus, val= [INFO] [4,1067853] WINDOW FOCUS event: src=[Ti.UI.TextField], typ=focus, val= [INFO] [5,1067858] WINDOW FOCUS event: src=[Ti.UI.Window], typ=focus, val=nullI get a focus on the text field, a window focus coming from the text field, and then another window focus coming from the window itself(!). I understand that the order of the info messages may not be correct due to the async nature of event handlers, but why are so many events coming out? Does Android pass along focus/blur events to all listeners regardless of who processes one?
Further, if I add a 'return' event handler on the text field in Android (for the keyboard Done or Return button) to call the '.blur()' event handler explicitly (otherwise the keyboard closes but no event is detected), I get this interesting mix of events:
[INFO] [3154,1564119] TEXT RETURN event: src=[Ti.UI.TextField], typ=return, val= [INFO] [38,1564157] TEXT FOCUS event: src=[Ti.UI.TextField], typ=focus, val= [INFO] [9,1564166] WINDOW FOCUS event: src=[Ti.UI.TextField], typ=focus, val= [INFO] [9,1564175] TEXT BLUR event: src=[Ti.UI.TextField], typ=blur, val= [INFO] [23,1564198] WINDOW BLUR event: src=[Ti.UI.TextField], typ=blur, val=In iOS, I get one TEXT BLUR event. Here is a pastie of the sample code showing the above behavior.
Is there a way to suppress further event handling by returning a true or false value, or some other workaround to get the behavior I need?
Running 1.5.1 and Android SDK 2.2; iOS 4.2.
a new better solution / workaround...
when spawning the new child window, I now add a 'close' event listener to the new window that calls the function I wanted called on the return 'focus' event... so it's not the focus event calling it at all, but it gets done anyway by the window closing...
and thanks Kevin and the rest of the team. I know you've got a beast of a job, and balancing cross-platform stability vs. us all clamoring for the newest features must be quite a challenge. I still appreciate the tool immensely, (couldn't do what I'm doing without it!) but just wanted to put my opinion forward that I, for one, would prefer cross-platform uniformity and stability over cutting-edge features.
I was experiencing difficulties with the window.focus event in android, and here's how I solved it - perhaps it will help others... but it's still messed up!
I was opening a new window (used for setting prefs) and wanted an event to run when the user closed the prefs window, and returned to the original one. The focus event was firing on iOS, but not android. IF, however, I added an automatic call to the focus() event on any object in the new prefs window -- I focused on the table being used for choices eg. tableview.focus() -- when I returned to the original calling window, the window.focus event fired!
of course, THIS solution DIDN'T work on iOS - threw an error: tableview.focus() [undefinend] is not a function. Same error doing it to the window, to a button, to a textfield, or view... don't know what I was doing wrong there...
BUT... if the prefs window included ANOTHER window (with an admob function in it, which basically created a webview pointing to the admob code), then when I exit back to the original calling window the Android and iOS 'focus' event gets called...
hope that helps! David
BTW - - WHY is it so difficult to do cross-platform development on a platform that exists to make cross-platform development easier? Every time I've got something working on one platform, it DOESN'T work on the other. It's almost more time-consuming than coding them separately! :-)
Event propagation does work differently in iOS versus Android. In Android, events tend to bubble all the way up through the hierarchy, and we don't currently have a way to cancel the rest of the chain. That's an area where we're looking to become more consistent in 1.6.0 (consistent behavior cross-platform, and sane interpretations of when an event should be triggered on an object).
In the meantime, you have found the best way to react to this in your code. Window focus is particularly chatty, so it's important to check the source of the event to determine how the event was fired.
Think you can help? Login to answer this question!