Implementation Story

Started by finalizing the design of the application. We designed the logo of the application in Canva.

We had to maintain a state of the application that can be used by each component of the application so we chose to go with a reactive approach using VueJS to write the application.

Began implementing the design using Electron (JavaScript Framework) to make it run as a desktop application to avail it for Windows, OSX and Linux.

The logical implementation of the application i.e.

• Being able to access and list local files.
• Linking of components that are sharing data.
• Extract metadata from mp3 files.

The application was programmed to search for MP3 files only in the beginning also it was not recursive search. It just gives files that are in the given folder and not its subfolders.

We used jsmediatags to extract metadata from mp3 files although later we made a shift to music-metadata because of the unwanted behavior of jsmediatags in an asynchronous environment.

It became harder to debug the application when using VueJS because the extension that it used is for browsers and we’re using it in our desktop application. So we found an unofficial open-source project which was a command-line tool + a boilerplate to use Vue with Electron, electron-vue. Which was installing the vue-devtools in the desktop application wrapper while starting the application. We started organizing the project in ‘.vue’ instead of plain JS. Which after compilation, it generates a single file for the application which gets rendered in the frame.

The codebase before we started using electron-vue was very bad. So many things written in a single file. Basically, all logic of each component of the application was maintained in a single file and another file was maintaining the global state of the application.

In the development environment, vue-cli used by electron-vue creates a server to serve files for the components and reflects live changes in the files to the rendered components. Which worked as a boon until we were moving designing components from the old codebase, but the code started failing wherever it was accessing local files. It happened because previously there was no intermediary compilation. There was no need to serve the pages or compile it. Electron just accessed the file using the relative path, but now it was being served and every request made by the components for local songs and assets were starting redirecting to http://localhost. Later the code was updated to request on ‘file:///path/to/the/file’ instead of the file but because of the security issues, it was prohibited by Electron. Http protocols can’t request file protocols. Unless the application is in production mode, the files will be served on HTTP protocols. We configured Electron to stop checking for Cross-Origin requests.

Till now, the application was able to look for mp3 files extract their meta data and show it with their album art play/pause songs show 10 recently played songs which updates with sliding animation as the song changes show all songs that it has discovered in the given directory so far. show list of the artists show songs specific to an artist when clicked on artist’s name

It was looking for mp3 files every time when it got launched. Which was not very efficient. We decided to cache the files that were discovered for the first time and use it every time to show songs. Users can refresh the list by clicking on ‘Refresh List’ in settings.

We started writing tests when we were in between the shift from electron to electron-vue which is not yet completed. It is highly unstable which is expected to complete by 14th April. Being able to browse files of the computer in the network was the part of the 2nd sprint which got delayed as the code merger entered the product backlog. How the computers are going to avail their songs is perfectly planned and will get implemented once the backlog is cleared.