Native Ooui Deployments

[Mike-E-angelo]

This is a task that I have on my plate, but real world work will be my life for the next several weeks, so I wanted to throw this out there to see if the community might be able to assist in the meantime.

This builds off of #74 (comment) and #109. The goal is to create a native Ooui deployments, with a sample/HelloWorld (button?) application that is deployed to the following hosted store environments:

• Windows Store
• Google Play
• Apple Store

As mentioned above, I got this working on a local Windows UWP application and it works fine. In theory, it should "just work" fine in all the above hosted environments as well, as connections are made and connected to within the process the client application is running. That is, no external outbound or inbound connections are made or used. Since the listener and subsequent port is created locally in process, and the calling client is also created locally in process (via web browser), there should be no problems with getting that connection to work as expected.

I emphasize should as I do have a Xamarin forum post asking about this very issue, and the only reply I got thus far seems to suggest that this might not be possible, so I am wanting to find out with 100% certainty because as outlined above it should totally work. 😄

Finally, it is my thinking that we create Ooui.Native.<Platform>.sln solution files and put respective native projects in there, as not everyone has these workloads installed in Visual Studio and I believe they will be confronted with dialogs explaining as such when opening solutions. Adding these projects to Ooui.sln would be a bad idea from an overall developer experience point of view, as they would be confronted with these messages with the default solution if I understand correctly.

Thank you for any consideration, discussion, feedback, and/or assistance you can provide with this issue!

[praeclarum]

I designed Ooui to support this scenario from the beginning so am very much interested in making it happen.

My plan was to have the base Ooui library able to work on mobile just fine. However, Xamarin.iOS doesn't completely support netstandard2, so caused problems.

On reflection, I think I will create yet another package Ooui.Mobile that would swap out the parts needed by the mobile platforms.

This would also allow me to fine-tune it to the platforms. I imagine implementing a more efficient comm session between the browser and the app logic (instead of the web sockets used now). I would also have the ability then to dress up the native UI outside the browser.

Perhaps Ooui.Native is a better name though since desktop apps should be supported.

I think all the platforms could be combined into 1 package. Or do you think there is a benefit to splitting it?

[Mike-E-angelo]

Cool! Well, to give you more context around my thinking here, "native" to me is any context where the application rendering via native display technologies. Essentially, it's "native" (iOS/Droid/Windows) and "web" (browser-hosted). I have no problem with how we name it, just that these two areas are delineated.

Now, when you say "package" do you mean solution? or are you thinking nuget package?

I'd also like to reiterate that my primary interest here is to ensure that these hosted store environments allow Ooui to operate like it does on a webpage. That is, I am wanting to verify that HttpListener works as expected in a hosted store environment, for all the stores. Having things fine-tuned is a secondary goal for me, but that is super cool you are thinking that way. 😄

[praeclarum]

Hmm, I'm not sure we're both thinking the same thing. So let me ask some questions just to be sure (since native means so much these days):

1. Do you imagine Ooui running inside a web browser view inside of a native shell app (like Electron)? This is what I was imagining.

2. Do you imagine using native control like UIKit.UILabel and Android.View.Label?

3. Are you talking about custom rendering everything like Flutter?

I plan on doing 1, but 2 and 3 would be a huge amount of work.

[Mike-E-angelo]

Haha, it's very possible that we are not talking about the same thing! 😆 This is good exercise for me as it ensures that I am using the right vocabulary.

My intent here is very simple: to deploy Ooui to the hosted store application repositories for each of those platforms. That's the end goal. I call each of these stores "native" as they are "native" to their each respective ecosystems. That is, they utilize their own native resources to host and display (render) the applications when the consumer ultimately installs, launches, and views them on their "native" (platform-aligned) device.

Did you take a look at the UWP sample that I provided above, by chance? That is exactly what I am thinking of doing, only instead of running it locally on the developer machine as it is right now, the goal is to fully deploy it to the Windows Store to ensure that it actually operates as expected there. The same goes for Apple Store and Google play.

So to answer your questions:

1. Correct. This is what I am doing in the UWP example I provided. If you could, please take a quick second to view it and ensure we are talking about the same thing. I think it would clear up any confusion here.
2. No. :) This is all you!
3. Same as previous question. 🤓

I hope that helps clarify my intention and direction here. Very simple and should take a day if you have accounts already setup to UWP/Apple Store/Google Play. Unfortunately I do not have any accounts setup for any of them so it would take quite the investment on my part. This is one of the reasons I am reaching out to the community first before I dive in. 😄

[Mike-E-angelo]

Hey @praeclarum ... in the interest of keeping your board's activity/issue count down (😄), have you heard of Progressive Web Applications? I am sure you have. I have been studying them, myself. It looks very close to what Silverlight had back in the day when you could "install" a Silverlight application on the desktop and it would run from there.

This is very compelling technology, and the MOST interesting part is that it appears you can "wrap" these applications and install them in a native-hosted store (the ones that I list out in the original post of this issue).

If that is the case, that makes my intentions here with this issue moot, not to mention incredibly simplifying the entire deployment story. We no longer need to account for native-hosted stores but simply wrap Ooui applications in the PWA wrappers that each store provides. Windows Store has one but I have not checked the others.

In any case, if I understand this all correctly, this issue is no longer relevant and can be closed. Please feel free though to re-open if I have misunderstood something and/or if you would like to keep it open for other purposes. Thanks again for the dialogue!