1.using todays pull, build and install KS on device or\nsimulator
\n2.launch and note which tab is opened
results: opens to PLatform tab (tab3), when the script indicates\nit should open controls (tab 1)
\ntabGroup.setActiveTab(1);
\nthis just broke
changed erroneous title
This is an order of operations problem. Here's the issue:
\n\nvar tab4 = Titanium.UI.createTab({\n...\n active:true\n});\n...\ntabGroup.addTab(tab4);\n...\ntabGroup.setActiveTab(1);\n...\ntabGroup.open(...)\n\ntab4 is explicitly set as 'active', but then before opening the\ntab group itself, we set the actual active tab. So which takes\nprecedence? What if there's more than one tab marked as 'active'\nwhen it's added to the tab group before opening? Currently, the\nfirst tab in the bar with 'active:true' is focused.
\nWe need some clarification on the issue. The reason order\nstarted changing is probably because of an iOS change, where one\nproperty was being set before the other - wasn't this around when a\nnew 4.1b/4.1 was released?
I'm not sure I can answer these question (I'm not 100% sure\nabout the timing relative to 4.1), assigning to Ralf. If the\ncurrent behavior is correct, should android change its to reflect\nthis for parity?
I don't know much but my expectation would be that the active\ntab is set to 1, and that should be the active tab, which seems to\nbe the old behavior on IOS and the current behavior on Android.
\nTo keep compatibility and just my instinct tells me we should\nhonor the \"last\" setActiveTab execution, if more than one\nexists.
Here's the problem. I do the following, instead of what's\ndescribed above:
\n\ntabGroup.setActiveTab(0);\ntabGroup.add(Ti.UI.createTab({\n active:true\n})\ntabGroup.open()\n\nWhich one gets respected? We have no way to tell which was set\nfirst upon opening. We should simply say that the order is\nundefined.
Sorry, changing back to needs-more-info.
Steve, it is always the last.
\nFundamentally whether by setActiveTab or via tab.group.add(...\nactive:true), the last one wins before the tabGroup.open()
\nAt the point of tabGroup.open() it should be the tab that was\ncreated and added in your latest example.
My point is that we don't KNOW which change was last when the\ntab is opened. It's obvious in the user's JS, but that's not how\nTitanium works internally - all properties are, for all intents and\npurposes, set in a specific order all the time always (there are in\nfact a lot of features which depend on this) upon certain\noperations (in this case, opening the tab group causes all of them\nto be set \"for real\").
\nSo we can't determine that information from property settings on\neither the tab or the tab group. The order is thus indeterminate\nand we should document it as such.
(from [aa66687741d962455f0d191e06e872b628f85ff9])\n[#1773 state:fixed-in-qa] Documentation updated\nto reflect ambiguous ordering of tab activation. \nhttp://github.com/appcelerator/titanium_mobile/commit/aa66687741d96...
Question:
\n\ntabGroup = Ti.UI.createTabGroup({\n activeTab:1,\n tabs:[\n tabGroup.add(Ti.UI.createTab({active:true}),\n tabGroup.add(Ti.UI.createTab({})\n ]\n })\ntabGroup.open()\n\nEntries in a dict/object are unordered. Who wins?
OK, let's take a deep breath everyone. :)
\nLet's all think the rationale for having an \"active: boolean\"\nproperty on Tab.
\nWhy do we need it?
\nI think the undefined issue (above) would go away if it was\neither \"deprecated\" or \"read-only\".
\nWhy don't we think about this, and \"do the right thing\" if we\ncan.
Steve, I'll take it back and change the state.
\nWhen we understand the rationale and arguments, we'll have to\nmake a call make it part of the \"spec\" that doesn't exist now but\nwill exist sometime soon. :)
That sounds good. For now, I'm leaving the documentation change\nin.
\nThat's a good question. Tabs should have 'active' as a read-only\nproperty to determine whether or not they're the currently\ndisplayed tab.
What did we choose on this, again?
The comments above are relevant. I will have some interesting\nobservations in our upcoming API scrub.
\nIf we see this as an \"ordering issue\", please make sure that our\nKS code is \"fixed\" to launch to the first tab on both\nplatforms.
\nAssigning to Steve to fix KS ASAP!
(from [e3c8d2a13c626d84582035d4217bd4ec7ab8508f])\n[#1773] Updated KS to always start on 1st (Base\nUI) tab, unambiguously. \nhttps://github.com/appcelerator/titanium_mobile/commit/e3c8d2a13c62...
Setting to TBS because the requested KS change was made.
Hey Stephen - I believe we need to keep line 90. If we comment\nout both 90 and 57 we get default tab set, which gets rid of the\ntest in KS. I ran this by Blain and he agrees. Ralfs at lunch right\nnow, wanted to send this back.
\ntabGroup.setActiveTab(1);
(from [cf498dde5a379ec9b361ff20bc8e694c1e83177e])\n[#1773] Provided requested fix. NOT marking this\nbug fixed because the underlying issue is not resolved. \nhttps://github.com/appcelerator/titanium_mobile/commit/cf498dde5a37...
The observations are correct that the order cannot be determined\nesp when using the activetab property.
\nIn a future API scrub, we will discuss this property. If it\nshould exist at all maybe it should be read-only.
\nThe only remaining question is setActiveTab().
\nMy opinion is that if multiple calls exist, the last call to\nthis function should be the tab that is active. Again, fodder for\nour API scrub.
\nOur KitchenSink example is fixed and works the same on both\nplatforms as it should right now.
\nMy action is to place it in the TBS release, with\nneeds-more-info state and another tag stating it is due for API\nscrub.