The following proposal is made to help minimize number of round trips to the backend server. Any additions/suggestions are welcome and if there is already such facility available then definitely it is not documented.
Justification for the proposal:
For modularization purposes, it often common to designate a single view to represent data for different data sets of a single entity. For example a "Detail.html" fragment could be used to represent details for a "Person" entity where multiple "Person" entities exist.
The way bbUI.js is currently handling screen stack is, based on my experience, considering the above example, I can push multiple "Detail.html" with each invocation having its own parameters unique to it, and having a common "id" lets say "detail".
Currently it is designed such that bbUI.js does not maintain screen state which is true to an extent but as I figured out there is some amount of state being maintained "behind the scenes".
For example as I push out a number of "Detail.html" into the stack (remember this is the case of pushing same html page with the same id) with the same "id", with unique parameter set, now as I navigate back through the stack through popScreen, the framework displays the right screen instances in the stack meaning in the right order with the corresponding parameter set. So as you can see there is some sort of unique id tied to each screen instance (imagine it as an instance of "Detail.html" html fragment) which maintains the screen order, of course "id" and the parameter set that was used to invoke the screen instance. This greatly helps minimize the number of round trips already. All is good so far. But here is the problem.
My use case is a user pushes out multiple "Detail.html" instances into the stack. Within "Detail.html" there are multiple views of the data that needs to be fetched from the backend. As long as the user stays within the context of "Detail.html", once the data is fetched from the backend server, it is immediately cached for each view, so navigating between different views (imagine Pill Buttons) within "Detail.html" does not fetch data again from the backend as long as it is cached. But if the user navigates back from "Detail.html" to previous "Detail.html", the cache is destroyed. This is so that I dont want to accumulate too much cache data. So I have set a boundary for how long cache lives and gets destroyed which in this case is a Person context whose details are displayed within the "Detail.html". So the cache lives only within the Person context.
The problem surfaces when there is a child entities associated with the "Detail.html" like for example "AdditionalDetail.html" having its own "id". The idea is to not grab entire data set for each "Detail.html" invocation but, to limit the band width and fast user response, there can be a case where you download only limited data for each invocation of "Detail.html" and on demand basis request additional data when you invoke "AdditionalDetail.html". But when I invoke "AdditionalDetail.html", I am still within the same Person context. The issue is technically speaking an invoke to "AdditionalDetail.html" is just another push to the stack but conceptually it is a child of "Detail.html". When I navigate back to the "Detail.html" from "AdditionalDetail.html", only in this case, I dont want to destroy the cache for the Person context which was accumulated while in the "Detail.html" and vice versa when I go back again to "AdditionalDetail.html" from "Detail.html", I want to retain the cached data for "AdditionalDetail.html".
The way I ensure the cache is destroyed for each Person context (when multiple "Detail.html" instances in the stack exist) is I monitor for the "id" of "Detail.html" in onscreenready or ondomready (does not matter, well it does but its another discussion) and then destroy cache. But when I am navigating from "AdditionalDetail.html" to "Detail.html", this will destroy cache based on above logic.
So to ensure I can properly handle destruction of cache at the right context, as a workaround, I could create some global variables and have it work that way but it will be cumbersome and lots of maintenance. A clean technique to properly maintain parent-child relations between screens in the stack, is to be able to identify a way to inspect the stack and determine atleast the following id's id1, id2 & id3 below. Currently all that is being received is the current id that is being pushed into the stack
push Screen 1 (id1) >>>push Screen 2 (id2) >>>>push Screen 3 (id3)
I cannot tell you how to go about implementing the above gap but is something worthwhile to think about and also provide a solution in a more general sense without getting bogged down by my example (remember it is just an example that I happen to face in my application)
Please offer any suggestions/feedback. The current state of screen stack management is very basic and I strongly feel should be enhanced further to accomodate more generic scenarios.
Thanks for your time.
Any screen stack changes would have to wait until an overhaul to the framework. There's some work being done there that will be revealed in a little bit