// See the note at the top of MainActivity for why the platform namespaces are reached through `global::`.
using Avalonia;
using Avalonia.Android;
using Avalonia.Media;
using DodoSSH.Client.Android.Platform;
using global::Android.App;
using global::Android.Runtime;

namespace DodoSSH.Client.Android;

/// <summary>
/// The Android <c>Application</c> object, and where Avalonia is configured.
/// </summary>
/// <remarks>
/// <para>
/// Avalonia 12 moved the <see cref="AppBuilder"/> hooks here from the activity, which is a better fit than
/// it first looks: an activity is destroyed and recreated, and the application object is not. The desktop
/// head's equivalent is <c>Program.BuildAvaloniaApp</c>.
/// </para>
/// <para>
/// Any Avalonia 11 sample will show this on <c>AvaloniaMainActivity&lt;App&gt;</c> instead. That type is
/// still here and is still what the launcher activity derives from — it simply no longer takes the
/// application as a type argument.
/// </para>
/// </remarks>
[Application(Label = "DodoSSH")]
public sealed class DodoSshAndroidApplication : AvaloniaAndroidApplication<DodoSshApp>
{
    /// <remarks>
    /// The JNI constructor, and the only one Android calls. It exists to hand the managed object its Java
    /// peer; there is nothing to do in it and nothing may be done in it, because the application context is
    /// not usable until <see cref="OnCreate"/>.
    /// </remarks>
    public DodoSshAndroidApplication(nint javaReference, JniHandleOwnership transfer)
        : base(javaReference, transfer)
    {
    }

    /// <inheritdoc />
    public override void OnCreate()
    {
        // Before Avalonia, and from the application rather than the activity: this is the context whose
        // lifetime matches the composition root's, and reading filesDir is the first thing startup does.
        PhoneEnvironment.Attach(this);

        base.OnCreate();
    }

    /// <inheritdoc />
    /// <remarks>
    /// This used to be the one place the two heads disagreed on purpose: the recorded v2 decision was
    /// "Android recolours with the shared palette and keeps its own default sans", on the reasoning that a
    /// phone's system font is a phone's own business. The user has reversed that, this pass — the phone now
    /// takes the desktop's face as well as its colours, and <c>docs/design-import-gaps.md</c> is corrected
    /// to say so rather than left asserting a decision that no longer holds.
    ///
    /// <c>WithInterFont</c> still registers Inter, for the same reason <c>Program.cs</c> keeps it on the
    /// desktop: it is what the layout suite pins and what a glyph Montserrat does not cover falls back to.
    /// What changes is which face answers first. Montserrat ships embedded in
    /// <c>DodoSSH.Client.Shell/Assets/Fonts</c> already — this project references that assembly for
    /// <c>Theme/Phone.axaml</c>'s own <c>MonoFont</c>, so no csproj or asset work was needed to reach it
    /// from here, only the same <see cref="FontManagerOptions"/> block the desktop's
    /// <c>Program.BuildAvaloniaApp</c> sets.
    /// </remarks>
    protected override AppBuilder CustomizeAppBuilder(AppBuilder builder) =>
        base.CustomizeAppBuilder(builder)
            .WithInterFont()
            .With(new FontManagerOptions
            {
                DefaultFamilyName = "avares://DodoSSH.Client.Shell/Assets/Fonts#Montserrat",
                FontFallbacks =
                [
                    new FontFallback { FontFamily = new FontFamily("avares://Avalonia.Fonts.Inter/Assets#Inter") },
                ],
            });
}