XPlat, IStart vs IElmishViewModel and resolving fields

[houstonhaynes]

Hey Jordan I'm wondering about a few things as I'm trying to migrate some of my work in the Example app over to an XPlat instance. I'm curious about some of the differences in stucture - like using "IStart" instead of IElmishViewModel - and whether that has something to do with a wrinkle in XPlat...

I'm also trying to get the project to build and right now I'm seeing hard errors in AXAML files in the XPlat project that are just warnings in the original example project. See the attached screen shot. (left is my XPlat and right is the example app I PR'd back to your repo) I always kinda 🤔 scratched my chin about why those warnings are there, and trusted that they're not an issue since that's a key to making things work in the Elmish binding model.

But now that it's a hard stop in this project I'm curious if this is a Jetbrains/IDE level setting or if there's something in Avalonia that needs to be set in order to get past it. Any thoughts? Thanks!

[houstonhaynes]

Disregard - I found it - switched

<AvaloniaUseCompiledBindingsByDefault>true</AvaloniaUseCompiledBindingsByDefault>

to 'false' and the mappings switched from errors to warnings. 👍

https://docs.avaloniaui.net/docs/next/basics/data/data-binding/compiled-bindings#type-casting

[JordanMarr]

Oh good!
There was an issue posted the other day with the suggestion to use compiled bindings for better compile-time checks.

[houstonhaynes]

I was wondering if there's a way to make that "map" so that the warning/error drops - deeper water than I'm willing to venture. 😨

[houstonhaynes]

Hey can I bother you to eyeball this project (SunFlwrXPlat) to see what I might have missed in trying to get it to work? I'm essentially just trying to get Elmish.Avalonia's sample app in XPlat format to then deploy to Android and iOS - for kicks. Right now I'm only seeing the UI render with "dead" menu links and no nav reaction to the menu bar. Can you weigh in?

It looks like the bindings are dead - something I left out? Something I did that I shouldn't have done?

https://github.com/speakez-llc/SunFlwr

[houstonhaynes]

It seems to be centered on the "MainView" and "MainWindow" - and on desktop (which uses MainWindow to call the MainViewModel) always displays as blank.

The fact that the menu in the MainView preview is "grayed out" is either a problem with the binding or a theme mismap - or both - or neither? 😕 😁

[JordanMarr]

At some point I renamed IStart in the template to IElmishViewModel. I just thought it made a little more sense.
Perhaps that should exist in the Elmish.Avalonia along with the FileLocator. I dunno.

I took a glance at your project. The only thing that seems weird is that I don't see a Program.fs anywhere. That has some configuration in it that is necessary.

[houstonhaynes]

Thanks. Fresh eyes help. Interesting theres no "hard stop" for it on compile if its missing. Along those lines I saw a base of some sort hiding in the folder but not included in the project. Curious if that's just a vestigial piece or is it necessary

[houstonhaynes]

The more I look at this the more confused I get. I just looked at your AvaloniaXPlatExample.fsproj for a package ordering difference, and spotted that there's not Program.fs for the project to "see"

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net7.0</TargetFramework>
  </PropertyGroup>
  <ItemGroup>    
    <AvaloniaResource Include="Assets\**" />
  </ItemGroup>
  <ItemGroup>
    <Compile Include="ViewModels\IElmishViewModel.fs" />        
    <Compile Include="ViewModels\CounterViewModel.fs" />        
    <Compile Include="ViewModels\MainViewModel.fs" />        
    <Compile Include="Views\CounterView.fs" />
    <Compile Include="Views\MainWindow.axaml.fs" />
    <Compile Include="Views\MainView.axaml.fs" />
    <Compile Include="App.axaml.fs" />
    <Compile Include="ViewLocator.fs" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="Avalonia" Version="$(AvaloniaVersion)" />    
    <PackageReference Include="Avalonia.Themes.Fluent" Version="$(AvaloniaVersion)" />
    <PackageReference Include="Avalonia.Controls.DataGrid" Version="$(AvaloniaVersion)" />
    <PackageReference Include="Avalonia.ReactiveUI" Version="$(AvaloniaVersion)" />

    <!--Condition below is needed to remove Avalonia.Diagnostics package from build output in Release configuration.-->
    <PackageReference Condition="'$(Configuration)' == 'Debug'" Include="Avalonia.Diagnostics" Version="$(AvaloniaVersion)" />

    <PackageReference Include="Elmish.Avalonia" Version="$(AvaloniaElmishVersion)" />
  </ItemGroup>
</Project>

src/Samples/AvaloniaXPlatExample/AvaloniaXPlatExample/AvaloniaXPlatExample.fsproj

[houstonhaynes]

I just created a new Avalonia.XPlat from the JaggerJo template and it also doesn't have a Program.fs at the top level. (They're there in Browser and Desktop)

