Hello qaul.net community mailing list,

I just pushed some changes to the main branch (develop) that implement
most of the android glue code to make the app actually work (the
wifi-direct connection mode is partially implemented and needs some
channel magic in kotlin to work).

There's some caveats though, only the chat service is exposed, and after
user creation it's currently not possible to change your name.  Expect
bugs!

If you find anything that blocks you from continuing, please e-mail me
(Cc to kookie@spacekookie.de), and I'll have a look before the 13th of
july.  AFTER the 13th of July I'll be off the grid for 2 weeks!)

Hope testing goes as smoothly as possible and yields some useful data
about the existing code!


~k


---

I'm writing this e-mail while still hacking to keep track of a few
things that are really not solved well, or just need to be solved at all
as the testing progresses.  Consider this a TODO list for the next few
months.

- Find better Java - Rust FFI abstraction

  The JNI crate is quite cool and good, and makes a lot of the JNI stuff
  possible, but it's not great, and we need a more high level
  abstraction over it.  Especially conversions from Rust to Java types
  could potentially be automated, if we give a Rust crate access to the
  java module, parse the java code and output trait implementations for
  `ToJObject`, `FromJObject`, etc.

  The main idea would be to have a way to generated both the function
  stubs, code that saves and retrieves data from the passed in `this`
  instance, the JNIEnv, and also handles the memory domain of the native
  state (currently this is being done by manually calling
  std::mem::forget).  We should have a look if there's more type system
  magic that I'm missing so that we can make sure we never accidentally
  clean up our work state.


- Subscription types

  Currently the only way to get data into the Android app is by loading
  a view and having it fetch data.  A much better approach would be to
  create a generic interface that can be pushed to, which then handles
  updating views, and then hooking up the push code from the Rust
  subscription objects.


- Hook up filesharing, voice, and feed services to android views
- Try to deduplicate recycler view adapter code (especially with
  subscriptions in mind)
- Fix the issue where the registry screen isn't full screen
- Make text fields always focus by the keyboard
- The chat view should fill out the whole screen, not just the inner
  frame inside the nav view holder
- Populate avatars from local and remote users
- Figure out alexandria persistence on Android
- Create a connection management dialog
- Additional menus?
  - Is the bottom nav enough, plus an overflow ... menu?
  - Do we need a sidebar that has more items?
  - How to communicate the general app-state (not just notifications,
    but connections?
- Unify API endpoint language
  - All functions of the same type (create, update, ...) should behave
    the same across the whole library ecosystem
  - Singularise/Pluralise consistently
  - Name fields in types consistently
- Investigate new async_std channels API update
- Start laying out the basics for the service-service RPC server
- Look into specifications for the ratman transport encoding (see
  existing standards)
- Test timestamp behaviour between services (currently only chat has
  working timestamps)
- Figure out a second endpoint API to make the remove_ep API on the
  router redundant:  we could communicate additional metadata for
  endpoints that support it, such as deleting or configuring it after
  the router has already started running.
- Pick a serialisation format and stick with it (bincode all the way?)