daddoon / blazormobile Goto Github PK

The current class library for Android is targetting MonoAndroid v8.1 as SDK requirement (not the API level, wich should work on API 19)

The library must be available for older SDK version instead of erroring when referenced from older SDK.

The documentation must be more clear and more straightforward

Add documentation about NetworkIsolation on UWP for remote debugging

Clear Webview cache at BlazorMobile start.

It seem that there is some inconsistency and crash on UWP sometime after some builds. It may be related to the fact that UWP cache web files, and in my opinion, is doing some things wrong when getting data from caches.

This may occur on other platform (maybe).

Here is the todo list:

• Calling clearing cache before WebView call if possible ?
• Clearing OK on UWP
• Clearing OK on Android
• Clearing OK on iOS

As we are using and executing web technologies from the device, we may be interested to return some extra or web contents from our mobile app, and showing them, working like a remote resource.

As using the AppStreamResolver method in our project, we may expose a wider way to add extra controllers to the local web server in order to do extra custom behaviors within the Blazor app.

We should allow to register custom controller types in EmbedIO (used for web server) with some integrity control, as /contextBridge and the root uri namespace are actually reserved by BlazorMobile.

The package updated a lot, still some documentation seem a little outdated or refering removed sections.

Need to do a little review !

• Add a section about server_index.html
• Add change in server-side sample project
• Add change about ElectronNET support
• Rewrite unaccurate/outdated documentation part
• Enforce usage about Xamarin DependencyService requirement in order to register Native side interopping calls
• Add line line change in Startup's cs files for BlazorService.Init and more as the Blazor engine component is not longer required
• Add init line for ElectronNET (dotnet tool install ElectronNET.CLI -g) (electronize init)

Remove Xamarin.Android.GeckoView.Forms direct dependency from BlazorMobile package.
This dependency should only be referenced from the Android specific assembly, preventing to add more build size on other projects

As a fun experience, trying to port BlazorElectronExperiment.Sample here, on Xamarin.

This will be called BlazorXamarinExperiment.Sample

Due to the evolution of the plugin, with the need of BlazorMobile compatibility with the server-side model, it seem that onFinish callback from BlazorService.Init in Blazor project don't callback if a real Device is not found.

It's may not be seen as critical, but it seem we cannot rely on the success boolean returned by the service, as it will return true when success, and the delegate never called if failed or not found.

Reload Blazor application if listening port is not available anymore at resume.

• OK on UWP (never fired)
• OK on Android (fixed and updated the GeckoView component)
• OK on iOS

Launching in Debug Mode from Android 8.0 i can see:

02-19 20:16:47.566 I/zygote64( 9715): Rejecting re-init on previously-failed class java.lang.Class<com.android.webview.chromium.hb>: java.lang.NoClassDefFoundError: Failed resolution of: Landroid/webkit/SafeBrowsingResponse;

We may try to disable safe browsing in Android Manifest with:

<manifest>
 	<application>
 		<meta-data android:name="android.webkit.WebView.EnableSafeBrowsing" android:value="false" />
 	</application>
 </manifest>

Add SourceLink support on NuGet package in order to allow more dynamic and deep debugging if some issues occur about the plugin.

Create a project template for new project creation.

User should be able to create his own template with his own namespace without having to replace manually namespaces from samples.

This does note replace #8 directly.

Functionnality:

Allow Remote debugging from .NET Core / Server implementation to Device
We can't actually debug C# from the WASM version that is embedded in the mobile Device.

However, we can try to implement a mecanism that allow debugging the Mobile app on the remote version for the Blazor app side, and then behave as we are in local with the Mobile / Emulator device, receiving method invocations like in the WASM build version.

So this allow:

• Test and Debug Blazor app code from server .Net Core engine on the development machine.
• Test and Debug Xamarin native side from your Emulator and Device.

We must keep in mind that this is not a real WASM debugging, as it's not yet supported by Microsoft too, but a way to test the code logic and interop for mobile version of the Blazor app.

It does not cover anything if there is a bug in the WebAssembly code of the browser, or something else that behave differently in WASM version.

