Xamarin.AndroidX.Navigation.Ui 2.5.2 and higher breaks fragment animations

[gmck]

Android application type

Classic Xamarin.Android (MonoAndroid12.0, etc.)

Affected platform version

VS 2022 17.5.0 Prev 1

Description

After upgrading both Xamarin.AndroidX.Navigation.Fragment and Xamarin.AndroidX.Navigation.Ui from 2.5.1 to any higher version in my latest test app NavigationGraph7 the fragment animations are broken.

Since beginning with Android’s NavigationComponent, via their code lab, I was never impressed about handling Fragment animations via a NavGraph as it seemed to be a really messing, repetitive task if you ever wanted to test a different animation, so I came up with an animation resource class where you could add different animations which allowed you to quickly change the type of animations you wanted to try by using the NavOptions Builder of Xamarin.AndroidX.Navigation.Ui which has methods SetEnterAnim, SetExitAnim, SetPopEnterAnim, SetPopExitAnim. Therefore with a bit of logic before creating the builder you can pass the appropriate e.g. AnimationResource.Fader2() or AnimationResource.Slider() etc and finally call navController.Navigate(menuItem.ItemId, null, navOptions). The downside is that you can’t use their automatic navigation and you have to write methods like OnNavigationItemSelected and BottomNavigationView_ItemSelected etc. And of course, to go the other way every fragment requires OnBackPressedCallback which does the opposite in its HandleBackPressed method. I would argue that the above approach is easier to maintain than having to add all this stuff and extra actions, bundles etc in a navGraph. Also, it looks like the OnBackPressedCallback is going to become mandatory anyway.

When I first realised that the animations weren’t working, I immediately thought of Material 3 as the culprit as this was the first test app I’d written using Material 3. I’d spent a lot of time trying to get the colours working with the existing themes and then dynamic colours and after getting all that going I realised the animations weren’t working as previously. I went back to the NavigationGraph6 project, the previous test app (Material 2) and noticed that it wasn’t using the latest version of Fragment and Navigation.Ui so I upgraded both and that broke the animations in NavigationGraph6 too. So I think it is safe to conclude that Navigation.Ui is what is causing the problem. To confirm I downgraded Navigation.Fragment and Navigation.Ui in the NavigationGraph7 app and the animations are back to normal.

I’ve checked at https://developer.android.com/jetpack/androidx/releases/navigation and can’t see any information that could indicate that something relating to animations has changed between 2.5.1 and 2.5.2

The xml files in the Resources\anim folder are exactly the same in both projects. I added some Log.Debug to both the BottomNavigationView_ItemSelected and the NavFragmentOnBackPressedCallback as in the following – “Navigate back” in the callback.

Log.Debug(logTag, "Navigate to - Enter Animation " + navOptions.EnterAnim.ToString());
Log.Debug(logTag, "Navigate to - Exit Animation " + navOptions.ExitAnim.ToString());
Log.Debug(logTag, "Navigate to - Pop Enter Animation " + navOptions.PopEnterAnim.ToString());
Log.Debug(logTag, "Navigate to - Pop Exit Animation " + navOptions.PopExitAnim.ToString());

This results in the following

NavigationGraph7

Xamarin.AndroidX.Navigation.Ui 2.5.3

Navigate to - Enter Animation 2130772009
Navigate to - Exit Animation 2130772010
Navigate to - Pop Enter Animation 2130772008
Navigate to - Pop Exit Animation 2130772011

Navigate back - Enter Animation 2130772009
Navigate back - Exit Animation 2130772010
Navigate back - Pop Enter Animation 2130772008
Navigate back - Pop Exit Animation 2130772011

NavigationGraph6

Xamarin.AndroidX.Navigation.Ui 2.5.1

Navigate to - Enter Animation 2130772005
Navigate to - Exit Animation 2130772006
Navigate to - Pop Enter Animation 2130772004
Navigate to - Pop Exit Animation 2130772007

Navigate back - Enter Animation 2130772005
Navigate back - Exit Animation 2130772006
Navigate back - Pop Enter Animation 2130772004
Navigate back - Pop Exit Animation 2130772007

I don’t understand exactly how aapt2 works, so I’m not sure about the significance of the different values. I’d appreciate learning if the above results are significant. Or if there is anything that you guys could suggest that I can investigate further.

@jpobst
I understand you will probably move this to AndroidX, however, I like to point out, that then it is likely not to be commented on as it is obvious that moljac is just so busy maintaining all the AndroidX stuff that he doesn’t have time to get involved in discussions. For instance, on Sept 6th I raised the issue about menu deprecations in Xamarin.AndroidX.Navigation.Fragment 2.5.1 #611. Other than your comment about moving it there, there have been no further posts, even though there have been a couple more releases since then.

