At some point we'll want to explore support for no_std platforms. Our initial focus is on major mobile operating systems, which have support for the full standard library, but certain embedded platforms we may target in the future may not.
This issue tracks known steps we'll need to take to support no_std:
[ ] non-UniFFI interface: UniFFI requires the standard library, particularly making use of things like std::sync::Arc in constructors, and types like std::time::SystemTime for mapping timestamps.
[x] We use std::collections::HashMap a few places; could probably replace with alloc::collections::BTreeMap; we can also use Vec from alloc
[x] NavigationController currently uses a Mutex for internal state mutation. This is arguably an antipattern and breaks the clean "functional core / imperative shell" pattern. We should probably rearchitect this to return a new controller state (which must be saved by the caller) before v1.0.
At some point we'll want to explore support for no_std platforms. Our initial focus is on major mobile operating systems, which have support for the full standard library, but certain embedded platforms we may target in the future may not.
This issue tracks known steps we'll need to take to support no_std:
std::sync::Arcin constructors, and types likestd::time::SystemTimefor mapping timestamps.std::collections::HashMapa few places; could probably replace withalloc::collections::BTreeMap; we can also useVecfromallocNavigationControllercurrently uses aMutexfor internal state mutation. This is arguably an antipattern and breaks the clean "functional core / imperative shell" pattern. We should probably rearchitect this to return a new controller state (which must be saved by the caller) before v1.0.