[enhancement] What about extending BlazorMobile in another project with cross platform shared api for browser, mobile and Electron.net?

[arivera12]

Example of cross platform Alert api

/// <summary>
/// Cross platform Alert (Platforms: Browser, Xamarin & Electron.NET)
/// </summary>
/// <param name="message">The message of the alert (Platforms: Browser, Xamarin, Electron.NET).</param>
/// <param name="jsRuntime">The JsRuntime of the browser (Platforms: Browser).</param>
/// <param name="title">The title of the dialog (Platforms: Xamarin, Electron.NET)</param>
/// <param name="cancel">The title of the dialog (Platforms: Xamarin, Electron.NET)</param>
/// <returns></returns>
public async Task Alert(string message, IJSRuntime jsRuntime = null, string title = null, string cancel = null)
{
    if(BlazorDevice.RuntimePlatform == "Unknown")
    {
        throw new NotImplementedException("DisplayAlert is not supported on this platform");
    }
    else if (BlazorDevice.RuntimePlatform == "Browser" && jsRuntime.IsNull())
    {
        throw new NotImplementedException($"DisplayAlert jsRuntime need to be provided on this platform: {BlazorDevice.RuntimePlatform}");
    }
    else if(BlazorDevice.RuntimePlatform == "Browser" && jsRuntime.IsNotNull())
    {
        await jsRuntime.InvokeVoidAsync("alert", message);
    }
    else
    {
       await Application.Current.MainPage.DisplayAlert(title, message, cancel);
    }
}

I could be available to invest time on this, while you keep updating and maintaining the core of blazor mobile.

We could bring out those shared API already over blazor mobile framework and could be more attractive to developers in my opinion.

What you think about this?

Any thoughts?

[Daddoon]

Actually, the DisplayAlert API scenario while using Xamarin.Forms (at least) on Electron.NET does already work, as i have mocked a fake Xamarin.Forms driver for Electron.Net, and implemented some of theses bases method call like DisplayAlert, Dialog...

Otherwise from a Design point of view, it's in my opinion more safe to distinguish Web alerts (that will works in every case during your Web experience) and Native alerts, as it give more design / behaviors choice to the developer.

But nothing prevent you to do your own package for this, that will take a look at if there is any possibility to call a native side in your app...or not, and so using a JS implementation instead.

Concerning the BlazorMobile future, i'm less concerned about updating it for now as i have other priorities on my current projects, and as Microsoft is now implementing a Hybrid app compatibility with Mobile Blazor Bindings project. See the current latest news: https://devblogs.microsoft.com/aspnet/hybrid-blazor-apps-in-mobile-blazor-bindings-july-update/

Actually, according to their doc, their system does seem to use the same memory area for Native and Web ! As they don't use WASM in their version, i assume that they are using a kind of "Server-side" scenario on Mobile, even if this is using Mono instead of .NET Core under the hood. But i think this is the best choice, as you have more horse power, as this is Native C# instead.

An interesting thing would be maybe to do something about migrating current BlazorMobile projects to a Mobile Blazor Bindings project, without having to rewrite any custom different logic. It should be possible.

The only downside is that ElectronNET would be dropped indirectly (but you still have WPF and MacOS support according to their docs, and Linux should be at least feasible with the community work on Xamarin.Forms) , and UWP too maybe, as i don't see it written anywhere in the doc. Very strange, but maybe it's unofficialy possible.

[arivera12]

I would keep stick to your approach since we have single base code and easiness to port to other platforms. Html will be always the most portable language for cross platform development approach. Xamarin has gained ground on other platforms but not on all. It will take too much time for them to be executable on every platform. Take a deep note that every platform have web browsers and if we have web browsers then we can run blazor mobile always without any issues. Web will always be the first thing to arrive and be available on every platform. This is the main reason I loved this project since day 0. We reuse everything we have already know, what we already have on the web and we can keep focused on one platform at the time.

[arivera12]

As far as I could see at this moment you were right, making this doesn't makes any sense. It better to apply apis per platform rather that one that makes decisions internally. I got in sense of this once I saw that over blazor I do persistence using the browser storage but this doesn't work for blazor mobile I would rather need to write to the device storage directly. I am closing this.

[Daddoon]

Actually, writing to the localstorage in the browser is not a bad idea at all. I mean it would have been a logic like this if only working through a PWA app alone. I don't see neither the use of localstorage OR native storage a bad choice.

In our case this is only by Design, i don't know if it was a good idea, at first it was to avoid some caching issue, but in the end it is maybe a too agressive design.

However, going into your point, it's true that we can less rely on the localstorage of the browser while working on this kind of scenario, meaning working on a native app on the back:

• Concerning BlazorMobile, we are using "localhost" endpoint as a server. This is not like a PWA app, so how does the browser should behave ? We cannot rely on this address for multiple reasons.
• It's not a regular external Browser, as we are in a app, so we cannot be sure about all the behaviors.

As clean as it should be, if working on a Browser only AND working also as a mobile app (BlazorMobile), i would have written 1 interface with 2 possible implementation. One expected to be registered and used for a web app alone, and the other for a BlazorMobile (Native) app, that would interop to Native instead to write data.

This way, it would be transparent at usage time. For theses kind of scenario, you may even slice your Blazor project into a Razor Class Library project, and only reference the additionals implementations on the additionnals boot project (the one for Web, the one for BlazorMobile), but this is another topic !

[arivera12]

As clean as it should be, if working on a Browser only AND working also as a mobile app (BlazorMobile), i would have written 1 interface with 2 possible implementation. One expected to be registered and used for a web app alone, and the other for a BlazorMobile (Native) app, that would interop to Native instead to write data.

This is the approach I planned!