app.pane.history changes in the new release

8 posts, 0 answers
  1. Ron
    Ron avatar
    122 posts
    Member since:
    Sep 2011

    Posted 25 Nov 2013 Link to this post

    Since the Q3 release our code for navigation has become less than reliable.

    We used to use app.pane.history to figure out the context of where we are in the application and navigate based on this information. It seems that now app.pane.history only contains one entry of the initial view.

    Is there an alternate way for us to figure out where we are in the navigation and use that for our needs?

    Thanks,
      Ron.
  2. Petyo
    Admin
    Petyo avatar
    2439 posts

    Posted 25 Nov 2013 Link to this post

    Hi Ron,

    the Mobile application pane.history was an internal and undocumented structure. Since Q3, the application pane relies on the application router instance to maintain its view stack. This resolved several issues related to the mixed usage of hardware back button and app navigation on Android. 

    Regards,
    Petyo
    Telerik
    Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
  3. Kendo UI is VS 2017 Ready
  4. Ron
    Ron avatar
    122 posts
    Member since:
    Sep 2011

    Posted 06 Jan 2014 Link to this post

    Is there any way for us to implement it in some way that does not involve capturing router changes and building our own history stack?
  5. Petyo
    Admin
    Petyo avatar
    2439 posts

    Posted 08 Jan 2014 Link to this post

    Hi Ron,

    of course, such approach is possible. It will require overriding some of the mobile application internal methods - as such it is not guaranteed to work with future Kendo UI releases. 

    An alternative approach which may work for you is to use the mobile application instance router field and use its public API

    Regards,
    Petyo
    Telerik
    Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
  6. Ron
    Ron avatar
    122 posts
    Member since:
    Sep 2011

    Posted 27 Nov 2014 Link to this post

    When using the router object, can be sure that the back event happens before the change event?

    We want to build our own array to navigate with - based on the router events. Back events should pop a location from our array, Change events should push one. Unfortunately, both events are called on a back key without a clear indication that this is a change because of a back button.

    We noticed that when the change event is called after the back event, the backButtonPressed is set to false even after we press the back button that caused the change event - so we can not use this method to ensure that it is a change after back, but if we know for sure that change happens after a back, we can have our own global flag that will be turned on on back, turned off on change, and change will not push after a back event.
  7. Petyo
    Admin
    Petyo avatar
    2439 posts

    Posted 01 Dec 2014 Link to this post

    Hello Ron,

    the easiest way to verify that is to check the source code of the router - it is not that complicated. I think that the backButtonPressed flag should work (it is triggered when the hardware button is used, or a gesture is performed), as Kendo UI Mobile relies on it. 

    Regards,
    Petyo
    Telerik
     
    Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
     
  8. Ron
    Ron avatar
    122 posts
    Member since:
    Sep 2011

    Posted 01 Dec 2014 in reply to Petyo Link to this post

    First, I wish the documentation will explain that the back button is Android only - as when testing in the browser, the backButtonPressed  will not work when using the app's Back button.

    About looking at the code, that is nice for now, but what we really want to know is if we can be sure that it will continue to work this way going forward. Unfortunately, we already had to change our code once because of the changes to the history stack. There needs to be a documented stable method to perform this that we can use without fear that implementation details breaking it going forward. 

    If the goal of the router object is to overcome the use of the undocumented history stack, we need better documentation of the order of events as this is critical to the implementation on the App side. 
  9. Petyo
    Admin
    Petyo avatar
    2439 posts

    Posted 03 Dec 2014 Link to this post

    Hello,


    Like I suggested in my initial reply, the fields in question are part of our internal implementation, and, as such, their implementation may change in future releases. At this point, we have no plans in exposing these data structures for general usage. 

    A thing you may consider is to use the newly introduced browserHistory flag of the mobile application. It effectively detaches the app instance from the browser history, allowing you to manage its state manually. 

    Regards,
    Petyo
    Telerik
     
    Join us on our journey to create the world's most complete HTML 5 UI Framework - download Kendo UI now!
     
Back to Top
Kendo UI is VS 2017 Ready