-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Navigation #239
Navigation #239
Conversation
…tive-core into wasm_tests_iteration
/// Destination URL | ||
pub to: NavHistoryEntry, | ||
/// Additional user provided metadata handed to the event handler. | ||
pub info: Option<Vec<u8>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could this match the name state
in the NavHistoryEntry
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
info
and state
are two different things, the history entry contains persistent state which will always be included whenever it shows up in a navigation event, or when NavCtx::current
accquires it. info
is ephemeral and is passed to the event once.
I based this off of the web navigation api's naming scheme which is honestly not great.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
event_specific_info
might be more descriptive.
|
||
#[derive(uniffi::Object)] | ||
pub struct LiveSocket { | ||
pub socket: Mutex<Arc<Socket>>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm confused. Why's socket a Mutex<Arc<Socket>>
? Wouldn't the mutex be locked for the entire time that someone has a reference to the return of fn socket(&self)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, we have a really bizarre API underlying this which returns an immutable object inside and Arc
because the socket was expected to be orchestrated over FFI. So there is no way around the having the internal smart pointer.
When you lock it and clone the Arc
you get an immutable reference to the internal smart pointer without the mutex. The only thing that holds a reference to these sockets is the LiveChannel
struct, so it's beholden upon the consumer to drop the old dead LiveChannels
, which are now disconnected, to avoid a memory leak.
#[cfg(target_os = "android")] | ||
const HOST: &str = "10.0.2.2:4001"; | ||
|
||
#[cfg(not(target_os = "android"))] | ||
const HOST: &str = "127.0.0.1:4001"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. I think you can use super::HOST
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you've covered all my suggestions.
To address #166 and tangentially #212 this PR aims to add a web like navigation API to the
LiveSocket
object.