Friday, December 1, 2017

3.0 Work in Progress 12: File Browser UI

Next up on the new UI list is the file/folder browser.  I also rewrote the file/playlist handling on the backend to be much more streamlined.  A lot used to go on when playing folders and i've greatly simplified that.  As always, the file browser will show anything on the file system and does not care if its in the database or not.  This is great for navigating, but caused a lot of issues when a user went to play a file or folder.  I am sure some were familiar with the issue where songs would "disappear" from the queue after reloading GMMP.  This was because the user played a file that was not scanned into the database.  GMMP would play the file fine in the queue, but when the queue was persisted to the database those files were lost.  In 2.x GMMP would try its best to get everything scanned in by running silent scans of folders as you navigate into them.  While being pretty inefficient, it worked for the most part.  The big issue happened when a user would select a folder to be played and that folders contents were not scanned it.  GMMP did a bunch of stuff to account for this, but in the end it was very hacky/ugly and really bloated the codebase.

This time around for 3.0 I came up with a much better approach.  The new UI / data backend has some nice capabilities like auto updating when its backing data in the database changes.  Now when a file is played, GMMP will look to see if its in the db, if not it creates a placeholder on the spot.  The placeholder just contains the filename and a track id which is all that is needed for putting a song in the queue.  If any placeholders were created, gmmp will then run a scan to populate all the placeholders with the information from the tags.  Any UI that was displaying the placeholder will auto refresh and show the tag metadata.  So now there should never be a case where files are lost from the queue on restart.

New UI (I switched up the theme colors just to add some variety to the screenshots)


At the top is the QuickNav which is scrollable horizontally and each folder is clickable to instantly jump back up a few folders (the video below will show this).  Like every other list item, the metadata shown is customizable.  In this screenshot below the first item is a playlist which is just displaying its filename and the items below that are showing the song name and duration.



I plan on adding the ability to highlight the currently playing track (i also think i can add that ability to the library views. I know this is requested often).


Sunday, November 19, 2017

3.0 Work in Progress 11: Bookmarks, Chrome OS, and Permissions

I recently picked up one of the new Google Pixelbooks and I will say it a pretty awesome development device.  It runs Chrome OS, Android, and Linux all at the same time and has pretty good specs (i5 cpu, 8 gb ram, 128 gb ssd) for running Android Studio.  I am able to code and deploy GMMP right on the same device which makes development really convenient when not at home.   Android apps also run in their own window which can be resized which makes UI testing on different size screens super easy.

Ignore the artifacts around the window containing GMMP.  It is a side effect of taking a screenshot i guess (it appears fine on the device)
In order to support the free form resizing of the app window, I updated the target SDK level to 27 (android 8.1).  GMMP 2.x was still on 21 (android 5.0).  The target SDK update should see some performance improvement in newer devices (although i do not know by how much).  I also added support for the android permission system they added back in 5.1.  GMMP should only ask for storage permission and possibly phone state permission (if you want to use the auto resume after a phone call finishes feature).


Anyway, the main focus of WIP 11 is bookmarks.  In the process of refactoring / rewriting the MusicService, I rewrote the Bookmarker and added a UI to show existing bookmarks.  All of the previous work I spent on creating common, reusable UI components is really paying off.  Adding a functional bookmark list UI only took roughly 15 to 30 minutes.  Similarly the Artist and Genre details UIs I showed in WIP 10 took about the same amount of time.  Since its so quick to add these UIs, I can see myself adding a bunch of optional views for some other fields like year or composer (and making 2 separate UIs for artist / album artist if the user wants to have both easily accessible)


The bookmark list will show all the currently bookmarked tracks and let you play them directly from the list (or delete them).  Like every other view i've shown in 3.0 so far, the metadata will be customizable.  For this post I just had the list items show song name and bookmarked time.  For the video below I set it up to just auto bookmark everything, but the previous bookmark settings will still be there in 3.0 (auto bookmark based of song length, m4b extension, or by folder). The video will show the song auto bookmarking when changing tracks, and then resuming at the same position when returning to the song.  It also shows the manual bookmarking and unbookmarking of the currently playing song.


My focus next will be creating a folder UI.  The folder UI is a bit more complex than the other UIs (besides maybe now playing) so I imagine its going to take awhile

Sunday, November 5, 2017

3.0 Work in Progress 10: Multiple Artists and Genres Per Track

In the last few weeks I've been mostly doing backend work so there arent too many UI changes to show off.  The music service refactor / rewrite has caused me to rewrite a few of the other backend systems (and there will probably be a bunch more that need it to).  Since I was already making so many changes to the data access layer, I decided now would be the best time to basically clean up the whole data model and make the necessary changes to support some of the highest requested features like supporting multiple artists and multiple genres.  These changes led me to rewrite the scanner entirely (I had to do it anyway due to the data access layer changes).  Now the scanner will recognize artists and genres that are delimited by a specific character (";" by default) and set them up in the database accordingly.  Since fields with the ";" in it are a bit ugly.. i do plan on adding some functionality to replace that with "and" or "&" or really whatever phrase you want when displaying the song in now playing / notifications / etc.  That hasnt been implemented yet so these screenshots will show the delimiter. 

In order to show this in app, I quickly coded up a artist and genre details UI.  The plan is to show some sort of artist / genre image at the top similar to the album details view.  Right now its just a solid color background.

Properties of the test file with multiple artists and genres
Song in app






As you might have guessed, there wont be an alpha version ready to test anytime this year.  My first child is expected to be born in a few weeks so it is unclear how much dev time I will be getting in the near future, but I will try my best to continue the WIP posts and get something testable in the early 2018 time frame (hopefully)