Add clean samples project with NuGet reference, for new projects

Task id completion may collision with remote debugging, as the local Web context , launching multiple browser devices, are not aware of the other.

We should replace the integer by a unique identifier in order to avoid collisions.

As the title said, they are many update on the future version to be shipped of the plugin.

It's mainly about being able to debug remotely a Device from WASM and NET Core Blazor app version.

Things to do:

• Create/Ship Nuget packages
• Update BlazorMobile.Sample projects to reflect the new way of use, like BlazorMobile.InteropBlazorApp projects
• Updating documentation
• Adding documentation about remote debugging
• Adding documentation about migration from 3.0.0 to 3.0.1
• Ship BlazorMobile 3.0.1 as current master

The current webserver implementation used in this project, Waher.Iot is not free / not commercial friendly, as it require contacting and buying a licence from the author.

We must replace Waher.Iot by something similar and free like EmbedIO

Some url links:

EmbedIO
EmbedIO tutorial

Create a Xamarin.Forms component & CustomRenderer for Webview with GeckoView, in order to add easily GeckoView component inside a crossplatform Xamarin project.

Some reading:

Using a custom native control with xamarin forms via a custom renderer

Custom Renderer: Replacing the native control properly

https://stackoverflow.com/questions/50190568/net-standard-4-7-1-could-not-load-system-private-corelib-during-serialization

The current implementation work but we should be able to fix type mismatch at the type instanciation.

https://gist.github.com/john-cullen/c39d56efcb15e60b66cd4d05149316ed

We have to replace Webview by GeckoView in order to execute Blazor on very old version of Android (Minimum Android 4.4).

Current implementation of GeckoView does not offer Javascript interop injection.

The possible workaround for a seamless usage is to embed a Websocket server, like the one of EmbedIO, in order to have a bidirectionnal communication between Xamarin native environnement and the web application in GeckoView component.

I find this better than having multiple long polling HTTP Request (worst in case of failure), as there is only on single endpoint that remain open.

Websockets examples

The current implementation is using a javascript bridge in order to communicate from the Blazor context to native context, and same when receiving from native to Blazor, on the Blazor side.

This is due to legacy reason at the time. As all Javascript COM communication has been removed in all platform usage, and that we only rely on websockets, there is now no real reason to keep serializing data to string, to then pass it to javascript and then send it.

We should use a pure C# Websocket object, keeping the same current logic behavior. This way we should be able to:

• Prevent constant C# -> Javascript -> C# data conversion
• Being able to send pure binary objects if needed instead of relying to a string data format
• Deserializing directly from binary objects. We may try to use other libraries than JSON.Net for data serialization. Will take a look to Wire or other serializer alternative.

User can zoom Blazor page, it shouldn't as we try to do a pseudo Native mobile app.
Maybe it's just related to the Blazor page, adding this to documentation if needed.

MethodBase.GetCurrentMethod() return MoveNext instead of actual MethodName if method notation is with "async".

The MethodDispatcher should workaround this, or we must evolve the plugin to work on something easy and more reliable.

I think we should add:

Calling / Finding implemented Method though a simple method name (string) even if it can have caveat if you are manipulating very complexe signature (this should not happen often) Need to think about this

• If MoveNext is detected, trying to do some hack to Map from the found method implementation.

Must do more deeper test but non Async methods call on interfaces seems to not return

Add documentation about APK size consideration on Android - One APK per ABI advice.

As the current GeckoView AAR is embedding all Android CPU implementation (ARMv7/ARM64/x86/x64), when BlazorMobile app is compiled, the APK is about nearly 150 MB.

When compiling with the option "One APK per ABI, each minimum APK size go down to 50 MB only, meaning the GeckoView implementation of the requested CPU.

This advice must be added to the documentation.

As we are running on WASM inside a web process, debugging functionnalities are not available.
This must be mentionned in the doc too.

Throw exception if Blazor task cannot be honored.

Improvement are:

• Failed task in native will now throw in the Blazor corresponding task
• Impossibility to connect through socket to native will now throw in the Blazor corresponding task
• Inner exception message from native is transferred to the Blazor thrown exception if catched.

