Month: <span>February 2014</span>

Published February 28, 2014 by

Bookmark Browser revisit

It’s been over a year since I last touched my bookmark browser, and it needed some attention. There were a couple of outstanding bugs to deal with, plus it seemed like a good time to update the various libraries it uses.

One bug that occasionally cropped up is logging in for the first time and changing to the bookmark page, but having nothing show up. If I did a full refresh of the page then everything would be fine. I never quite figured out what was going on, until now. I assumed there was something I wasn’t doing right with Knockout, so I tried moving the code that does the bindings from the PageBeforeShow event for the bookmark page to right after the AJAX call that gets the data. But that didn’t help. Turns out it was something simple: the bookmark container is initially hidden, and I was never showing it after the first successful login, assuming the app was started in a logged-out state. The solution was showing the container right after the bindings were applied.

And speaking of content not showing right, it suddenly became necessary to add an explicit jQuery Mobile refresh call on the list that holds the bookmark data, like this:

$("#bmMain").listview("refresh");

Without such a call none of the jQuery Mobile styles would be applied unless I did a full page refresh. Not sure why, but whatever. The latest version did resolve a weird style issue with the bookmark menu list showing a double border around each list item, so that’s good.

jQuery jQuery Mobile KnockoutJS

Published February 18, 2014 by

Music Browser Part 1 – Intro

This is part 1 in a series of posts about creating a mobile web app for browsing music databases.

In my continuing quest to up my web/mobile game, I decided to build a web app for searching the All Music Guide database. There are a number of music metadata repositories on the web, some robust and some paltry. The one I like the best is run by Rovi (now Tivo) and powers All Music. They had an iOS app that allows you to access all parts of the data store. It was great, but the search portion is not very user friendly and doesn’t always work the way you expect.

My goal was to create a basic search form that allows you to look up an artist, album, or song title. The native app had an all-in-one search feature where it tried to dynamically show you results for what it thought you were looking for, but it often failed to return what I wanted. I understand the ease and utility of having a single field for different types of information, but I wanted to run specific searches.

The first step was creating an API that would essentially wrap the calls to Rovi’s RESTful API. I didn’t want to interface directly with Rovi for several reasons: to allow the results to be formatted differently if I wanted, to make it easier to switch to a different data store in the future, and so I wouldn’t have to allow cross-origin requests. I went with the standard Web API project in Visual Studio 2013.

Getting the routing to work properly was the only real hurdle with the API. The default Visual Studio template sets up routes that include /api/<controller>. But I just wanted /api and not the <controller> part. It’s tricky because the base controller class is ApiController. The MVC convention is controller class names are of the form <my_ctl_name>Controller and then my_ctl_name becomes part of your route. Having my own class called ApiController wasn’t possible, so I called it SiteApiController. But how to tell all requests to use that controller? Enter WebApiConfig.

I removed all the default routes and added two new ones: one for searching and one for lookups. I was able to specify the exact controller class and a route template that only included /api and not a controller designation. Bonus points to Microsoft for allowing lots of route configuration options.

Even though I only needed to make single, synchronous requests to Rovi, I used HttpClient to do it. There might be a need in the future to make multiple simultaneous requests to build a query result, if so it will be easy to make them asynchronous. The next step was the front end.

ASP.NET Web API C#