[JordanMarr]

I, so The xplat projects must have a different entry point. Which is probably fine, but then the stuff in that file needs to be initialized somewhere else. That’s where the ‘UseElmishBindings’ is registered which is necessary for your bindings to work.

[houstonhaynes]

I'm actually not sure where that leaves me.

When I look at "MainWindow.axaml" and see it use the same ViewModel (MainViewModel) as the MainView.axaml I kind of get it... desktop and browser starts with the window and the lifecycle for the mobile apps show they use the MainView. I get it. What I don't get is how does this compile and run with a blank screen on desktop?

This is what I get on Android - which crashes immediately - but at least I'm seeing the menu bar across the top.

[houstonhaynes]

Sorry these are so large - tried to resize inline but it didn't "take"...

Getting the same with iOS

[JordanMarr]

Each supported plastform has a different start point (it's the same for MAUI).

For example, desktop app still uses Program.fs, but Android has a main Activity.
You need to find the start-point for each platform and ensure that UseReactiveUI() is swapped out for UseElmishBindings().

For example, your Android binding is still using UseReactiveUI().

[houstonhaynes]

That explains why the ViewModelBase.fs is not in the project but still lurking in the folder structure.

[houstonhaynes]

So I did exactly as you suggest... great. Now it lights up and I have no idea why it's not "finding" it. It looks like it's using the Avalonia

However when I look at your example I don't see it anywhere.

src/Samples/AvaloniaXPlatExample/AvaloniaXPlatExample.Android/Activities.fs

namespace AvaloniaXPlatExample.Android
open Android.App
open Android.Content
open Android.Content.PM
open Android.OS
type Application = Android.App.Application

open Avalonia.Android
open AvaloniaXPlatExample

[<Activity(
    Label = "AvaloniaXPlatExample.Android",
    Theme = "@style/MyTheme.NoActionBar",
    Icon = "@drawable/icon",
    LaunchMode = LaunchMode.SingleTop,
    ConfigurationChanges = (ConfigChanges.Orientation ||| ConfigChanges.ScreenSize))>]
type MainActivity() =
    inherit AvaloniaMainActivity()


[<Activity(Theme = "@style/MyTheme.Splash", MainLauncher = true, NoHistory = true)>]
type SplashActivity() =
    inherit  AvaloniaSplashActivity<App>()

    override _.CustomizeAppBuilder(builder) =
        base.CustomizeAppBuilder(builder);

    override x.OnResume() =
        base.OnResume()
        x.StartActivity(new Intent(Application.Context, typeof<MainActivity>))

So I'm still very confused about the prescriptive path forward. I'm reading a lot about what I'm doing wrong, which is helpful as I'm "feeling my way through the dark" but I'm still not sure what is supposed to happen in terms of actual direction. I'm trying to resolve the "template" that you provided with the JaggerJo template to try to get something - anything to work other than "Welcome to Avalonia!" in static text on the MainView.

[houstonhaynes]

Honestly - I find it surprising that I'm encountering this much friction in moving what I did in the non-XPlat app to this one. But at the end of the day I'm going to be writing up a handful of blog posts about what I've learned along the way, so in the end I expect it to be a net positive for those that come after. Thanks for sticking with me on this.

[JordanMarr]

• UseElmishBindings() is an extension method that is included in the Elmish.Avalonia package. So you will need to open that namespace for it to work.
• FuncUI doesn't use MVVM and therefore has no need for a binding mechanism like UseReactiveUI(). A better base reference is the official Avalonia UI xplat template which does include this.
  • Ideally, you would start a new project via the official Avalonia F# template, then add the Elmish.Avalonia project and swap out the binding machanism UseReactiveUI with UseElmishBindings, (and optionally add the ViewLocator).
• I haven't messed with xplat at all. The xplat example in this repository was contributed by @daz10000 , and I would imagine that he may have only exercised some or one of the target platforms, which explains why the Android project still references the original UseReactiveUI method instead of the UseElmishBindings method.

[houstonhaynes]

So far the Android app opens completely blank - which at least is consistent with Desktop. Updated iOS and it's at least partially working. Only Counter and About are working, but it's a start!

[JordanMarr]

Nice! The binding appears to be working.

[houstonhaynes]

And I just ran the Android app to my Note 10+ (the local emulator was failing - probably need a restart of that process). Two steps in the right direction - though I'm mystified as to why Counter defaults into place and "About" is present but the other two menu entries are not there...

[houstonhaynes]

OK - Fixed "UseElmishBindings" in Desktop and I'm getting the view WITHOUT the menu. So I suppose the menu bar has to be put in MainWindow to display in that app "Lifetime" as a spanning element across views?

[houstonhaynes]

This is SUPER encouraging... the previewer is in good shape.

I just want to get it to behave when it's running live.

[JordanMarr]

OK - Fixed "UseElmishBindings" in Desktop and I'm getting the view WITHOUT the menu. So I suppose the menu bar has to be put in MainWindow to display in that app "Lifetime" as a spanning element across views?

Here is a link to the closed issue from @daz10000 where he was wrestling with similar issues:
#2 (comment)

It may be helpful.

[JordanMarr]

It's weird that you have a MainWindow.axaml and a MainView.axaml that are almost identical.
You reference one for desktopLifetime and the other for singleViewLifetime. Maybe that is part of the confusion?

[houstonhaynes]

In reading their thread that's actually how they "solved" it. One lifetime needs a window and another a control. Weird. I played around with some normative (WPF/Xamarin/MAUI) conventions for putting a Styles.axaml in with the styles listed as a dictionary - so that both the MainWindow and View would reference one location. But I ran out of ideas so I'm living with the non-DRY version for now. :)

