feat(mobile): multi window support - #1633
Conversation
flexible margin somehow makes the window centered at the bottom (pushes all edges)
Package Changes Through 5c83d7bThere are 1 changes which include wry with minor Planned Package VersionsThe following package releases are the planned based on the context of changes in this pull request.
Add another change file through the GitHub UI by following this link. Read about change files or the docs at github.com/jbolda/covector |
| // set all autoresizingmasks | ||
| webview.setAutoresizingMask(UIViewAutoresizing::from_bits(31).unwrap()); | ||
| // let () = msg_send![webview, setAutoresizingMask: 31]; | ||
| webview.setAutoresizingMask( |
There was a problem hiding this comment.
This sets the autoresizing mask for the webview, which is the legacy (pre-Auto Layout) way of handling view resizing in iOS.
- Doesn't automatically respect safe areas (notch, home indicator etc)
- Webview may extend under system UI elements
- Needs additional code to handle safe area insets
It may be worth considering moving to Auto Layout e.g.
webview.setTranslatesAutoresizingMaskIntoConstraints(false);
// Add constraints to fill parent while respecting safe area
NSLayoutConstraint::activateConstraints(&[
webview.topAnchor().constraintEqualToAnchor(&parent.safeAreaLayoutGuide().topAnchor()),
webview.bottomAnchor().constraintEqualToAnchor(&parent.safeAreaLayoutGuide().bottomAnchor()),
webview.leadingAnchor().constraintEqualToAnchor(&parent.safeAreaLayoutGuide().leadingAnchor()),
webview.trailingAnchor().constraintEqualToAnchor(&parent.safeAreaLayoutGuide().trailingAnchor()),
]);There was a problem hiding this comment.
that's something we should investigate in a separate PR - my first attempt resulted in a crash
and I believe this would be consider a breaking change too, most users offset the notch etc via HTML
| } | ||
|
|
||
| pub fn first_activity_id() -> Option<ActivityId> { | ||
| ACTIVITY_PROXY.lock().unwrap().keys().next().cloned() |
There was a problem hiding this comment.
Possible race condition if activities are destroyed while being accessed.
There was a problem hiding this comment.
ACTIVITY_PROXY is a mutex and first_activity_id is only used in cases where the actual activity instance doesn't matter
| override fun onStop() { | ||
| super.onStop() | ||
| stop() | ||
| id = savedInstanceState?.getInt(ACTIVITY_ID_KEY) ?: intent.extras?.getInt(ACTIVITY_ID_KEY) ?: hashCode() |
There was a problem hiding this comment.
hashCode() fallback could theoretically produce duplicate IDs, breaking message routing.
There was a problem hiding this comment.
that's why we are persisting the id in the saved instance state
| pub static EVAL_ID_GENERATOR: Counter = Counter::new(); | ||
| pub static EVAL_CALLBACKS: OnceCell<Mutex<HashMap<i32, EvalCallback>>> = OnceCell::new(); | ||
|
|
||
| pub fn destroy_webview(activity_id: ActivityId, webview_id: &WebviewId) { |
There was a problem hiding this comment.
While it doesn't pose a significant memory leak, do we have a similar function i.e. destroy_activity(..) where we clean up ACTIVITY_PROXY?
Co-authored-by: FabianLars <30730186+FabianLars@users.noreply.github.com>
3 participants
follow-up for tauri-apps/tao#1154
includes a refactor to only load Android library once