WIP: Add initial music api stubs and test

[Stubenhocker1399]

Feedback welcome ❤️

• Add test for play, pause, next, prev, volup & voldown calls
  • Automated calls
  • User guided testing (send play command, ask if music started playing successfully)
• Draw something on the display for those tests
• Move the test option down in the menu
• Implement the stubs (? Not sure if I'm up for that task, @ginge would need to help there quite likely)

[jwise]

❤️ This is great! +1 me. One API suggestion might be to implement a music_onchange callback so that users don't have to poll (callback fires for everything but time ticks), though that could go in a second commit.

[jwise]

Oh, yeah, one PR meta-nitpick: for WIP PRs, please include a checkbox list in the description of what's left before you think it would be ready to merge. (If a design review / code review is all that remains, and you'd be happy with something being merged as is otherwise, no need to put "WIP" in the subject.) Thanks!

[Stubenhocker1399]

Yeah, thought about a callback (see https://github.com/ginge/FreeRTOS-Pebble/pull/116/files#diff-9b012897d7876f3a3a7756e12ba612cfR38), might check out how to implement one. 👍

Thanks for the meta-nitpick, will update~

[ginge]

Oh yeah, this is just lovely... I'm happy with this, good job. I'll spend a bit more time poking, and I do agree a callback will be required at some point. We use callbacks quite a lot, buttons are a callback, so should be plenty of examples to work from

[Stubenhocker1399]

Ok, I implemented callbacks for on_music_change, on_music_play_pause and on_music_skip.
While puzzling this together I've added an context to the music_track_info, however I don't think that it is needed, so that is up for removal.

Also it's using app_calloc and app_free for the music info struct, thus adding the need for it to be passed around and making me think that all the track info related setting and getting are a bit wonky at the moment, I'll have to think about that a bit more (not a 100% sure in my mind how those interact with the actual pebble protocol calls yet).

As for the testing I am thinking about implementing a stepped through test, where the tester presses play and then reports if the music started playing successfully by answering yes or no.

[ginge]

so general musings here... How many music_track_info do we expect to have in existence at any one time? I can't think of a use case where there would be multiple music tracks required.
What that thought in mind, we could consider having only a single opaque music_track_info, and not require it for the function signatures. so, say, music_get_current_artist(void);

in terms of how pebble would then interact with this, i'll basically have it fill in that music_track_info struct when some data arrives.

[Stubenhocker1399]

Would that single opaque music track info be in memory all the time or should I keep the init and deinit calls?

[Stubenhocker1399]

Ok, kept the init and deinit calls, removed the passing of the struct.

@ginge Should I extend the music test to include more manual interaction or is the current simple one ok?