Blazor Mobile Bindings Migrations

[arivera12]

Hi,

I opened this issue since you say that you may be interested on migrating to blazor mobile bindings.

What I have found while playing around and notice on Blazor Mobile Bindings vs BlazorMobile

This is the base project stucture

The project Blazor Mobile Bindings already supports and not support by default

• Android
• Windows
• Windows Phone
• MacOs
• iOS
• Linux
• Blazor WASM
• Blazor Server

As far I can see they have a project which hold the blazor files and uses the same structure but its a library project instead a of a web app which is referenced by all projects already.

FirstBlazorHybridApp -> Holds the blazor files and it's the base library project.

We can still reuse most of what you have done on this library and give support to Linux under electron and setup Blazor WASM and Server under the hood.

Another important thing I found is that iOS emulator runs fine while BlazorMobile never didn't work because of the lack of WASM over the iOS emulator.

I think they are using the native razor engine instead of WASM to render the blazor files and seems to perform more faster than WASM.

In general term we should use BlazorMobileBindings as the base structure and extends with the rest of the things that aren't supported by default.

[arivera12]

Taking a deeper look not sure if this deprecates most of the already built-in features in this library but may be still useful if it's adds support to the 3 projects I mentioned above which aren't not supported yet.

[Daddoon]

I will take a look in few days (beginning October) when back on my business project.

The "magic" bits would be to ensure that we found (or invent) a project model template that can be both be linked easily between a pure Hybrid Native (Mobile Blazor Bindings) and an external Blazor Server or WASM Web project.

For the Linux support i'm pretty sure it's only the same limitation of Xamarin: Linux is not officially supported by Microsoft, but there is maybe some open source things for that, but no clue about the Web Browser implementation, i know that it was more about GTK and other native things support...Yes if there is no alternative, there is still Electron for Linux.

What do you mean by "Windows Phone" support ? UWP / Windows 10 ?
Pretty sure that UWP is supported even if not listed officially on Xamarin support...Or if it's not possible, maybe it would be because of the lack of .NET Standard 2.1 on UWP (or maybe this changed i didn't checked recently). BlazorMobile was workarounding this problem as the .NET Standard 2.1 implementation was hidden in the Web build, so WASM was responsible to manage it, and not UWP directly.

The updates of BlazorMobile will depends of what is needed and doable on Mobile Blazor Bindings. If there is some additions, it's cool, otherwise better to migrate completly to one to another plugin. Don't know yet, i have to see this very soon !

[arivera12]

I tried all projects and they all worked for me.

I haven't test a windows phone natively not sure if System.Windows.Form stuff is compatible with windows phone environment but it should work, at least xamarin works as is on UWP.

As far I can see migrating to Blazor Mobile Bindings will not be a big issue.

In general terms we may need to package only to linux/electron project.

Add references to the blazor server and wasm project from the base project library.

Everything else should be baked by default.

This is the way I see it.

[arivera12]

It's seem blazor mobile bindings is on the way on implementing blazor wasm and server projects and it's on the way. Take a look of this dotnet/MobileBlazorBindings#129. Not sure if these deprecates this project 😢

[Daddoon]

Mainly yes you are right.

The only functionnality that would be missing on Mobile Blazor Bindings is the possibility to load external Blazor package (like a downloaded updated app). The only reason: BlazorMobile load app as WASM, so its not tied to a native compilation, so the app package can be switched easily.

Mobile Blazor Bindings on the other end is very powerfull (the engine is native) but as it's compiled as native code, you cannot switch the app to another app. I mean, you can do it by some reflection and trickery, i imagine in the worst case, BUT on platforms like iOS that doesn't allow dynamic assembly load (like No JIT and only AOT), there is no luck !

This mean Mobile Blazor Bindings will never allow update on the fly easily, at least for all the compiled stuff. A full Mobile app new release will be needed to update an app.

[arivera12]

The only functionnality that would be missing on Mobile Blazor Bindings is the possibility to load external Blazor package (like a downloaded updated app).

I think this kindly possible with this https://docs.microsoft.com/en-us/aspnet/core/blazor/fundamentals/routing?view=aspnetcore-3.1#route-to-components-from-multiple-assemblies

[Daddoon]

Yes, but i'm talking about the mobile support.

Also this is not the exact same functionnality. In your link, this would reference an other Assembly, on web i imagine that it would be an Assembly that is in the web project, and on Mobile same but something that is linked with the compiler at build time with AOT.

Your documentation link is not about "replace the entire app" by an other one available.

And as said, Apple / iOS restrict any dynamic assembly load: Things must be embedded/linked in your app (AOT model so). It will probably crash on iOS or it will be rejected by Apple anyway.

[Daddoon]

On BlazorMobile it's working without issue because it's a trickery: The C# code, even if it's "assemblies" is executed in the Web browser, wich is a Sandbox for the OS. So it's considered like if you were loading any external/additional Javascript code to your page: The loaded code does not have direct API access to native: It's sandboxed so it's safe by nature as there is no easy way to c hijack the native side of your app by default.

