For help with installation, bugs reports or feature requests, please head over to our new forums.
Genuitec Community on GitHub
- This topic has 5 replies, 3 voices, and was last updated 12 years, 5 months ago by
support-michael.
-
AuthorPosts
-
RossL321MemberHi again,
I’m trying to implement a simple list page that allows an item to be selected from a list and viewed/edited on another page. All good.
I added a button to initiate a new instance, again all good.
When I use the back button from the instance page, I want to see the new instance on the list page, but I don’t. Not good.
I looked for phoneui events firing that I could intercept to refresh the list page content, but my knowledge is a bit short in this area. It seems that the back button simply drags the previous page out of the cache via the history.go(-1) function.
What can I do?
ThanksMarch 28, 2013 at 8:27 pm #337214
support-octavioMemberHi Ross,
So you have a master-detail patterned UI. To help me understand the issue, when returning to the master screen from a detail screen is it reset or scrolled or some state other than showing the object selected. Perhaps you can provide before and after screenshots to help us grok the UI state?
Also, does your detail screen use a Back button widget with Back() action or does it use some other widget with a GotoScreen() action?
April 1, 2013 at 6:03 pm #337350
RossL321MemberHi Octavio,
Thanks for your reply. I can add a bit of colour to the problem for you.
First of all my master detail screens are served as seperate html files, I don’t ‘bundle’ them as Mobione does when you add them as additional project files. I find this makes the custom js scripts way too complicated. You do lose some of the fancy sliding features, but I can live with that.
I did originally used the Back() function for my button, but the screen is viewed exactly as it was when you clicked on the ‘+’ button to add a new instance, presumably it comes straight out of the cache. There are no events fired, that I can find. If I could trap an ‘activate/reload’ event then I could refresh the master screen to include my new instance.
So then I switched to using a window.location to go directly back, which would reinitialise my master screen, but that messes with your history and you lose control of that which effectively destroys the reliability of the back button on your master screen. I assume the GotoScreen action would result in this same kind of page switch. Implementing it in the custom code file gives me better control over the href parameters, so no, I don’t use an action on the button directly, I call a js function to do it.
What I want to happen is for the master screen to appear not necessarily as you left it (I can live with that), but to at least include my new instance. These two things are probably mutually exclusive anyway.
Am I missing something here?
cheersApril 2, 2013 at 6:40 pm #337410
support-michaelKeymaster>What I want to happen is for the master screen to appear not necessarily as you left it (I can live with that), but to at least include my new instance. These two things are probably mutually exclusive anyway
While you said you are handling all js yourself please note there are 2 callback functions that should be useful here: prePageTransition() and postPageTransition(). These 2 functions are stubbed out in the xxx_custom.js file. Use one of them to make adjustments to the master page either before or after you return to it.
April 3, 2013 at 11:30 pm #337505
RossL321MemberHi Wayne
Thanks for your advice, but unfortunately I have looked at that and I find that these two events don’t get fired in the case where you are going back after navigating with a ‘window.location’ event. It is fine if you are navigating using a ‘goto screen’ action. but it would seem that the browser has the parent form cached and it simply re-displays it when you go back to it after a window redirect.
As I explained, I am not doing it the screen action way because that requires that the child screen is included in the same html file when you build, which requires then that all the custom logic behind the child screen is merged with that of the parent, which has to be managed manually, and it then requires lots of care to ensure you work within the context of the currently visible part of the combined html document.
So my design is to keep all the builds for each screen separate and code the navigation as you would for standard html pages without requiring the functions exposed by phoneui. I’m also not using any web form features like actions and methods. I don’t really understand the impact of turning forms on, I am deliberately trying to keep my server side processing as light as possible, just the page and the web services for the data. Perhaps this is what I need to do, I seem to remember that there were some pre and post web event stubs generated at one stage!?
I would be interested in your thoughts, and any solution you might be able to suggest of course.
regards
RossApril 4, 2013 at 8:22 am #337520
support-michaelKeymasterMy understanding is you have your own screen transition strategy and want to implement something similar to what the prePageTransition() or postPageTransition() callbacks would do. This is a general web programming challenge that you can google on. I did a quick search and identified some resources on stackoverflow such as:
http://www.bennadel.com/blog/1520-Binding-Events-To-Non-DOM-Objects-With-jQuery.htm -
AuthorPosts