I have moved my project to prism 7.2
I have quite a few "OnNavigatingTo" and replaced accordingly with InitializeAsync or Initialize
If I remember correctly "OnNavigatingTo" was firing every time you navigated to a page whether to or back. If I was navigating back to a page it would fire whilst Initialize doesn't.
This whether correct or wrong is causing me issues with some of my pages where I was passing back parameters when navigating back .
Is this the intended behavior?
thanks
OnNavigatingTo was only ever supposed to fire once. It's intent was to initialize. There ended up being cases where it fired more than once. Anything you require done once should be placed in IInitialize.Initialize anything that should be fired each time you navigate or requires some logic like Navigated Back to... should be in INavigat[ed|ion]Aware.OnNavigatedTo.
It was this confusion that led so many Prism users to request that the support be dropped and a new API be introduced that made the intent clearer.
Related
I have a contact addition form that can be navigated to from multiple screens in our application.
Once the form is submitted, I then take the user to a screen to view the contact that was added.
When the user then makes use of the back button it should take them back to the screen that they originated from.
This might be the Android back button or one that calls the RouterExtensions back function.
I have made use of the navigate extra replaceUrl when navigating away from the form to the view page.
I have also tried using the skipLocationChange extra when navigating to the form but this creates more issues.
I have created a simple playground page flow that creates not quite the same issue but does throw an error that I don't know what to do with either:
https://play.nativescript.org/?template=play-ng&id=BfVcGZ&v=2
In our app, by making use of the replaceUrl extra, the back button does take the user to the correct page.
However, there is a brief moment where they see the form again. This isn't an ideal user experience.
In the linked Playground I do get an error:
Cannot reattach ActivatedRouteSnapshot created from a different route.
This seems to tell me that replaceUrl is indeed removing the page from the route table.
However, the page isn't destroyed yet and so the app is trying to show a page that it shouldn't.
replaceUrl is not yet supported by Page Router Outlet, there is an open feature request, you might want to register your vote on the feature and follow up there for further updates.
I have a challenge in my app that I need to resolve quick, the thing is I have to prevent the current component from being destroyed when I navigate backwards using this.location.back();
Based on my project I have an About Us link in my Login component that navigate to the About component using this.routerExtensions.navigate(["/about"]);, in the About component I added the back button that goes back to Login component as I described in the first paragraph. My problem is that the About component is destroyed and I need to prevent that.
Is there any way I can implement this functionality?
Thanks!
I have a Durandal App in an asp.net mvc project. It all works great but a few people mentioned the navigation didn't work. I then noticed that they were clicking on the links BEFORE the app was ready and the router was ready.
Does anyone have any suggestions as to how I can prevent the navigation being available until the app is ready?
You can throw up a full-screen scrim (or a block UI, as some people call it) that sits at a very high z-index, covering all content. You can even put a spinner within this scrim at the same z-index.
In the compositionComplete handler of your shell's viewModel, you can then hide the scrim. This proceeds on the assumption that the completion of routing and composition should signal the availability of your app. Bear in mind, though, that if you have AJAX calls (in the form of fetching data, etc.) that could tie up your app, you may need to align hiding the scrim to the completion of those calls instead. That should happen no earlier than compositionComplete.
The last sentence is a bit a tricky. Most of the time, you're fetching data in the activate handler, which is handled earlier than compositionComplete. There's no way to know if the AJAX fetch will complete before or after 'compositionComplete'. In these cases, it might make more sense to move the AJAX fetch to the compositionComplete handler so that you can better coordinate and time the hiding of the scrim to the completion of routing, composition, and fetching.
I'm playing around with the wearable SDK and created some additional pages for my sample app.
Is there a convenient way to dismiss / delete a single page by e.g. swiping?
I just found calls for adding, but not for removing (even after an action)
As far as I know, this is not possible, because even a multi-page-notification is (from a technical point-of-view) just one single notification which can only disapper in its entirety.
The only possibility I see here is to set a pending intent to a broadcast receiver, figure somehow out on which page the user was when dismissing the notification, and then create a new notification without this page.
I have a few pages in an Application that require A-Synchronous calls to be made for about 2-3 minutes to get Synchronized, the user may navigate away from that page during Synchronization and can come back again after visiting multiple pages and the sync continues all the time he is on other pages as well, when I go to a page from sync-page and press the Back button everything works fine.. but when i go to a page and navigate back to sync-page from Application Bar a new Instance of the Page is created and the Sync is just like Re-started.
Now i know every thing is working fine since new instance of a page is created when i call NavigationService.Navigate() , but what should i do in this scenario ? How to get the old instance of a page if it is there ?
Thanks...
You can't get an "old" instance of a page and it's not guaranteed that a backwards navigation will reload the previous instance of the page, it may be a new instance of the same page, but restored to the same state (assuming you saved any).
If you are trying to provide backwards navigation from the application bar then a) you probably shouldn't because that's what the back button is for, and b) you should make sure you use NavigationService.GoBack() instead of NavigationService.Navigate() because Navigate will always launch a new instance of your page.
If the page you want to get to is not the previous page, then it sounds like you are trying to implement non-linear navigation for which there is a recipe on the App Hub.
By the sounds of your scenario, you should handle this long running process separately (away from the view) and then display it's progress or results in a view when the user navigates to the relevant page.