Can't Intercept Software Back Button #1944
Comments
We had a similar discussion here. Is this what you're looking for? https://forums.xamarin.com/discussion/100287/allow-a-single-place-to-handle-back-button-requests-with-async-support |
@samhouts Yeah that's pretty much exactly our issue. The aforementioned callback needs to be added to the codebase or the existing method needs to be enhanced to include events from the software back button. |
@samhouts is this bug accepted yet? It's a big issue. What more information is needed? |
I agree in the point that OnBackButtonPressed should handle both Hard- and Software-BackButtonss. Nonetheless, it isn't that hard to interecept both of them. I blogged on that topic here: https://msicc.net/xamarin-forms-the-mvvmlight-toolkit-and-i-taking-control-over-the-back-buttons/ |
@MSiccDev If we keep working around the problems presented by the framework, then it'll never get fixed and people will have to keep doing this themselves over and over again until the death of the technology. |
@AceCoderLaura true on one side. On the other side, one has to move forward. Best thing is to work around but report the issue. |
These workarounds break the hamburger menu on the root page... |
@AceCoderLaura I am using it in one of my apps with a MD-Page without any problems... |
@MSiccDev
|
@AceCoderLaura Are your OnOptionsItemSelected triggered after click on the nav-back button oO In my case, nothing happened...(Android) |
Is there any progress for this issue? I have multiple nested navigationviews and it would be ultra hacky to patch this in my application. I aggree with @AceCoderLaura that this must be patched by xamarin. |
Same problem. I think it's quite common to handle back event in enterprise app. It should be fixed asap. |
Please fix this, it's been reported for close to a year, and it's ridiculous not to have it yet. |
@ddobrev You're right this is a very useful feature, but unfortunately it hasn't even been clearly defined how it needs to work. Someone mentioned above it but it got no response:
Had this been clearly defined, I'd have tried to make a PR to implement it. |
I dont know why, but in my case (on Android) was enough to add this to my MainActivity
With this the OnBackButtonPressed is fired both even if i press the hardware back button and the software back button on the navigation bar. But i don't understand why. On iOS I still had too add it myself with a custom Page renderer. |
So, is this going to be fixed in 3.6.0? |
I think it was moved to In Progress by mistake. |
Ok, team, we're now leaning towards the functionality described here: #6971 (comment) Any objections? |
@samhouts I took a quick look at the linked issue and since I haven't used shell yet this is more of a question. Basically, it's not about intercepting the reverse navigation but instead taking control over what exactly happens when a user attempts to navigate back via any method available (swipe, navbar button, android button,..). I can decide to navigate the user to a new page instead of navigating back if I decide so, is that correct? |
@samhouts I have a working interception in my production app for iOS uwp and Android. iOS and Android using custom Page renderer. When User naviagtes back via Software or Hardware Back-Button I can Show Pop-up "Discard Changes?". When the User confirms the prompt, Back navigation ist executed and Page gets popped, otherweise User stays on current Page. I have Not yet considred that swiping ist also possible to Go Back, thats Missing in my Implementation |
@samhouts - It's not clear to me how the proposal allows interception of the back button to add a conditional step. Does the proposal work like this?
async Task MyProcessBackButton(bool usingShell)
{
bool navigateBack = await DisplayAlert("Cancel?", "Undo changes", "Yes", "No");
var mainPage = usingShell ? (Page)Shell.Current : Application.Current.MainPage;
if (mainPage is MasterDetailPage mdPage) mainPage = mdPage.Detail;
if (navigateBack) await mainPage.Navigation.PopAsync();
} Something like that should work for me but it seems cumbersome. Maybe I'm not looking at the proposal right. It would help to see the use cases spelled out with examples. P.S. Like @nschoenberg, I also have interception with custom renders in my apps (on NavigationPage, doing something like the MyProcessBackButton method above. It is nice that the proposal is not requiring Shell - it will allow easier adoption for our older apps). |
This is how I would imagine it to work, often we want the default functionality if not overriden. This would behave the same as overriding the device back button on android and returning true. Doesnt it make sense to replicate that implemenation in someway?
In the issue #6971 (comment), I am not sure exactly where the BackButtonCommand will be exposed, is provided only on NavigationPage? Is there a single implemation on a containing NavigationPage and all pages pushed onto the that navigation stack use the same behaviour? (I dont feel this would be a typical use case). How do individual pages implement their own override and take advantage of the command? I think the proposal provided above would satisfy the developers needs to override per page, since the invocation of back navigation is some what irrelevant often the dev wants to simply control what takes place on the back navigation i.e. prompt some user dialog prior to send them to another page or simply leave as default. I cant speak for everyone but we have instances in projects where we implemented some function that get excecuted if software button pressed, we also override the |
These properties all work the same as any of the attached properties on NavigationPage https://github.com/xamarin/Xamarin.Forms/blob/master/Xamarin.Forms.Core/NavigationPage.cs#L19 You can just apply them to the active page and the NavigationPage reacts. The attached properties are nice because they are bindable so you can just set it up on a page and bind it into the VM. <ContentPage NavigationPage.BackButtonCommand={Bindiing BackCommand} One of the advantages of having the command just "disable" the default behavior is that it enables async navigating. Because now the button just routes to the command and the command can do whatever for as long as it wants and then it can use navigation apis to complete the navigation if it wants to. Making it all async is interesting mainly because of scenarios like swiping back or swipe to dismiss on a modal because those aren't natively "async" so what we could also do here is tap into those gestures, route to the command, and cancel the gesture. We could also make it an event on the Navigation class which could fire all the way up the hierarchical proxy and then with an event you could use an EventToCommand Behavior. I do also wonder if NavigatingBack makes sense. If we're going to have something like that the might as well just create a navigating event similar to shell. I realize this is a bit rambling :-) but just wanted to answer some question and get some ideas down for discussion |
@PureWeen sorry forgot accessing properties was possible on a pages that way & that makes sense to do it that way anyway. Would the NavigationPage.BackButtonCommand consume the device back button also or just software back button? Since there are other ways of invoking back navigation. |
Currently I'm thinking NavigationPage.BackButtonCommand goes away and we have something more generalized. Just need to give it a bit more thought. Something tied to pop/push might make sense and match existing apis Not these exactly but something along these lines UserRequestedPoppingCommand Or possibly PoppingCommand and PushingCommand and then we can have something similar to your arguments that give context. enum NavigationSourceType {
Unspecified,
HwButton,
Navbar,
Gesture,
FromCode
} I'd like to make it all bindable as well but I haven't quite clicked into an idea I super like yet. Perhaps something on Navigation that indicates current state of navigation? |
Any update on this? We have been waiting on this for over a year. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Hello, is there any news? |
@scriptBoris Possible work arounds are as followed in these links, one solution might fit better then the other depending on your project structure. https://forums.xamarin.com/discussion/67854/android-menu-and-back-button-not-working Ive gotten both solutions from the links in seperate projects. |
Good afternoon, I apologize for disturbing you, but is there any news to solve this problem? О.О |
I am updating the question :) |
|
Is there any update on this? The solutions presented in this thread are more than acceptable, its been years and people are waiting for this. |
Can anyone from the Xamarin team comment on the status of this? This really is a big issue for many people. I know you can do this in shell, but for many larger apps that take advantage of Prism or MVVMCross shell is not fully supported so this is something we really need. Thanks |
Apologies @akemper1 but no specific updates currently. We haven't forgot about this one but are just a bit delayed on an official API to settle on. There are some pending Shell PRs that influence Back Button that will propagate over to the APIs used here |
I agree with many that are saying this is a big issue for them. I am going to give some of the workarounds a try though. I just want to be able to prevent a user going back until they "confirm" that they will lose changes on the page they are on. |
any news about this? it's been a really long time :( |
Hi team Xamarin.Forms, is there any news on this issue? |
3 years have passed, Xamarin.Forms 5 is released, and the problem has not yet been resolved. |
I will say this is also an annoyance for us too. I was hoping it may be a very much desired feature so it could have been prioritised more. But, not sure where it stands at the moment. |
Hi comrades, I'm tired of waiting for Microsoft. I made it possible to intercept the action Software backbutton (android, iOS) |
Amazing library @scriptBoris!!! Thank you. |
Description
Software back button doesn't use the same code paths as the hardware back button. This leads to unexpected behaviour on Android (and from what I've read, iOS).
Steps to Reproduce
Expected Behavior
The "OnBackButtonPressed()" method should be invoked, same as when the hardware "back" button is pressed.
Actual Behavior
The method is not invoked.
Basic Information
Reproduction Link
Will provide if asked.
The text was updated successfully, but these errors were encountered: