I have just fixed a bug for the library’s database of the Musical Insitute of the University of Hamburg. The bug was introduced with an update to a new php version on the server side of the university. When solving their issue I also fixed an issue that prevented my Schall & Rauch iPhone app from working correctly. So for everyone who is using the app – it’s back to life!
Happy searching to everyone : )
Schall & Rauch is now available to everyone on the App Store. The Institute for Music Studies of the department of Philology of the University of Hamburg has granted permit to access their databases. What a pleasure!
Schall & Rauch allows you to search in the 3 different music databases of the Schallarchiv, the institute’s library. You can find shelf marks and create local copies of search results as bookmarks. These are then available to you even if you don’t have access to the internet.
The app is free of ads and can be yours for €0.79. Have a look on the App Store: http://itunes.apple.com/de/app/schall-rauch/id392533750?mt=8.
[update] His highness has set the price to free just before christmas 2010.
Schall & Rauch has been approved by the iTunes Store Team.
Yesterday or the day before yesterday I had to reject the EDsync Update‘s binary on iTunesConnect. I was happily playing with the catalog search when I recognised that displaying a search result detail once makes the search always showing this single detail for any selected search result. This mistake has slipped through as I am not testing on the searchresults’ contents but only on certain parameters passed by the interacting objects. Well the bug could be fixed very fast but as I fixed the bug I suddenly felt uncomfortable with the overall architecture of the search. In the binary I sent to Apple there was one class handling a holy lot of things. It was a god class being responsible for displaying the main menu’s items and also responding to delegate methods of UISearchbar and UISearchDisplayController. It is Apple’s intention (see the overview) that a TableViewController will also serve as a searchDisplayController but in my case one class being capable of all these delegate methods is making it too confusing. As a tableView delegate it has to differentiate between being in search mode or in the usual tableView mode each time and for all the delegate methods. This is annoying. The more time I spent separating each functionality to its own class the more I got convinced that I should implement the whole searchUI by myself as I had done it in Schall & Rauch. So this is what it is going to be for now.
Ok, 25%… as I just explained 50% of submitting 2 Apps are already gone. So there is 50% left for Schall & Rauch. Apple has started reviewing it and I am very exited about the results… it’s been at the reviewers hands for 36 hours now :b
As I had to wait for my flight to the testing device I added the Core Data Framework to Schall & Rauch and implemented a new feature, that is to bookmark search results and save them locally to always have them at hand.
After ten days of heavy development Schall und Rauch has reached a state of being ready to be sent to Apple. The following video (it’s flash. Happy Android users. Happy iPhone users – for having an iPhone, not for watching the video) will give you an impression of the application’s capabilities. There are two main tasks left which are writing more unit tests/application tests and integrating iAd (the less time consuming+more comfortable task ;p)
Schall und Rauch Preview
Selection of a database
Entering search text
Displaying the results
Loading additional results
Showing result one result's details
Startet a new iPhone project named Schall & Rauch.
It will be a mobile counterpart of the existing browserbased search for media held in the Schallarchiv library of the University of Hamburg.
The following features are planned so far:
– Search for media
– Bookmarking media and storing it in a favourites list
Work that has been done until now:
– php script that takes library name, searchstring, number of results, fields to search in as parameters, converts the request into a sql query and outputs the results as a xml file. Actually the file is kept in apples .plist format that can be easily read in. I don’t know whether to keep this format or switch to a usual xml and read it in with the NSXmlParser that is available on iOS… will sleep about it another night…