uno.extensions
uno.extensions copied to clipboard
unoplatform
Centralize Lifecycle Events Hooks
What would you like to be added:
.NET MAUI contains platform lifecycle hooks off their app builder which makes it easy for 3rd party plugins to hook into things like the android activity or iOS appdelegate events without having to create inherited classes like MyUnoAppDelegate
Why is this needed:
Makes it easier for OSS maintainers to hook into the increasing .NET UI market without large investments in time.
For which Platform:
- [x] iOS
- [x] Android
- [x] WebAssembly
- [ ] WebAssembly renders for Xamarin.Forms
- [x] Windows
- [ ] Build tasks
Anything else we need to know?
I will be able to integrate Shiny into Uno without extensive documentation, boilerplate code, or ongoing maintenance
This is interesting. At this time, there's no need to inherit from anything for iOS, as the App.cs App class already provides all the overrides provided by the AppDelegate is it inherits from it directly. It does not provide events like Uno's Android MainActivity does.
For Android, the MainActivity file in the app contains events (in addition to all the overrides) for all the lifecycle .NET events provided by Uno.
I understand this is not as centralized as what MAUI provides, and I'm wondering if uno.extensions is the right layer to place this kind of enhancements. Maybe uno.toolkit is better suited.
I'm not sure what the toolkit does differently. I only recommended the hosting extensions because it would match the same setup model as MAUI.
The events from Application.Current on iOS don't have all of the event hooks I'm looking for - DidFinishLaunching so I can access the launch args and ContinueUserActivity for things like NFC.
For Android, I need to ensure things are being registered and run at the android application level. I don't think this will be a problem for the way uno inits. I can hook the android activities through the android app lifecycle and hook/unhook the events on uno activities accordingly.
Yeh I think in terms of raw support for events it's probably something to add to Uno.Toolkit (@jeromelaban are you referring to the uno.toolkit in the uno repo or uno.toolkit.ui?) which makes it available to anyone irrespective of whether they use uno.extensions. Once this is added, we can add support in Uno.Extensions to make it easier to hook events via the host builder
@nickrandolph I mentioned Uno.Toolkit.UI if we want to make more "fluent" set of helpers.
@aritchie indeed, Uno for iOS does not provide many events here, though the overrides you mention are available, even if not the best way to handle things in the simplest way. Is it the overrides you're talking about or actual events?
@jeromelaban The delegates expose all of the overrides. The events Uno exposes on the appdelegate are insufficient for a lot of 3rd party/plugin people. Having the user override those delegates and place a line of code in them is (not) surprisingly a difficult task.
This code here is how I integrate with MAUI https://github.com/shinyorg/shiny/blob/master/src/Shiny.Hosting.Maui/ShinyExtensions.cs
It is perfect for my needs and requires the user to add "UseShiny()" in their hosting code. No other boilerplate code required. I'm looking to add the same to Uno through the hosting package. The cleanest way to do this (in my opinion) is to add the missing events to the app delegate. I haven't checked the other platforms on how to go about this just yet. I'm guessing Android is going to be a pain because of the activity.
GitHub
A Xamarin Framework for Backgrounding & Device Hardware Services - shiny/ShinyExtensions.cs at master · shinyorg/shiny
Yes, the use such similar-looking APIs is definitely interesting.
The discussion here is about where such new APIs would go, considering those are not part of the WinUI API. It's not particularly relevant to Shiny, of course, but is for the dependencies created between packages, and what goes where.
There's no "hosting" capability as far as uno.winui is concerned, which means that for the most parts, it could be a helper class to register handlers, or events that could be exposed directly on Application, and how should those be exposed to another library whether is Shiny directly, uno.toolkit or uno.extensions.
Those are open questions for which we do not have an answer yet.
No decision has been made around this, mainly because such an implementation would be Uno targets specific, and WinAppSDK would not be able to follow. MAUI is able to do this because it has an abstraction over Application, and is able to redirect every override at the right place.
Thinking about it further, the only way I could see this working would be through a source generator, maybe provided by Uno.Toolkit, which would override individual methods properly and would detect if the overrides are present in user code.
Alternatively we could have the source generators in uno.extensions and leverage the hosting model