Once again another update on my Bachelor's Thesis. I tried finishing the search implementation, consisting of both API calls and a decent interface.
Like I stated in my previous post, I'm using @pjv_'s library for managing the API calls to Musescore.com. I already had a good idea about how I'd make the interface, so I first started getting those API calls to work.
@pjv_'s library was a bit difficult to get started with. It uses a MuseScore object which contains everything JSON related, but had a huge constructor and not that much documentation (since it was originally developed just for personal use). Therefore I downloaded and checked the source code Collectionista, the app for which this library was created. After digging trough numerous source files I finally found what I was looking for and based my code for initiating an API call on some code I found in Collectionista.
So, now I had a way to contact the Musescore.com API. I decided to implement the search function before browsing, since search is basically sending a customized query to the API, and parsing the server reply. Since the library I used contained all resulting data in Score objects, it was quite easy to get the results of a query - meaning Title, composer, number of pages of a score, etc. However, all feedback was textual.
I wanted to give the user a quick peek at the scores. As they say, an image speaks more than a thousand words. The Musescore API provides some static links to small generated thumb images of the scores. However, this functionality is not supported in @pjv_'s library. Therefore, I extended his library so that Score objects can also contain a bitmap, meaning that the thumb can be stored in the Score object. The developer himself is responsible for filling this variable, since this image is requested in a second query. Also, it should still be possible to use the library without thumb images. If the functionality to fetch these images was included in a normal query, a lot more of data would be used by the application, even if it doesn't even need the images.
Each score contained in the response by the server is shown in the application, along with the Title, Composer, number of pages, and a thumbnail. These thumbnails are loaded in the background, so on first sight they might show blank, but once they are loaded they are instantly shown. This thumbnail loading is another reason why I decided to store these images in the Score objects. Android deallocates every item in a ListView when it is not visible. Therefore, images would be deleted on scrolling, while others had to be loaded. Upon scrolling back to the top, the bottom ones would be deleted and the first ones would be downloaded again. This created lag because of the constant background threads fetching those thumbnails. By storing the images in the Score objects each image only needs to be fetched once. When fetched, it is stored in the Score object. Therefore, while scrolling these images can be instantly loading without needing to create numerous new threads to fetch these images once again.
The results of a search query are shown in a ListView. As you can see, one can add search parameters. A keyword or a query to search for as well as the instrument the score should be written for. (About the first screenshot, a ListView in Android doesn't show a scrollbar unless interacted with - the list of piano scores on which the keyword Bach applies is substantially higher than 5). What now rests is creating a link between this Activity and the actual meat of the app Activity (which playbacks the files). This can be done by clicking on an item in the ListView, since these are all connected to a Score object which can be used to fetch the corresponding MIDI file from the API.