Replies: 2 comments 4 replies
-
Hi! My current experience with this APIs shows that there is a number of pitfalls with
As for the callbacks, I suggest that you look at the approach currently used in #29 which. My personal suggestion would be to join our efforts working on #29. |
Beta Was this translation helpful? Give feedback.
-
I'm not really familiar with |
Beta Was this translation helpful? Give feedback.
-
Hi. I'd like to make a safe wrapper around
sys::ViewDispatcher
. Like furi thread, I'd like to use closures for callbacks instead of function pointers. As per the discussion from #80, it sounds like the right thing to do would be to make theViewDispatcher
methods take&mut self
, since the C code will take a raw*mut sys::ViewDispatcher
pointer and mutate the view dispatcher. Although it's worth noting that theNonNull
type will happily produce a*mut T
from a&T
without any compiler complaints.However, most of the time in a view dispatcher callback / closure, you want to do something with the view dispatcher. This leads to a multiple mutable borrows error. For example:
And an example program:
Here
view_dispatcher
is borrowed as mut by the closure,set_navigation_event_callback
, andrun
. Using the usual Rust tools of wrappingview_dispatcher
in anRc<RefCell<T>>
doesn't work becauseview_dispatcher
is in fact borrowed mutably in multiple places at the same time soborrow_mut()
will panic. Quick note: all the view dispatcher callbacks are invoked from the thread that calledrun()
so noArc<Mutex<T>>
should be required.One idea is to make all of the
ViewDispatcher
methods take&self
, even though they may mutate the wrappedsys::ViewDispatcher
. Then we can pass/capture cloned / immutableRc<T>
s without complaint.Another idea is to pass
&mut ViewDispatcher
as an argument to the closures.This works until we want to use a mutable method (like
send_custom_event()
) for our view dispatcher from another place (like an input event callback). We've exposed our view dispatcher as mutable in the view dispatcher callbacks, but it's still borrowed as mutable and unavailable to use else ware.@dcoles @str4d @JarvisCraft Do you have any thoughts on this potential design?
Beta Was this translation helpful? Give feedback.
All reactions