UI Shell - how to allow ADF Library Bounded Task Flow to close itself

Question

Hi Richard
Further to my other post, we're having lots of fun with the UI Shell, it's making mockups very easy.
Question for you though based around the functionality defined in the UI Shell whitepaper. Say we've created our UI Shell application, and rather than wanting to create the bounded task flows in the app (ie.first, second, third), we create them as standalone bounded task flows deployed to ADF Libraries, and imported into our app separately.
In the UI Shell examples bounded task flows are opened & closed via the UI Shell's own components (say the navigation page items or toolbar buttons), that call the methods in the Launcher bean (_launchActivity & closeCurrentActivity). It's fairly simple to rewrite the launcher helper methods in the launcher bean to call an imported ADF Library bounded task flow to open it as an activity, just referencing the correct task-flow.xml file.
However as you know a bounded task flow has a "Default Activity" entry point and one or more "Task Flow Return" exit points. What I haven't been able to work out is how when the bounded task flow exits via a task flow return, can we call the closeCurrentActivity method in the Launcher bean? The UI Shell code examples demonstrate closing a bounded task flow by menu options/or similar outside the bounded task flow in the UI Shell, but it would seem reasonable if the bounded task flow exited via a "Task Flow Return" we should be also able to close the activity tab too.
(....and as extension, before we even do that potentially call the checkState/isDirty() method to stop the user closing the activity too, but again driven by the bounded task flow attempting to exit).
I could imagine inserting code into the bounded task flow finalizer to close the activity tab, but this pushes the UI Shell tab activity management logic into our standalone ADF Library bounded task flows which isn't ideal, especially if we want to later reuse them in another app which doesn't use the UI Shell.
Any suggestions welcome.
Thanks & regards,
CM.

Answer 1

And we're back again.... what's a couple months between friends?
So it turns out after testing our app (d@mn, so close) that we've hit a bug with this approach.
Our current app allows one BTF to be open in the UI Shell at any one time. Our menu options automatically open one BTF at a time by the user (max one open), and close the previous BTF. However we have some "special" BTFs that require the user to explicitly close the BTF, which in turn makes use of the regionNavigationListener solution I described earlier in this post.
However we discovered a bug when we do a complete cycle of the 15 embedded regions within the UI Shell.
Say we:
1) Open a normal BTF in region 0
2) Open another normal BTF in region 1 (our solution automatically closes the previous BTF)
3) We then open another BTF (again the previous BTF is closed) in region 2, yet this a "special" BTF requiring the user explicitly to close it. Upon the user closing the BTF - this results in the regionNavigationListener being called and the removeTab() method called to close down the BTF in the UI Shell
4) The user then open/closes multiple normal BTFs, one by one, rotating through regions 3, 4, 5 .... eventually back to 1 again
5) Then the bug occurs - on opening any BTF back in region 2 (as part of the complete cycle of all regions), the tab for the region 2 opens, correct title, and via debugging the Tab.class has all the right settings including taskFlowId, but the tab is incorrectly empty
doh!
I've managed to track a symptom of the problem down that may explain what's happening.
Each time a tab is rendered with a BTF, the Tab classes getBinding() method returns a reference to the binding required for the current BTF. However for some reason on the complete cycle, for "r2" it returns the binding for the previously user-closed BTF from step 3 above, even though we called the TabContext.removeTab() method.
What I haven't been able to work out is how the bindings get turned on/off dynamically for each BTF being invoked. Presumably for some reason on step 3, the BTF's bindings aren't being correctly removed from r2 even though we called TabContext.removeTab().
If anybody has any brain waves about what's going on and how to fix this problem, your help appreciated.
Regards,
CM.