Update - I did a full cold reboot of my iMac and the Android (real) and iOS (simulated) both behaved exactly the same as the desktop. I removed the view 'hard size" values I had in the other app and things more-or-less worked as expected when flipping from portrait to landscape view. There was a wrinkle with the LiveChart not re-drawing when switching back to portrait - unless you toggle away from the view and return to it. I imagine that's a wrinkle in the Chart controller itself, which I'll noodle around with later.

Once the other XPlat PR is in I'll do the honors with the example XPlat project so there's more meat "on the bone" there.

[JordanMarr]

That makes sense. It might be helpful to rename those two views so it's more obvious how they are being used.

[JordanMarr]

Re: odd chart behavior:

You should be tracking the isAutoUpdating state in the Model rather than having loose, static, mutable state.
All state changes should be in Model and should be managed via dispatching messages.
Otherwise, your static isAutoUpdating field ignores init and instead maintains whatever its last state was.

[houstonhaynes]

I'll need to unpack that a bit but I think I'm about to turn the corner on grokking it.

[daz10000]

playing catch-up here I’m just reading the whole thread, but you ran into the main problem encountered getting the cross platform solution. At the highest level, web, mobile can only do a single window, so you end up with a top level control. The desktop has the flexibility to open many windows, and so it’s initialized differently. I never tested mobile, but in theory the web case should exercise all of the same problems as mobile (or at least a subset of them). If there are changes you want to make sure that example, please send them over. I didn’t have the ability to test android and iOS.DarrenAm 7/27/23 um 1:35 PM schrieb Jordan Marr ***@***.***>: Re: odd chart behavior: You should be tracking the isAutoUpdating state in the Model rather than having loose, static, mutable state. All state changes should be in Model and should be managed via dispatching messages. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[JordanMarr]