[arivera12]

I see and understand now!

[Daddoon]

You may be right, we may do some "usefull" things that are more an addition to the existing Mobile Blazor Bindings state that a completely different thing.

I may be wrong but the only things missing today on Mobile Blazor Bindings would be:

• UWP support
• Electron support
• Linux support (but so covered by Electron) , due to some GTK issues in Xamarin atm if my memory is correct.

We can assume that on unsupported platforms, depending their own limitations, we can switch to a simple Blazor Server project or in the worst cast, Blazor WASM project , of course WebAssembly would be needed (also it's the reason i used Gecko engine in this project for Android, it was for workarounding limitations on old devices, and making the browser experience consistent between devices, at least with WASM !).

What would be missing and so be keeped by BlazorMobile on thins kind of scenario, would be the interop layer to communicate, with a embedded HTTP Server.

As stated in an other issue on this repo, some other javascript mecanism can be used for communication on devices, but if i took this path on this project, to use a webserver to do the communication layer, it's mainly because not all WebView implementations on each platform would allow to do direct javascript communication with the device. In fact GeckoView engine does not allow this kind of usage.

To be short, i think that if we maintain momentally this project, the main things to do would be:

• To update projects hierarchy and contents
• Migrate everything on a Mobile Blazor Bindings logics
• Keep and add every extra projects and data, services, DI that are needed to be able to use the exact same projects on both supported platform on Mobile Blazor Bindings and unsupported one that are supported on BlazorMobile.

Somehow, i would see at the moment BlazorMobile as a consolidation layer on some grey part of Mobile Blazor Bindings in order to gain development time, until Microsoft has consolidated everything to "rule them all" !

@jspuij If it don't bother you, do you have any opinion on theses statements ?

[jspuij]

GeckoView supports writing WebExtensions to interact with JavaScript. Also injecting JavaScript can be done by using "javascript:" inside loadUrl. So writing a WebExtension to be the bridge is possible.

UWP works more or less as long as you limit yourself to netstandard 2.0 Blazor assemblies. MBB still is netstandard 2.0. It works on CoreRT, but it cannot load every Blazor library out there. As long as the UWP runtime isn't updated, this will still be an issue. I have a feeling though that .NET 6 will be able to use all features of the windows runtime and that .net 6 will be supported on UWP platforms (e.g. the XBOX). That way CoreRT (the runtime for C# on WinRT) will be retired.

I can see how migrating to MBB for platforms that are supported is attractive v.s. retaining BlazorMobile platforms for unsupported platforms is as well. Please keep in mind though that as long as MBB is a preview, its development could be stopped at any time. It's used to test whether the strategy is viable and whether there is community interest. So adopting it could tip the balance towards a full product in the future ;-)

[Daddoon]

I understand your disappointment but actually, running a Blazor app in Native mode (meaning like the Xamarin.Forms components) or as a regular Blazor Web app with Mobile Blazor Bindings, in theses two cases you should have some kinds of Native performance.

I mean, the engine used on MBB is the IL code generated for your device VM. Yes it's not like we are executing a bare-metal code, but performances are pretty close to native, as it's a dedicated environment.

But it's true that you are so limited to available VM. Android should be able to do JIT and AOT, where iOS is AOT only, but you surely know that.

Ironically, the only way some "kind of" JIT would be available on iOS today it's from a WebAssembly code, as everything would be sandboxed and so transparent for the executing OS. But we have instead a slow IL interpreter at the moment.

However i agree that today we only have the choice, for a pure web app in Blazor, between good performances with the Server mode but kind of unreliable in case of disconnection and hard to implement for scalability (more thinking about costs in the end), or a very cool Blazor WASM packaging, but with the need to be carefull about what we do atm as there is no AOT compilation of the project, only IL to interpret, so potentially slow depending the device.

Too bad that this is taking so much time, as Blazor is very promising in term of programming experience.
But in the end, is something blocking you due to Native AOT missing ?

[jspuij]

iOS supports JIT from 14.2 on: https://9to5mac.com/2020/11/06/ios-14-2-brings-jit-compilation-support-which-enables-emulation-apps-at-full-performance/

It was to be expected since all the support for JIT on ARM was silently introduced into the M1 dev kit and the apple silicon is faster than intel now, even on your iphone. So AOT on iOS is not necessary anymore.

For now only for sideloaded apps, but I guess permission for frameworks like .net and java will follow shortly.

[Daddoon]

@jspuij What a news ! Thanks for the info ! Would not have guessed that some days Apple would change their mind about this , even if what you describe seems logic.

[Daddoon]

I think the last risk you mention can exist in any kind of app. Client is never secure. But it's true that it will be easier to decompile and read.

However i don't think that the current usage of mono-wam is what is intended by Microsoft / Mono. I may be wrong, but when mono-wasm will be AOT compatible, the Blazor will surely download a compiled WASM image instead of plenty plain .dll's.