Android app improvements, multiple layouts problem

[pzmarzly]

In Android small improvements right now would be:

• a reconnect button
• correct IP should be based on zeroconf data (using IP from zeroconf and port received from Yoke instead of IP:port combo from Yoke) - another method to deal with multiple interfaces would be fine too. Then --iface option could be removed or modified (despite its name Yoke always binds on 0.0.0.0, the option sets which PC interface is accessible from app's point of view)
• stop appending 3 floats to each message (that's like 54 bytes wasted per message. doesn't sound much but I can imagine some routers struggling) - corresponding code on Python side is marked for removal with TODO: comment
• after reconnecting (or connecting do different machine), Yoke app keeps sending status from before the reconnect, until some layout is selected (so that update_vals is called)

Multiple layouts: navigation

Right now hitting Back makes the app quit. It could instead bring user back to layout selection screen. However, currently app makes it impossible to achieve on HTML/JS side alone.

Navigating with <a href="..."> causes browser selector to pop up:

Meanwhile I made history.pushState-based system that in browser, but in app the back button event gets intercepted by app (HTML doesn't get any event)

Multiple layouts: management

Right now some settings are adjustable in base.js. Also, since layout is hardcoded in Python code, and some programs ignore SDL gamepad string, user may want to customize Python code. This is fine (I adjusted README to show this better), but a bit troublesome.

User may want VIBRATE_ON_PAD_BOUNDARY to be on on gamepad layout, but not on racing layout. If they ever create custom layouts, there would be even more problems. There are few solutions I can think of:

1. Move these 2 new boolean settings to CSS - but that would make 3 options per joystick (locking? vibrating on quadrants? vibrating on edges?), which means 8 joystick types (+ number) instead of current 2 (locking or non-locking).
2. Move all settings to JSON files. We could have it like [{type:'joystick',id:1,locking:true,vibrate_on_pad_boundary:false,x:100,y:300,background:'file.svg'},{type:'joystick',id:2, ...}]. Default options of course wouldn't need to be specified. It wouldn't have to be JSON, could be e.g. TOML. We would need either a good editor, or at least a reference (list of all widgets with their default options).
3. Move back to single layout system and tell users to use Git branches for different configs. That would let them customize Python code. If they chose not do modify Python code, they could have hot-reloading with pip3 install -e . (symlinks instead of copying files). Versioned config files could be a plus, too. The downside is that Git is not newbie-friendly. We could make some helpers, e.g.

yoke new gamepad csgo -> git checkout gamepad && git checkout -b csgo # default gamepad preset would be a branch
yoke save -> git add ${YOKE_ROOT_DIR} && git commit -m $(date)
yoke list -> git branch
yoke history csgo -> git log --oneline csgo # branch is optional
yoke set csgo -> git checkout csgo
yoke rm csgo -> git branch -D csgo

In the third scenario, Multiple layouts: navigation part could turn out to be unnecessary.

@medape @rmst : your opinions are welcome

[medape]

I just saw this right now, and I'm going to try answering in order.

Small improvements

The Android framework is just intuitive enough for me to be able to delete things. I think I managed to cover your third point (stop sending floats before every message).

I'm not very knowledgable in networking and even less in zeroconf, so I can't give any opinion there. I'll be okay with whatever method you use.

The rest of your improvements would be very useful, and I'd appreciate it if either you or @rmst could program them in.

I'd also like to remind you about

• hiding the action bar. Modern phones don't have hard keys and accidentally hitting one button would automatically disconnect the gamepad.

Multiple layouts: navigation

This probably could be done on JavaScript alone (by adding a button to refresh the page) but I like your method better. The screen is cluttered enough as it is.

Multiple layouts: management

I was thinking about that, too.

Options 3 is a very difficult method, and little better than the users editing base.js themselves. Using the CSS or the JSON would be good ideas, but I have another approach:

4. Presenting a configuration popup from the webpage itself.

Every default layout could have a special small button on a corner. This wouldn't actually be a gamepad button: when a user touches it, it would bring up a window like this:

---

OPTIONS

• Vibrate on joystick quadrants
• Vibrate on joystick borders
• Self-centering joysticks (shouldn't this be changed from the CSS?)
• Enable force touch
• Click here to change background colour or whatever

---

To avoid accidental presses, this window would only appear when holding the button for longer than two seconds.

We could even think of eventually translating these to any language, or setting up cookies to remember the users' preferred config, but for now I wouldn't worry about that. Users can for the moment set everything up every time they load the page; there aren't that many options.

EDIT: This button should also appear in every CSS file (we could call it cfg or whatever) so users can move or remove it if they really want to.

[medape]

I uploaded a “pre-release” to my fork, just in case @pzmarzly hasn't got Gradle set up.