I’m thinking of providing an in-app UI to change some options in RadioConfig.UserPreferences:
Any comments/ideas?
An option to disable location updates would be cool.
And router mode
Oh, cool! I think the UI should include everything on both the ChannelSettings object and the UserPreferences object.
It’ll be a lot but then we can add additional preferences without having to hard code it into the app. We do the same with the python api.
The caveat may be that you may want to include a description or a user friendly name for the setting, but then the availability of the settings shouldn’t be dependent on description and a friendly name.
would it be possible to have a spot to type a command. This way as the firmware progresses, if the Android App doesn’t progress as fast you can still enable or disable new features through a make shift command line?
Maybe under an Advanced Tab or or Preferences Tab
@mc-hamster, are you proposing to use proto reflection API to generate Android UI widgets? It is possible (and there maybe even some libraries for that, not sure), but I feel this maybe not good for the following reasons:
There is an option of having “basic” vs “advanced” settings screen, with “basic” providing curated set of settings and “advanced” doing what you propose.
You bring up a good point. Splitting between a basic and advanced screen would be ideal. We need to be mindful of maintaining a positive user experience and there are a lot of settings.
If possible I’d love an easy button to revert back to the default channel.
You know, now that I think about it … @satkiwii 's idea about having a manual text input for advanced features is actually very elegant. Having a text entry is, by every definition, advanced. It also serves the purpose of not cluttering the UI.
Yeah, I agree that manual command fits advanced usage better. But what kind of commands do you want to send? Is there already a set of commands defined somewhere for meshtastic devices? Sorry, I’m probably missing some context here…
The settings would map to the property value pairs in the ChannelSettings object and the UserPreferences object.
I can imagine something like… (Please excuse the crudity of the model, I did not have time to build it to scale or to paint)
Channel Settings
property [ ] value [ ] (SUBMIT)
User Preferences
property [ ] value [ ] (SUBMIT)
(View All)
A user would be able to enter the property and value that they want to modify for each object.
(View All) would enumerate all the current values in Channel Settings and User Preferences and just display it in a similar form as the current debug window prints out the received protobuf objects.
Of course I suspect you may have other ideas too 
Amazing!
Could you change pretty much any of these?
Love this idea. I’d vote for:
The "advanced preferences tab/panel/dialog/whatever is populated as three columns:
the left column has the name for the preference,
the middle column contains the editable value (either as an int, a string or a boolean checkbox)
the right column has a either a question mark and if you click on it (or hover over it) it shows a tooltip paragraph of text on what the parameter is and what it means"
These rows would come from the following data structure:
an array of structs with “field name”, field type, paragraph doc. If you wanted to be fancy some of this could be pulled by reflection on the generated protobuf class, but I’d start with just a hard coded array with the most popular parameters. Eventually that array could instead be moved to be a JSON (or other) datastructure kept in the protobuf project (so we could use the same metadata in the python and javascript code).
That said, all the stuff you’ve done so far has been great so if you want to instead tackle just the "more polished/nice experience for a few of the most critical UserPreferences that would be great also 
I’m a big fan of having the advanced tab available. Even if it’s a little hidden to avoid confusing people who shouldn’t be mucking around in there. It lets power users break or fix things through 1 common interface rather than messing with multiple interfaces.
Another idea: for advanced settings, maybe we can we provide a simple html form, that could be rendered both in Android webview and on device HttpServer?
That would make it easier to develop and keep things in sync.
The upcoming Meshtastic Web has an interface to edit all the preferences. I’ve been using it, it works well.
Is the “Meshtastic Web” the http server that runs on device when it comes as a WiFi AP? Can somebody point to the code for rendering?
For advanced users, is this “Meshtastic Web” sufficient or Android UI will be also useful? (probably yes)
I’ll send you a few messages over PM.