Android music app build

Every other bugger is building amplifiers, so rather than clutter up other threads with my random whining I figured I’d put it in its own thread. Feel free to mute.

I’m currently not working, and occasionally bored, so I figured I’d have a play with Android development. My background is all in server-side Java programming. So, Java - check, Android - not so much.

I installed the free “Android Studio”. This was the first serious hurdle. I’ve used the Eclipse development environment for the last 15 years. Android Studio is based on its mortal enemy, IntelliJ. Ho hum, there are a few conceptual differences, and a lot of basic key bindings to relearn.

Android already comes pre-loaded with a heck of a lot of support for storing and indexing media, and decoding and playing music. If I was going for the full monty reading music and playing it from scratch I’d be here forever. So this job is most likely to be concentrating on the user interface.

After poking around API documents and Stack Overflow for a couple of hours I discovered that the Android Open Source project already had a freebie music player app on GitHub. It’s a lot easier to learn by modifying someone else’s code than to start from scratch, particularly on a very unfamiliar platform, so this suits me down to the ground.

The basic idea is to mash this app around to do what I want. Eventually there will probably be nothing left of the original.

My basic requirements are:

  • I want it to play FLAC files that are local to the device.
  • I want it to handle the “album artist” tag gracefully, and not just use the “artist” tag.
  • I want album art to work properly, just like it doesn’t in Google Play Music. Particularly I want to be able to display a folder.jpg that is in the same folder as the source file.
  • I want it to work with USB DACs like the Chord Mojo - most apps in the app store are very cagey about this. Except one which appears to be the default and only option.
  • Later on I want it to be able to display geeky shit like sampling frequencies etc.

I cloned the project from GitHub, fired it up, and it has a few tunes in, and it plays them. Superb! They are indexed by genre only. Where the hell is it finding these tunes? I can’t find any embedded mp3 files etc. It turns out that its terribly clever, and has the concept of music being provided from different sources, not just local files. The sole implementation retrieves some JSON from a server somewhere (looks like the Android Auto API server) which in turn references a few mp3 files on YouTube. It basically passes the URIs of these files to the music playing subsystem, which does the rest.

So the first challenge is to get files from the local storage.

I plonked a few files in the storage of an emulated Nexus 5, using the Android Device Monitor.

Android does a good job of indexing all these files for you, and you query the media store in a similar manner to querying a relational db - you get cursors and projections and columns and all that good stuff.

I won’t bore you with the pain of getting the “please may I have permission to read from your phone”. And I’ve mostly forgotten what I did.

Querying for the genre was strange, since the column was defined as not being used. It turns out that each file can have multiple genres (of course, since Dread Zeppelin are both Rock and Reggae), so once you’ve got your file you have to do another query to get the genres for that file.

Anyhow, after two morning’s work I managed to get it to play a single file from local storage. There are loads of things that don’t work, but that’s kind of the nature of software.

At this point I flailed around with libraries and gradle build files for two solid hours before I realised I didn’t have any do-able concrete aims, and this project needed a bit of rigour if it was going to advance at all.

So basically I’ve turned it in a job - organising it as a one-man scrum team, with me being product owner, scrum master and code monkey. I’ve got a basic prioritised backlog of stories which I’m sure will fill out very quickly if I continue in this vein. I haven’t bothered with estimation - it’ll take as long as it takes, and currently I don’t have a concept of a sprint. Given that the only person I’m delivering to is myself, I think sprints will basically be a couple of stories until I’m happy that whatever I’ve done is sufficiently polished.

4 Likes

Story 1: I want to be able to browse songs by Album Artist (as opposed to just by genre).
Estimate: One meeeeellllion story points

I found where it’s squirelling away the music data that I’ve got from the onboard media store - everything is hard-coded to getting a map, with genres as a key and values being lists of songs.

Cue vigorous cut & paste to duplicate the functionality but for album artists.

I have a suspicion that I’ll be wanting to maintain all this very differently as the number of ways of browsing increases, and I want to categorise things by album instead of just a flat list of songs, but that’s for the future.

