This is a migrated thread and some comments may be shown as answers.

app.pane.history changes in the new release

7 Answers 116 Views
Application
This is a migrated thread and some comments may be shown as answers.
Ron
Top achievements
Rank 1
Veteran
Ron asked on 25 Nov 2013, 08:41 AM
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.

7 Answers, 1 is accepted

Sort by
0
Petyo
Telerik team
answered on 25 Nov 2013, 12:41 PM
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!
0
Ron
Top achievements
Rank 1
Veteran
answered on 06 Jan 2014, 05:22 PM
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?
0
Petyo
Telerik team
answered on 08 Jan 2014, 02:16 PM
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!
0
Ron
Top achievements
Rank 1
Veteran
answered on 27 Nov 2014, 07:24 PM
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.
0
Petyo
Telerik team
answered on 01 Dec 2014, 03:26 PM
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!
 
0
Ron
Top achievements
Rank 1
Veteran
answered on 01 Dec 2014, 04:52 PM
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. 
0
Petyo
Telerik team
answered on 03 Dec 2014, 11:38 AM
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!
 
Tags
Application
Asked by
Ron
Top achievements
Rank 1
Veteran
Answers by
Petyo
Telerik team
Ron
Top achievements
Rank 1
Veteran
Share this question
or