Notice: The Monaca & Onsen UI Community Forum is shutting down.

For Onsen UI bug reports, feature requests and questions, please use the Onsen UI GitHub issues page. For help with Monaca, please contact Monaca Support Team.

Thank you to all our community for your contributions to the forum. We look forward to hearing from you in the new communication channels.

Best way to use ons.enableDeviceBackButtonHandler()



  • Hello.
    Please what’s the best way to use ons.enableDeviceBackButtonHandler()?
    Should it be placed in the callback function for ons.ready() ?
    E.g.

    ons.ready(function () {
    
                ons.enableDeviceBackButtonHandler();
                ons.setDefaultDeviceBackButtonListener(function(){});
    });
    

    Furthermore, since ons.enableDeviceBackButtonHandler() relies on cordova.js should i wait for the cordova deviceready event before calling this method??

    Please, i ask this question because the documentation is not clear on this; and in my apps, i always end up with a race condition which makes ons.enableDeviceBackButtonHandler() not capture the device backbutton event.

    Thanks for your help and attention



  • Please does anyone have any insight into this yet?
    Thank you


  • Onsen UI

    @writeosahon It is enabled by default so you should not need to call it manually. This is just required if for some reason you call ons.disableDeviceBackButtonHandler(). before.

    If you want to set a specific handler, you can call ons.setDefaultDeviceBackButtonListener(listener) inside ons.ready. That should be enough. Note that Onsen UI will call first the components handlers (popPage in Navigator, hide in Dialogs, etc.).



  • @writeosahon Well it is a stand alone function and should not, as I understand it, be in the ons.ready() function. You also don’t have to wait for anything and there shouldn’t be a race condition as it would not be called until the back button is actually pressed which is captured by Onsen first. Do you have code that is failing?


  • Onsen UI

    @munsterlander I wrote it should be inside ons.ready but it’s actually just for safety reasons. I think it works well also outside it.



  • @Fran-Diox @munsterlander thanks for your explanations. This has helped to clarify alot of things.
    Please one more question. Assuming i have this code:

    <ons-splitter>
      <ons-splitter-side id="menu" side="left" width="220px" collapse swipeable>
        <ons-page>
          <ons-list>
            <ons-list-item onclick="fn.load('home.html')" tappable>
              Home
            </ons-list-item>
            <ons-list-item onclick="fn.load('settings.html')" tappable>
              Settings
            </ons-list-item>
            <ons-list-item onclick="fn.load('about.html')" tappable>
              About
            </ons-list-item>
          </ons-list>
        </ons-page>
      </ons-splitter-side>
      <ons-splitter-content id="content">
        <ons-navigator id="myNavigator">
          <ons-page id="page1">
            <ons-toolbar>
             <div class="center">Page 1</div>
           </ons-toolbar>
           <p>This is the first page.</p>
          <ons-button id="push-button">Push page</ons-button>
         </ons-page>
        </ons-navigator>
    </ons-splitter-content>
    </ons-splitter>
    

    This code shows ons-splitter that contains a ons-navigator, the navigator in turn contains a ons-page.
    Each of these elements has an onDeviceBackButton property. So, in what order will onsen listen for the backbutton event?
    My understanding is: it will start with the inner most element i.e. ons-paqe, then ons-navigator, then ons-splitter.; depending on which of these has an onDeviceBackButton set.
    Please is my understanding accurate?

    Thank you



  • @Fran-Diox Ah, ok. I have always just assumed from the docs that ons functions were stand-alone entities and didn’t need to be wrapped. I have coded my backButton handler outside of it without issue - at least so far, none have been reported.


  • Onsen UI

    @writeosahon Quite accurate. The algorithm actually takes into account the zIndex/visibility of the components. Therefore, first it will catch Dialogs (those can be at the body level but are still displayed over everything else) and then the rest of the components. Something like this: dialogs -> menus -> pages -> navigator -> app, I guess. More info here.

    @munsterlander They are defined at the same time so they are all available for sure. I think there nothing that actually depends on ons.ready, to be honest, so maybe just ignore my comment :sweat_smile: