I am trying to create a “back” button and a “forward” button for browser navigation on a mobile phone. Is there a straightforward way to do this? I was going to create a custom property on a header called urls (as an array or object) that will receive messages via message handler that contain the url of the page just opened, which is then appended to the urls property. Pages can then be navigated back and forth with this. That seems like overkill and a really roundabout way of doing it.
Also, is there any way to get the current view and current url on the page you are on? For example, if I am at view “Main/Home View” and url “/home”, how can I get these out? I’d imagine that data is contained in the “view” object (e.g. a property of self.view), but I could not find this. Any ideas?
There’s no way to directly access a View’s URL because you could theoretically have multiple URLs pointing to the same View. From an Ignition design standpoint, a “Page’s” View has no idea what its URL actually is.
That being said, you can set custom PROPS on your root if you KNOW you’re always going to use a url for a View, and bind a Label to those properties (this is can be incredibly misleading however, as you can navigate to Views WITHOUT changing your URL).
As far as the “back” and “forward” functionality, you’d most likely want a header/footer with the back/forward buttons.
You could then create a custom Session property (NOT a tag) which is an array.
You’d also need a custom session property which tracks the length/currentIndex of the navigation_url array.
The hard part wold be that you would need to make sure that EVERY navigation call except for the forward/backward navigation calls wrote to the end of the array.
All in all, this would not be easy, and you’d also run into issues whenever you do navigation to a View or external URL.
From a mobile design point, you should strive to keep your page navigation depth to a minimum so that it only takes 1-3 clicks to get to any page from a navigation menu (one click to expand the menu, a second click to change categories, and a third to locate the page you want).
If you want a breakdown of exactly what properties you can access in relation to your View, this is the structure you can’t see - all other properties you can see by looking in the Perspective Property Editor:
You’ll notice that “props” is empty, and that’s because all of the properties are set to default unless you change them - if I were to change my PROPS.defaultSize to 900 instead of 800, I’d see
Thank you for the response! You totally confirmed my suspicions, and also confirmed that that “back” and “forward” functionality should be implemented in that manner.
Also good to know what those hidden view properties are!
You’re welcome. Don’t forget that if you ever need to see exactly what properties are in place for a View/Container/Component, you can always hold Shift and then right-click your View node in the Project Browser (NOT the root node, but the named View). Select ‘Copy JSON’, and then paste that into a text editor - you now have a visual representation of every property within the View (declared but blank properties are considered to be retaining their default value).
I understand the solution here, but as you indicated it is rather cumbersome and not easy. Can we request a forward/back button feature? It is pretty standard on many operating systems to have that capability and it would be much cleaner (and less work) than this solution.
Your request is a little unclear. If users are using a browser (desktop or mobile), then the browser should be used for going back and forth. If the user is using the native app, then they should be able to go back by swiping from the left edge to the right. In speaking with our mobile developer, it sounds like there was some discussion already regarding “forward” in the apps and the idea was nixed. So if your request is for that area, you can use the ideas forum to reintroduce discussion of such a feature, but it sounds like we already decided against doing so.
I don’t recall the behavior of the app, but in a browser it only will go back to the most recent “page” not “view.” I was hoping to be able to go back in views that had been opened.
I might be misunderstanding you, but the ability to go back-or-forward amongst the VIEWS displayed sounds like a very bad idea.
Here’s why:
“Page” navigation is mediated by browsers, in that they maintain a registry of urls visited and therefore are able to perform the back-and-forward of pages with no overhead placed on the user/integrator, which is why we recommend structuring in a way where using urls makes sense.
“View” navigation would be required to be limited to the current Page, because if you do navigate to a different Page you don’t want to navigate to a View a different Page used.
If this idea were to implemented, you’d have a totally proprietary navigation paradigm in place which mirrors a similar universal paradigm but which all users would now need to learn the subtle differences between lest they become lost in their own project.
The browser button is fine in how it functions, but my customer wants to have a forward and backward function in the header because they are going to use the application on full screen.
Is there a way to call the script attached to the standard back and forward arrow in the browser or do i really have to do all the things described in this forum with session properties…
“Page” navigation is mediated by browsers, how can we trigger the backward and forward buttons from the browser inside perspective?
The customer wants his application at full screen so the buttons itself are not available for them. I want to create a custom header with those buttons inside so they can navigate. The only thing I can think of creating it myself is to get the primary view on navigating and use that one to navigate, but thats view based and not url based.
If there are no better answers. You can mimic the hotkey of the back button for the browser. For example [alt+left], is back for google chrome. Put that on the script of your button
You can’t send arbitrary keypresses from Javascript - otherwise, any malicious page you visited would be able to completely control your computer.
There’s an active feature ticket in the backlog to provide some means to access the window.history object, which has back() and forward() methods that do what you’re asking for - the same action as the browser’s back and forward.
It’s impossible to say; there’s about a million factors that make it difficult to estimate. Also, we’re using a release train model, so there’s no ‘waterfall’ of specific tickets → specific versions. The most I’d say is more likely 2020 than 2021
Also when it is possible to mimic key presses we can just add components in script at runtime.
due to the "ctrl - v" command. should be an nice option.
