facebook

Goback refresh

💡
Our Forums Have Moved

For help with installation, bugs reports or feature requests, please head over to our new forums.
Genuitec Community on GitHub

  1. MobiOne Archive
  2.  > 
  3. Getting Help – General
Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #337159 Reply

    RossL321
    Member

    Hi 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?
    Thanks

    #337214

    Hi 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?

    #337350

    RossL321
    Member

    Hi 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?
    cheers

    #337410

    support-michael
    Keymaster

    >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.

    #337505

    RossL321
    Member

    Hi 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
    Ross

    #337520

    support-michael
    Keymaster

    My 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

Viewing 6 posts - 1 through 6 (of 6 total)
Reply To: Goback refresh

You must be logged in to post in the forum log in