That makes sense.
Considering that this app doesn’t utilize any extra windows, it should be able to use a single main view for both.

[houstonhaynes]

I honestly don't mind it so much. Other than that first view everything else is 1:1. Your point about multiple windows is interesting - like the Catalyst apps in MacOS running things like a tablet format - very "flat". I wonder if it's possible to point the "lifetime" for desktop to the MainView - I got from the docs that it (desktop lifetime) needs to start from a Window - not a Control. So there's that possible wrinkle. Begs the question whether mobile can start with a "Window" Control - which would make them more harmonious.

All of that could be half-baked - as by the time I was scrounging around to "figure it out" it was already late hours of the evening. 😪 🛌 😉

[daz10000]

you are going through the exact evolution I did. The dual head (window and user control) is a bit annoying, but ultimately you get used to it and you realize that these platforms are fundamentally single views of a multi window paradigm doesn’t make sense. I think the next layer of problems last thinking is how you switch between views, and Jordan help me work through all of the wiring to switch. You have to think about the user experience a little bit. You can’t click on an item in a list and just throw off a new window (I guess a tab in the browser world is the equivalent of opening a fresh window but that’s also a little bit hard to do with the overhead of starting up a new wasm session).  Am 7/29/23 um 8:55 AM schrieb Houston Haynes ***@***.***>: I honestly don't mind it so much. Other than that first view everything else is 1:1. Your point about multiple windows is interesting - like the Catalyst apps in MacOS running things like a tablet format - very "flat". I wonder if it's possible to point the "lifetime" for desktop to the MainView - I got from the docs that it needs a Window - not a Control. So there's that possible wrinkle. Begs the question whether mobile can start with a "Window" Control - which would make them more harmonious. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[houstonhaynes]

Thanks for that - I'm still very much feeling my way through this. I'm taking a few days in the woods (national forest here in western NC) to set up for a week-long camp during the peak of the Perseid meteor showers in the second week of August. We'll be driving/bicycling from camp into an area that has decent 5G coverage where I'll do some experimentation and reading on/offline to get a better grip on Elmish - instead of just banging away and scratching my head.

I opened a separate thread to keep track of how to set up a shared style "dictionary" between the MainView and MainWindow. I thought I had followed "the letter of the law" as laid down in the Avalonia documentation, but it didn't seem to work for me. So I'll be looking into that and also looking back into Elmish a bit more deeply. @JordanMarr 's comments about cleaning up the messaging around routing isAutoUpdating through the model has made me want to step back and "hit the books" a bit more.

(such as why would I want to do that when it's all within the ViewModel anyway? and related 🧠 teasers)

[houstonhaynes]

FYI #17

[houstonhaynes]

For posterity (mainly my future self) here's an interesting excerpt while glancing at Fabulous.Avalonia... it seems they do the same thing - wrapping the viewmodel with a "Window" when in desktop lifetime.

https://github.com/fabulous-dev/Fabulous.Avalonia

/// A simple Counter app

type Model =
    { Count: int }

type Msg =
    | Increment
    | Decrement

let init () =
    { Count = 0 }

let update msg model =
    match msg with
    | Increment -> { model with Count = model.Count + 1 }
    | Decrement -> { model with Count = model.Count - 1 }

let view model =
    VStack(spacing = 16.) {
        Image(ImageSource.fromString "fabulous.png", Aspect.AspectFit)

        TextBlock($"Count is {model.Count}")

        Button("Increment", Increment)
        Button("Decrement", Decrement)
    }
    
#if MOBILE
    let app model = SingleViewApplication(view model)
#else
    let app model = DesktopApplication(Window(view model))
#endif