Basically, support for Xamarin.Android is now non-existent. https://learn.microsoft.com/en-us/answers/topics/164819/dotnet-xamarin.html is so out of date that it doesn’t matter. They appear to be in a time warp of about 2019 and Android 10 or 11 is the latest version. I don’t think it is necessary to further comment on Send Feedback/Report a Problem in VS after my rant about the Xamarin.Android Designer and now I notice they just transfer Xamarin.Android issues here. So that leaves StackOverflow which is more or less in the same time warp as the MS site.

I can also see from my daily visits on Discord that you guys are also super busy and I understand your reluctance to answer questions.

Therefore who should I/we complain to? Who should I email at Microsoft to suggest that Microsoft desperately needs to improve its technical support for Xamarin.Android. I get peppered with emails and notifications all day every day about Maui which I have absolutely zero interest in because my apps are never going to be published on anything other than Android. It seems ironic that my app is based on an old windows app which is how I came to Xamarin.Android years ago, but there is no demand anymore to run it on a laptop – phones and tablets are all my users are interested in now.

Since AndroidX is the ever-changing part of Android couldn’t moljac be given more assistance – more bodies for instance to help him with testing and finding bugs? I’m sure you could even find volunteers if MS won’t stump up for more staff.

The test app is at the following link https://github.com/gmck/NavigationGraph7

Steps to Reproduce

See sample app

Did you find any workaround?

Revert back to 2.5.1

Relevant log output

No response

[jpobst]

The value proposition with the Xamarin.Android product (and AndroidX/GPS bindings) is we provide users raw, direct access to the Google Android API from C# so they can be used exactly like they are used from Java. The downside of this is that these are Google's APIs and not ours, so we do not know how they function and cannot provide support for them. (We maintain bindings for the massive Android API as well as 500+ bindings for AndroidX/GPS/Firebase/MLKit libraries.) They will have the same quirks and bugs that Java users will have trying to consume them.

Obviously, this is an unsatisfying answer for many users who expect better support from Microsoft. For this, we offer Xamarin Forms or MAUI. These products offer users APIs (and designers) that are written by Microsoft that cover up the rough edges of Android/iOS and are supported by Microsoft. When these APIs do not function correctly, it is Microsoft code and we can fix the issues.

As an analogy, Xamarin.Android is like buying computer parts and MAUI is like buying a computer. There are some people who want a fully assembled computer backed by Dell or Apple, and there are some people who want to put the pieces together themselves.

Therefore who should I/we complain to?

My suggestion would be to fill out any surveys that are offered on Twitter or through the IDE. These are the feedback signals with the best chance of making it back to business decision makers.

[jonpryor]

@gmck wrote:

Basically, support for Xamarin.Android is now non-existent. https://learn.microsoft.com/en-us/answers/topics/164819/dotnet-xamarin.html is so out of date that it doesn’t matter. They appear to be in a time warp of about 2019 and Android 10 or 11 is the latest version.

I'm not sure that I am seeing what you are seeing. I do not understand this comment. The dotnet-xamarin.html topic has 4731 topics, some asked "1 hour ago" for me. What do you mean by "out of date"? If I search for "Android 13", the very first match is Documentation for Xamarin Android SDK 13 (which should now exist as of bd1d93c and xamarin/android-api-docs@d7bb60c).

Additionally, .NET Android is the supported replacement for Xamarin.Android, and is mostly API compatible with Xamarin.Android. (I don't have a count of the API breakage offhand, but I can't think of anything outside of System.AppDomain use and Xamarin.Android.Net.AndroidClientHandler.)

Regarding your issues with navigation and animations, @jpobst's comment is correct: .NET Android and Xamarin.Android only bind the Java APIs, with a handful of "sugar" to make things more ".NET-like" (property generation, event handlers for the Listener pattern, etc.). A difficult Java API will remain difficult to use from C#.

If you have "equivalent" Java and C# code which behave differently, that is a problem we are interested in and will explore.

If you instead have a bit of C# code that doesn't behave the way you expect, well, we are not experts in using the Java APIs, just experts in the binding and runtime aspects. We are only able to assist if that C# code is ported to Java, and the behavior between the Java code and the C# code differs.

dotnet/android-libraries#611, meanwhile, is a binding issue: Java interface default methods are not currently exposed in our AndroidX bindings, as enabling them would cause API breaks. This is something we will need to address.

[jpobst]

dotnet/android-libraries#611 has been resolved, so I think this issue is complete.