Saturday, October 14, 2017

3.0 Work in Progress 9: Shuffle and Notifications

The last update I showed off the new queue ui which did involve a complete rewrite of the underlying queue backend code.  Due to that and switching to the new data model (Room-based), I ended up taking the plunge and rewriting the MusicService.  It seemed like a waste to try to hack it up to use all the new stuff I added when I eventually planned on rewriting it anyway.  Due to that I dont have too much to show UI wise, but I did make some queue improvements and redid how shuffle works.

One of the largest complaints I've gotten over the years was the inability to skip back/forward while shuffled and get a consistent track order.  Once you skipped back, the next track would be chosen at random.  My response was always that I understood the frustration but without rewriting shuffle / music service entirely there was not much i could do.  Since I am rewriting the music service and queue, this seemed like the perfect opportunity to fix this issue.

In the video below, it shows off the new shuffle queue.  It essentially works like the "randomize" option in the queue.  Turning it on will put your current playing song at position 1 and shuffle the order of the rest.  Pressing next track will simply just go to the next track in the queue.  This allows you to go back and forth and maintain the same order.  This also greatly simplifies the code on the backend.  Next track doesnt care if its in shuffle or not.. it just goes to the next track listed in the queue.  When shuffle is turned off it will return to the previous order.  Any new tracks added while in shuffle will just be placed at the end when shuffle is turned off.  Note: For this video and testing i added a shuffle button to the min player at the bottom.  This was just so i could keep the queue up and change the mode back and forth.



Notifications were managed by the MusicService, so I gave them a rewrite as well.  Google has added a lot API since I originally created these notifications, so this time around I will just leverage what they provide instead of doing a custom view for it.  These newer notification apis will also allow album art to play on your lockscreen on devices that it didnt work before (most phones would already show the album art on the lockscreen but a select few would not). 

Plans for the notifications will be 5 customizable button slots (most likely just the common actions like next / prev / play/pause / exit / toggle shuffle) and 2 (maybe 3?) metadata lines that are customizable like the other metadata views I've shown in previous updates.  The images below just show off the standard next play/pause and prev buttons.

Lineage OS 7.1.2
Lineage OS 7.1.2
Galaxy S5 running 6.0.1

Friday, September 22, 2017

3.0 Work in Progress 8: Queue

Its been awhile since I've posted a new update but I spent a few weeks working on 2.2.4/2.2.5 and now I am back working on 3.0.  This next update focuses on the queue.  Its not finished but it is working enough that I can show it off.

The queue involved a bunch more work than the previous views since I had to rewrite the actual backing queue data structure.  Previously the Queue class would retain its own copy of the tracks and it was in charge of persisting all changes into the database.  This time around I made it much simpler by just keeping everything straight in the database, so the queue and db no longer have to stay in sync.

The queue features drag and drop like the previous version of gmmp, however it is done a bit differently (at least for now pending feedback).  Instead of having the "handle" on the left on each list item that you press to start dragging, dragging is now started via a long press.  The reasoning behind the behavior.. honestly.. is the drag and drop helper class that google provides works this way https://developer.android.com/reference/android/support/v7/widget/helper/ItemTouchHelper.html .  I didnt see any reason to reinvent the wheel.  Also deleting can be done via swiping left.


Due to the swipe left to delete, I have chosen to not make the Queue available to be placed as one of the library tabs.  However, the queue will be accessible straight from now playing via the FAB (this is shown in the video), and via the side navigation drawer.  I originally had the queue in as a tab and it was too unreliable trying to delete.  Half the time it would just scroll over to the next tab.

Just like all the other views, the metadata displayed in the queue will be customizable.  I also improved the metadata views quite a bit by adding the ability to define how much space each "slot/alignment" takes up (see WIP 1 for details).   This allows for something like the image above.  The song title and artist will take up 80% of the view and the track duration only takes up 20%.  Below is the code that represents the queue list item:

 var metadataLinesModel = MetadataLinesModel(GMThemeEngine.getInstance(context).currentTheme).apply {  
       addMetadataLine(arrayOf("<weight=0.8><align=left><typeface=sans-serif><size=16>%ps%. %tr%", "<weight=0.2><align=right><typeface=sans-serif><size=16>%du%" ))  
       addMetadataLine("<color=2><align=left><typeface=sans-serif><size=14>%ar%")  
     }  


Here is the video of the queue in action


Wednesday, August 30, 2017

2.2.4

I was finally able to work out some of the sdcard write issues.  I could only reproduce issues when creating playlists, so hopefully that was the only problem.  I also tested with android O (the emulator) and didnt experience any issues, so GMMP should be good to go for 8.0

2.2.4 (08/29/2017):
-Updated google services to 11.0.4
-Updated support libraries to 26.0.0
-Updated compile sdk to Android O
-Fixed bug where keyboard would not show when using a gesture to jump to search
-Play next/prev album now orders by album name instead of by artist (use next/prev album by artist for other behavior)
-Reset anything set to next/prev album to next/prev album by artist
-Notification will now properly update state when queue completes with on queue completion set to default or stop
-Audio focus is now only abandoned when the music service is destroyed
-Fixed audioengine startup race condition deadlock
-Fixed creating new files on sdcard (playlists / downloaded album art)
-Fixed issue where some m4a files would play at the incorrect sample rate

2.2.3 (05/02/2017):
-Update google services to 10.2.4
-Fixed some audioengine crashes
-Fixed other various crashes and bugs