As I’m sure lots of you have heard there have been rumours of VLC for OSX being deprecated because of the lack of active developers for it. On hearing this and both having recently learnt Objective-C and being quite a hardcore user of VLC (I use it to play fullscreen videos on my second monitor while working) I felt that I might be able to jump in and help out. I know I won’t make any groundbreaking changes but it would be nice to give back something to a product that gives to me.
So I trundled off to the VLC main page to try and get some more information about what is the current state of the project and how I could get involved with the OSX side of things. While looking around the sight I seemed to almost stumble upon this github project. Huzzah! you might be thinking but still no contact information of who to talk to about the project, where I can get more information on it or even what needs doing next! After a quick glance over the codebase, a quick run of Clang static analyser and I’ve found and very quickly patched a potential memory leak – obviously I’d like to get some more information so that I can start actually contributing to the project though, well that is if I end up having enough time between my 101 other projects…
Although thats an awfully complex title to say fast 10 times its also my solution to a problem that I’ve been having with SQLite databases on the iPhone.
While developing both TEC and Tagger (yes thats my highly unimaginative name for my dissertation app) I keep running into threading issues with the SQLite database I use to store all the data. This is partly because of my use of many threads to keep the UI fast and useable. Because of these many threads there is occasionally a collision between the normal getting the details of the local area from a MAC address and the adding of a new location or a background database update. This is a problem that could be solved in a few ways – first checking that we aren’t running a database update when we request location details or, my preferred option, a queue.
The good thing is in Objective-C there is a built in queue class that can either process things sequentially or in parallel based on the free resources of the computer. In this sense it’s actually possible to think of it as a higher level abstraction of the Grand Central Dispatch found in Snow Leopard but the real beauty of this class is that its available on the iPhone. This means that I can now add all the queries I want to perform to a queue and then when the previous one has finished it’ll automatically start on the next one. Bliss.
Well this is all well and good but to do this you need to make the SQL query into a task that is completed and this is the bit that isn’t so easy. With an insert method that requires no feedback it really is as simple as creating a NSInvocationOperation object with the insert query and data then adding that to the queue but what if you actually want to get data back out? Turns out that you should be able to grab the result of an NSInvocationOperation when it has finished processing but if I’ve called this from another thread it quickly becomes problematic. So to solve this new problem I turned to properties and good old NSNotifications.
Simply put I place the data pulled from the database in a property in the DatabaseManager instance (its a singleton so its always the same…) then send out an NSNotification which is picked up by the class that is expecting it, in this case the Tags class and then it copies from the DatabaseManager property to a local variable. Its not the most elegant way of solving this but it works and after all that’s all that ultimately matters!