Fire it up!

Biotchin!

Only the album artists are appearing under the genres menu entries, and what happened to “Various” for the songs from “Sound Of The Suburbs”?

Bollocks.

If only i knew what it all means.

2 Likes

Problem 1 was unsurprisingly cut & paste. After some refuctoring the album artists turn up under album artists.

Problem 2 was me shovelling files on via the emulator while the phone was up. A bounce cured it.

Now works as desired …

Added something to the backlog to re-run the media scanner in the background.
That’s me done for the day.

I had a vague plan to create an android app as a learning experience. Then realised I simply couldn’t be arsed. Well done for bothering!

1 Like

me likes this thread

More of a technical task today.

The next actual user story is to be able to browse by album rather than a flat list of songs i.e. once I’ve selected an album artist or a genre, I want to click through and see albums, and then drill further into songs in those albums.

This is going to require some major refactoring of the existing code, if not an almost total rewrite.

I’m used to “refactoring fearlessly” but this usually entails having a base state in source control to which I can revery if / when I cock up or hit a dead end. At the moment I don’t have the safety net of proper source control.

So the work at hand is to rip out all extraneous crud that I don’t want, like wearable, auto and TV support. Rename packages etc. Then get what’s left uploaded to github.

On first blush the TV support seems a particular fudge - it’s a giant special case as opposed to simply setting a flag here and there.

So, bombs away. This needs to be done sooner rather than later anyway, but I suspect it’s going to take a lot of manual fiddling to rename projects and so on.

Well that was a bit of a struggle.

Cleared out all the cruft.
Added everything to my own local git repo.
Then set to basically rebuilding the whole guts of the thing to be

| Giant bucket | | |
| | Album 1 | |
| | | track a |
| | | track b |
| | Album 2 | |
| | | track c |
| | | track d |

Instead of simply a giant bucket of standalone tracks. This was basically a rewrite of everything non-GUI in the app. Well it had to happen sooner or later.

None of the menu entries make any sense - I think making it look coherent is the next task.

Then sort out album art - I find it difficult to work out if I’m looking at the right thing without the pretty pictures.

I’ll post another screenshot when I’ve got something that doesn’t look like a pool of dog vomit.

Not that anyone’s listening.

3 Likes

I’m listening.:grinning:

Been meaning to get into Android development and have been bemoaning the lack of a decent music player, so keep it up.:+1:

This is a great thread combining uber-nerdy Hi Fi thingo development with geek-tastic computer nerdishness. I do home there will be a button offering the opportunity to delete the AA or repeat the track you like most built into the next version. Save Jon some effort and get you listening to your collection properly. I might add that I don’t have a clue what is going on here, but carry on anyway…

4 Likes

In the final version of the UI the rough plan is to have a “FINAL NUCLEAR ARMAGEDDON” button that occupies half the screen, with Play/Pause being an 8*8 pixel button that moves around the screen like Pacman.

4 Likes

Consider a combined Android Music Player app with built in adult dating based on shared music preferences. And a torch.

“Rated #1 on the App store, would stalk lonely C&W fans again.”

“Dogging, beats & a flashlight”

Sounds like a grime outfit.

Coming to a layby near you soon.:grin:

ftfy

I’ll buy that for a dollar :dizzy_face:

only just spotted this thread.
Hows the App going?

Source control - mercurial is nice and easy to use, free and allows you to branch and switch very easily.
If you want to store things offsite you can hook it up to bitbucket nice and easily too.
There are nice windows integration tools from Tortoisehg which is also free which means no nasty command lining either.
Would give you a nice safety net.

Tragically I got a job, so the project went straight in the bin.

The last thing I want to do after a day coding in Java is more coding in Java.

I might resurrect it when I’m next between jobs, but I think next time I would build from scratch rather than mashing someone else’s app around. It’s probably more work to do the latter than the former.

I’ve only just found this thread, and it died. Everything I touch dies,

Fear not, everything @htm_1968 and I touch falls apart or catches fire. Sometimes both.

3 Likes