This way, it seem now impossible that a given started task may hang forever if something wrong happen on one side.

When using EntityFramework Core 2.2.6 this error occur when calling, for example, .ToList(); on a table:

System.TypeLoadException
  Message=Could not resolve type with token 0100003f from typeref (expected class 'Microsoft.Extensions.Logging.Abstractions.Internal.NullScope' in assembly 'Microsoft.Extensions.Logging.Abstractions, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60')

After research it seem that some methods signatures does not match between Microsoft.Extensions.Logging.Abstractions 2.2.0.0 and Microsoft.Extensions.Logging.Abstractions preview7.xxx used by the Blazor nuget package.

Also actually it seem that futures Microsoft.Extensions.Logging.Abstractions may be only .NET Standard 2.1, and Xamarin does not support it by the moment.

The best way to solve this problem and being able to use any version of Microsoft.Extensions.Logging.Abstractions required in Xamarin is to remove any Blazor related dependencies from Xamarin project.

This mean:

• An additional NuGet package will be created, BlazorMobile.Web, containing itself, Blazor only components required for the plugin, with BlazorMobile.Common flagged as a dependency. This package will be required on the Blazor web project.
• Strip all Blazor components and Nuget package reference from BlazorMobile.Common.

This way, any very specific Nuget and component versions will be only present on needed related projects.

Actually, there is a bug from System.Text.Json, doing some weird behaviors.

I opened an issue here:

https://github.com/dotnet/corefx/issues/40412

In the meantime, the only "easy" workaround until this is fixed or investigated, is to wrap our JSON to a Base64 string instead when interoping

It's ugly and less than ideal, but there is no way to workaround internally this problem as the JSInterop serializer cannot be changed in the current Blazor implementation.

Actualy, there is a lot of manual thing to do the initial project setup and for make it working.
Installation and usage must be more easy, and at least, only adding the a NuGet package for Build Task on the .Net Standard shared project for mobile must be sufficient.

And also of course, still using the initialization code.

Task to do:

• Use Blazor web project in the .NET Standard mobile project as a reference, in order to retrieve the Blazor project path -> More problematic solution. It is better to separate pure Blazor dependencies to the Xamarin one in the final assembly.
• Being able to usage either WASM or ServerSide Blazor project implementation in reference in the mobile project. -> shipped in BlazorMobile 3.0.1
• Create a BeforeBuild task, executed as .NET CLI Tool or MSBuild Exec that fire on the shared project, after Blazor build, that remove Blazor pure .NET reference (or assume Local Copy == false), and add an embedded ressource ZIP WASM version of the Blazor app project on the shared project. -> Will be shipped in BlazorMobile 3.0.3

Also, useful links:

• MSBuild tasks with dependencies
• .NET Core Global Tools overview

Add a AdjustResize for WindowsSoftInput on Android, as Keyboard may hide HTML input in current view rendering.

A lot of things changed in Blazor API.
Blazor.Xamarin must reflect theses changes in order to works correctly with Interop.

