Android Activities and Navigation?

[JohnSL]

Does Avalonia's on Android include full support for activities and navigation? I wasn't able to find any documentation on how you would set this up. Here are some of the questions I had:

• How do I create a new activity and have that activity connected to a new Avalonia view? I have no previous Android experience to fall back onto
• How would the Avalonia main view start the new activity?

[emmauss]

We currently do not have a control type that represents an Activity, like what with have for desktop platforms with Window. You can instead host an AvaloniaView, which is a native android view, in an Activity and set its Content to an Avalonia Control.

[JohnSL]

Sure, I understand that part as I have it working already with the MainActivity. If I understand correctly, then, the answer is that there is no support for Android-native navigation based on activities. In other words, there is no way to enable the back button in the bottom navigation bar to move within your application. That's where I was going with navigation support.

And therefore, I need to build my own navigation with my own buttons for going back. Correct? Are there plans to support Android features like navigation and screen orientation changes?

[mysteryx93]

I'm starting to look into implementing navigation in HanumanInstitute.MvvmDialogs for mobile (this is overdue; I've been busy to say the least)

Is the Activity design something for me to look into, or I handle my own internal stack, cache and navigation?

What are the Activity classes for?

[maxkatz6]

"Activity" is not an Avalonia type, but native Android type to define a top level page/window.
Avalonia view is hosted inside of the android activity. It is technically possible to create navigation using activities, if developer needs some specific integration with Android. It's not a cross-platform way to do so, obviously.

https://developer.android.com/reference/android/app/Activity

[mysteryx93]

Would there be benefits to basing it on Activity?

One downside might be that MvvmDialogs would have hard dependency on Android even for other platforms? Does the simple fact of referencing Activity requires Android dependencies?

I suppose it should be possible to handle the "Back" button via API and mask it as handled?

[Mrxx99]

One downside might be that MvvmDialogs would have hard dependency on Android even for other platforms? Does the simple fact of referencing Activity requires Android dependencies?

That could be handled with multitartgeting

[AArnott]

As I understand it, Avalonia's support for Android apps is to model them as a Single Page Application (SPA). That is, there will only ever be one activity, and any Back button behavior will have to be emulated within your application.

If I understand correctly, then, the answer is that there is no support for Android-native navigation based on activities. In other words, there is no way to enable the back button in the bottom navigation bar to move within your application.

I found a way to do this. The tricky part is that the Android back button is not plumbed through Avalonia at all, nor is the Android view or view model plumbed through to the Activity. I had to rely on a static field (which already existed, FWIW) so that the Activity could communicate with my view model in order to emulate the expected Back button behavior. Here is how I did it:

1. Define a root view model that will be the basis for your SPA. It basically has one property (ViewModelBase CurrentPage) which holds whatever view model represents the page you want to display to your user.
2. In that same root view model (which I'll call MainViewModel), define a NavigateBackCommand whose execution will cause your MainViewModel to pop a view model off its stack, thus updating CurrentPage, which always points to the top of that stack.
3. Modify the App.axaml.cs file:
   1. Add a property that exposes your root view model (the one with CurrentPage on it) to your App class.
   2. In the override OnFrameworkInitializationCompleted method where you create that root view model, store the view model in the App class property
4. In the Android project's MainActivity.cs file, add this method:

public override void OnBackPressed()
{
	if (App.Current?.MainViewModel is { } mainViewModel && mainViewModel.NavigateBackCommand.CanExecute(null))
	{
		mainViewModel.NavigateBackCommand.Execute(null);
	}
	else
	{
		// This will terminate the app.
		base.OnBackPressed();
	}
}

My App.axaml.cs file uses a MainView as its root UserControl for ISingleViewApplicationLifetime applications (e.g. Android), and a MainWindow Window-derived class for IClassicDesktopStyleApplicationLifetime applications (e.g. desktop). The MainWindow I define is just a wrapper around MainView.

To provide an equivalent experience in desktop applications, which have no OS-provided Back button, my MainWindow adds a Back button in addition to the MainView user control that takes up most of the window.

[maxkatz6]

Loaded event pretty much guarantee that control has a top level. Also, it can be detached and attached to another top level (more likely to happen with windows on desktop, but still). That's why it also makes sense to listen for Unloaded.

[AArnott]

Great feedback. That leaves me with:

protected override void OnLoaded()
{
	base.OnLoaded();
	if (TopLevel.GetTopLevel(this) is { } topLevel)
	{
		topLevel.BackRequested += this.MainView_BackRequested;
	}
}

protected override void OnUnloaded()
{
	if (TopLevel.GetTopLevel(this) is { } topLevel)
	{
		topLevel.BackRequested -= this.MainView_BackRequested;
	}

	base.OnUnloaded();
}

private void MainView_BackRequested(object? sender, Avalonia.Interactivity.RoutedEventArgs e)
{
	if (this.ViewModel is { } mainViewModel && mainViewModel.NavigateBackCommand.CanExecute(null))
	{
		mainViewModel.NavigateBackCommand.Execute(null);
		e.Handled = true;
	}
}

And as you predicted, that actually makes the GetTopLevel call return a non-null value on desktop too. 🥂

[mysteryx93]

I'm implementing back navigation for MvvmDialogs. I'm noting a bug on Android. When switching back to the app, the first "Back" doesn't trigger BackRequested; it only raises the event on the second click. Should I open a ticket for this?

[emmauss]

If you can make a small repro for it, open a issue and I'll take a look.

[mysteryx93]

created a report and repo here
#10342

[mysteryx93]

To handle navigation, there's the option of using MvvmDialogs which now supports navigation for mobile. I just released preview2 with mobile support, although doc isn't updated yet.

BackRequested is now supported by Avalonia? That will make things much simpler for MvvmDialogs! I'll be able to add that quickly then.

[Grave18]

There is still nothing about this in the documentation. After thinking about it, I came to this approach:

// Android.MainActivity.cs
public override void OnBackPressed()
    {
        var navigatorService = App.GetService<INavigatorService>();
        
        if (navigatorService == null)
        {
            return;
        }

        if (navigatorService.IsHome())
        {
            // if In Home Page - exit Application
            OnBackPressedDispatcher.OnBackPressed();
        }
        else
        {
            navigatorService.OpenPrevious();
        }
    }

Here I use Microsof Dependency Injection and my custom View Navigator service. This approach is push code from MainView.cs to Android MainActivity.cs