feat: add cross-platform NativeWindow implementation#11181
feat: add cross-platform NativeWindow implementation#11181edusperoni wants to merge 3 commits intomainfrom
Conversation
- Introduced NativeWindow class to manage platform-specific window behavior for iOS and Android. - Added interfaces and common functionality for NativeWindow, including event handling and lifecycle management. - Implemented Android-specific NativeWindow logic to wrap AppCompatActivity and manage its lifecycle. - Implemented iOS-specific NativeWindow logic to wrap UIWindowScene and UIWindow, handling view controller setup and trait collection changes. - Updated core index files to export new NativeWindow functionality.
|
View your CI Pipeline Execution ↗ for commit 50f8880
☁️ Nx Cloud last updated this comment at |
|
Great start here, it might be helpful to setup a new demo page in toolbox or repurpose |
…ling - Refactored NativeWindow to separate platform-specific implementations for Android and iOS. - Introduced AndroidNativeWindow and IOSNativeWindow classes extending a common NativeWindow base class. - Updated lifecycle event notifications to emit events directly from NativeWindow instances instead of the Application class. - Deprecated direct event listeners on the Application class in favor of listening on NativeWindow instances. - Removed redundant index files for native-window on both Android and iOS platforms. - Enhanced type definitions for NativeWindow events and interfaces to improve clarity and maintainability.
|
|
||
| // --- Typed event overloads --- | ||
|
|
||
| on(event: 'activate', callback: (data: NativeWindowEventData) => void, thisArg?: any): void; |
There was a problem hiding this comment.
those should go into a native-window.d.ts file (which is missing by the way)
| onSceneConfiguration: ((application: UIApplication, connectingSceneSession: UISceneSession, options: UISceneConnectionOptions) => UISceneConfiguration | null | undefined) | null; | ||
|
|
||
| /** | ||
| * @deprecated Listen on a NativeWindow instance instead. |
There was a problem hiding this comment.
i dont think we should mark those as deprecated. There is a lot of power in having Application events.
It is the only place where we can have all windows event from one single listener.
same for orientation and all other events.
I think it is great to have them both in NativeWindow and Application.
plus we ll never be able to remove them. Application events are deeply used in all existing apps and plugins.
| getRegisteredBroadcastReceivers(intentFilter: string): android.content.BroadcastReceiver[]; | ||
|
|
||
| /** | ||
| * @deprecated Listen on a NativeWindow instance instead. |
There was a problem hiding this comment.
Same thing i would not deprecate those, only explain you can do it through NativeWindw
There was a problem hiding this comment.
should the android NativeWindow listen to configuration change, just like we do in application?
It should store it s configuration, font scale, orientation... use them for accessors but also notify the NativeWindow about them. Just like we do in Application.
maybe we can even have Application plugged to use accessors, events from the main window?
Not sure about this because in application we use context and not activity i think, not sure what difference it makes for configurations like orientation, font scale ...
| } as AndroidActivityNewIntentEventData); | ||
| } | ||
|
|
||
| // @deprecated - Bridge to Application.android for backward compat |
There was a problem hiding this comment.
i wouldnt deprecate here again. It is really nice to have that
This is a draft POC implementation.
The goal is mostly to discuss the approach and refine it.
We introduce a new class (NativeWindow) which will handle most multi-window functions.
We slowly deprecate 'launch' event and other Application events in favor of the window events.
Ideally we also add something like:
View.getNativeWindow()so you can get the NativeWindow of a specific view. All plugins will have to adapt to this new API, but we'll provide backwards compatibility.In sum, we the following concept:
The developer can choose how to handle this. Example from my angular background:
bootstrapApplication(...)("root" services are per-window, "platform" services are shared)createComponent("root" services are shared, navigation has to be similar to modal navigation)