Closed TNT0305 closed 3 years ago
RequestPop in a given page is not called when PopToRoot is called on the NavigationController. Shouldn't it be called in this scenario?
Hello THT0305, sorry for long time response. Can you write more detail your question?
Yes. Within my app, the user can be in a navigation (map with driving direction announcements). In order to leave that screen, I ask the user if they actually want to quit navigation (users often accidentally hit the back button on android). After that, I clean up resources and leave the navigation screen. That prompt is facilitated by NavigationSam (Thanks!). However, I added handling app links to my app. In that handler, I call PopToRoot. If the user is on a screen where the RequestPop is handled, I think a call to PopToRoot should still trigger the RequestPop (or it should be configurable to do so). Thoughts?
@TNT0305 Let me give you a clear answer tomorrow, ok? And yet, you can take a screenshot of a piece of code where you use this algorithm
@TNT0305 Hi, I thought and decided that it would be more correct to do this:
Since the task of this module is to intercept UI Back button
p.s. If anything, I can help with the implementation of my idea.
To get the INavigationPopInterceptor from teh App class, should I do something like this?
int index = Application.Current.MainPage.Navigation.NavigationStack.Count - 1;
var curPage = Application.Current.MainPage.Navigation.NavigationStack[index] as INavigationPopInterceptor;
if(curPage == null || curPage != null && curPage.RequestPop())
{
Current.MainPage.Navigation.PopToRootAsync()
}
or is the a better/more reliable way to get the current page?
***EDIT I think I see the better way. NavigationPageSam has a "CurrentPage". So:
var p = Current.MainPage as NavigationPageSam;
var cp = p.CurrentPage as INavigationPopInterceptor;
if(cp == null || cp != null && cp.RequestPop())
{
Current.MainPage.Navigation.PopToRootAsync()
}
I was thinking, it might be good to have an optional message in the RequestPop. So like:
bool RequestPop(string reason = string.Empty)
That way, an opportunity is provided to allow a particular message to be shown to the user. In my case, the reason I would pass would be "QR Code scanned" and the final message would read:
Are you sure you want to exit navigation?
Reason: QR Code scanned
Since it is up to the user (me) to come up with the response to requestPop, it would be up to the user to include (or not) the provided reason. But at least with the parameter there, we have the opportunity. Thoughts? ***EDIT So as not to break existing implementations, it should get a different name like "RequestPopWithReason" or, alternatively, just another event taking the parameter (rather than the same event with a default parameter. So, INavigationPopInterceptor would end up with:
Task<bool> RequestPop();
Task<bool> RequestPop(string reason);
hmm. Then it would need to become an abstract class rather than an interface (so you could have a default implementation of RequestPop() that just forwarded the call to RequestPop(string.Empty) )
@TNT0305
Task <bool> RequestPop (string reason)
Not good, since the Module NavigationSam only uses back buttons to intercept and there is only one reason for interception - software back button.
The rest is the responsibility of the programmer. As an example, let's create a branch - a demo project for clarity.
@TNT0305 I creat branch for you demo https://github.com/scriptBoris/NavigationSam/tree/issue7%23demo
@scriptBoris , I take your meaning. Even if I did actually have a different scenario besides app linking to "irregularly abort" the navigation screen, the user knows what they just did. And thanks for reminding me about the "is" operator in your source code branch (I keep forgetting that one :p )
@TNT0305 if you problem is solved, can you close this issue?
p.s. And put a star on this github repository :)
RequestPop in a given page is not called when PopToRoot is called on the NavigationController. Shouldn't it be called in this scenario?