[TIMOB-13409] Android: Titanium.UI.currentTab.open(); parity issue on Android
| GitHub Issue | n/a |
|---|
| Type | Bug |
|---|
| Priority | Low |
|---|
| Status | Closed |
|---|
| Resolution | Won't Fix |
|---|
| Resolution Date | 2013-04-07T07:52:30.000+0000 |
|---|
| Affected Version/s | Release 3.1.0 |
|---|
| Fix Version/s | 2013 Sprint 07 API, 2013 Sprint 07 |
|---|
| Components | Android |
|---|
| Labels | qe-3.1.0 |
|---|
| Reporter | Eric Merriman |
|---|
| Assignee | Vishal Duggal |
|---|
| Created | 2013-04-05T20:40:26.000+0000 |
|---|
| Updated | 2017-03-22T22:59:02.000+0000 |
|---|
Description
Description:
A report came in from the field regarding a runtime error generated when attempting to open a tab with Titanium.UI.currentTab.open(). The behavior is that calling open in this way does not open a tab, but opens a new heavyweight window. On that window, when trying to open another tab in the same manner, a runtime error is generated because Titanium.UI.currentTab is null since not in a tabgroup.
Please visit github.com/veamon/Tabs for code.
Steps to reproduce:
1) Install project from github and launch
2) Note you are in tab group. Click "next"
3) Note you are not in tab group. Click "next"
Result:
Runtime error.
Expected Result:
If comparing to iOS, expect to stay in tab group and instead of runtime error, a new tab is opened.
Attachments
This is a basic difference between the underlying OS. The TabProxy comes with a built in Navigation Controller on iOS. So when you do a tab.open(window), we essentially push the window onto the NavController stack. So there is a direct UI relationship between the window and the tab. As such any window running its own context has a pointer to the tab and tabgroup. On Android the TabProxy has no NaviController equivalent. So when you do a tab.open(window) we are essentially opening a heavyweight window over the tabGroup. As such there is no UI correlation between the window and the tab which made the call to open it. Hence the window running in its own context has no pointers to the tab or tabgroup. So Ti.UI.currentTab will be null on android and will point to the hosting tab on iOS.
@Vishal, that doesnt seem to make since though, since it works fine on the 2.x SDK's, and not the latter ones. Something must have changed in between to break that functionality, and its also not noted anywhere in Kitchensink, or anywhere else.
A lot of things changed with 3.0.0 release wrt the TabGroup design on Android (Actionbar support). But to get back to the point as to why currentTab is null, lets say you have tabbed application and open a bunch of windows on the first tab. Then you go ahead and switch the activeTab on the tabgroup in response to some user action on the open window. On iOS there is an immediate visual feedback, since the window exists within the UI context of the tabGroup. On Android you wouldn't see anything until you actually closed all the open windows and made the tabGroup visible to the user. The tab.open(window) API exists purely for legacy reasons on Android. The opened window has no UI relationship with the tabGroup or tab.
@Vishal: if that's the case update the KitchenSink as everything crashes becuase of this
@Martin Agreed. If nothing else, it shouldnt be hard to just build that extra functionality in to keep the default behavior in place, so we dont have to completely rewrite our apps, or create custom functions. Personally, I'm staying with 2.15 until I absolutely have to upgrade.
Closing ticket as "Won't Fix".