• Blazor.Xamarin Blazor components updated to the 0.8.0 implementation
• Blazor template project migrated to 0.8.0
• Blazor interop project migrated to 0.8.0
• Android support from Android 4.4 and more (blocked by [#12] and [#14])
• iOS 12 support

As there is some bugs on iOS 11 webkit version on WebAssembly, and because iOS updates are very frequent and possible on iOS, nearly all recent devices (iPhone 5s >=) can use iOS 12, and we will take it as minimum requirement for Blazor.Xamarin

Also:

• Rename solution and related data to BlazorMobile.* (because shorter)
• Rework the documentation
• Publish BlazorMobile on NuGet
• Unlist Daddoon.Blazor.Xamarin NuGet package

Migrate from stock Webkit to Crosswalk Chromium, as there is some inconsistency between Webkit versions for WebAssembly support and WebAssembly stability.

Actual version of Blazor (0.8.0 preview) crash on stock Android Webkit, but seem to be working on Chrome browser. Some test must be made.

Integration of Crosswalk on Xamarin
Thread about some details of Crosswalk on Xamarin on Stackoverflow

Add Linux build support.

This issue will be on low, and maybe another implementation stategy will be taken as we are on Desktop, so we can considering using running Blazor in Electron.Net.

Add a bidirectional Message broadcast API.

This way it allow to:

• Fire configured trigger from Blazor to Xamarin
• Fire configured trigger from Xamarin to Blazor

Also give the opportunity to use a less coupled way for communicating between each side

Improvement needed:

• Automatic Http port binding at startup
• Automatic Http port fallback if port unavailable

Very old versions of Android, and more recent version does not support WebAssembly on WebKit / Chrome for Android.

As tested, base image of Android 7.0 and older versions does fail with WebView / Chrome for Android

We will Use GeckoView instead of WebView for Android 4.4 >= support , as it embbed is own rendering and WebAssembly, and is a very modern component for progressive web apps !

See updates of my Xamarin.Android.GeckoView bindings project

As the Xamarin.Forms part is compatible with Mac, we should be able to build Blazor.Mobile apps on Mac.

This issue will be on low, and maybe another implementation stategy will be taken as we are on Desktop, so we can considering using running Blazor in Electron.Net.

Simplify MethodDispatch.CallMethods*

• There should be very few method type to call by Design.
• Enforcing Task method (and derivated) signature only

Evolve contextBridge service as a Task/Websocket manager.

Everything is working fine in the current implementation, but some weird events can occur in some race condition scenario.

The current code is not aware if there is actually a Websocket being open, but not yet. If some events occur very fast at the same time, we may try to wrongly open two sockets.

The new implementations must be:

• From C# to Javascript, a fire and forget with task
• From Javascript side, only queue the task
• The contextBridge from Javascript only manage a singleton connection, and send queued task whenever it can, or fault them. Ideally, this same contextBridge must try to reconnect automatically if the connection close, and try forever if it cannot connect (only waiting the previous timeout).

Try to lower Android support to Android 4.4.

I did have some issue at first try, mostly related to Xamarin.Forms package.
Still, most applications (Snapchat etc.) still support Android 4.4.

GeckoView support Android 4.4, so maybe it's faisable.

Using Json.Net.AOT because of some issue with Blazor at runtime.
See here for more information.

Must try to migrate to the original one if linker change work.

The method dispatcher may be a little rewritten, in order to do something more clear and less ambiguous considering the platform limitations on mono-wasm and mono generally on limited platforms like iOS:

• There is not JIT, only AOT
• System.Reflection.Emit is not available (no JIT) so no DispatcherProxy available too
• mono-wasm is currently limited to one main thread, we must continue on the AsyncStateMachine logic

Automatic restart of webserver in case of crash.

There is some Exception type in order to see if it's a user cancellation or a server invalid operation crash.

We can't actually migrate to WASM Websocket.
We need the following issues to be done:

dotnet/aspnetcore#10489

and

mono/mono#9567 (already done)

Returned exception:

ArgumentException : Could not cast or convert from System.String to System.Type.

Actually it's because the class used for simulating returning a void type, IgnoredType, has been kept in BlazorMobile.Web by error, so BlazorMobile cannot find it when deserializing.

This class should be moved to BlazorMobile.Common package.

At the moment, every step when managing communication between methods in Browser and Native side are done with a string JSON type.

This is not efficient in the long run as:

- Every call to a new method with a value type like a string, result in a value copy
- May occur memory bottleneck when serializing binary value
- String footprint is higher

This should be managed by trying to serialize data to BSON ideally, then added to a MemoryStream we can give between method and dispose when needed.

As EmbedIO doesn't support UAP/UWP on recent version and as Waher.Networking has been removed (not free licence), one solution is to:

• Keep using an older version of EmbedIO, version 2.1.1 in packages dependencies for UAP
• Use the Javascript inter-process communication instead of Websockets on this platform as Websockets are not supported on this platform with EmbedIO

Also maybe considering adding an Electron.NET project template in the future as an alternative.