Holiday Hacking 1: Architecture: Flatten key press handling #83

- Rely on default init values - Deduplicate range check

…ner pattern)

The hub itself shouldn't implement its own listener-interface, to avoid infititely-recursive triggers, so un-implement PianoListener, and rename the 'onKey*'-methods to 'doKey*' to signal their importance.

…ic helpers. The old `SOUNDSET_DIR_PREFIX` already indicated in its name it wanted to live in a SoundSet class. Additionally, it's not just for DIRs, since it's also (ab?)used to get at the translation keys. As such, move the prefix to SoundSet, and isntead use SoundSet helpers everywhere the prefix is currently used. Also, the SoundSet class, which is already handling the raw folder access, is a far better candidate for scanning that folder, than the current SettingsFragment.

An interface for something with only one sane implementation (SampledSoundSet) might seem like overkill, but this allows us to write tests without adding a dependency on a mocking framework, which would be worse overkill.

…istener. Move the last context-awareness out of piano, by converting `play_sound()`, including all its supporting infrastructure, to external PianoListener. Rather than one single, complex Melody-Preference-checking Listener, use a strategy pattern with two simple listeners: - one for 'normal' behaviour: StraightKeySoundMaker - one for melodies: MelodicKeySoundMaker Choose which one to listen with only once during piano-init, rather than checking melody-not-null on every key-press.

It was getting cluttered in the main package.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Holiday Hacking 1: Architecture: Flatten key press handling #83

Holiday Hacking 1: Architecture: Flatten key press handling #83

Commits on Dec 1, 2023