Saturday, November 15, 2008

Performance improvements...

One of the reasons that I originally wrote ooTunes was because I was very put off with the poor performance of other alternatives.  I tried DOT.Tunes (it was using 10% of my cpu all the time, and resyncing with my iTunes library took minutes).  I tried slimserver and found that in order to keep the slimserver database in sync with my iTunes library I had to run a 1 hour long sync.  I chose to do this during the night, since it bogged down my computer and made playing music from the library skip and buffer.  I spent a lot of time tacking on additional functionality (like marking songs played when I played them, etc.) but it was obnoxious not to be able to see changes to a playlist for as much as 24 hours.  So, ooTunes was born.  I spent a lot of time writing and optimizing the code that reads the iTunes library.  It now is parsed in under 5 seconds, without freezing up my computer, and that's on a library with 14,000 tracks!  This means, what you see through ooTunes is basically what you have in your iTunes library.  If it isn't, reload  the page, and it will be.  


Well, I spent several of the last few days further increasing the pageload speed.  I found that a lot of the time when refreshing the page (usually re-reading the iTunes library is the biggest part of that, though it only re-reads it if there have been changes since the last read), was spent reading online playlist from mp3tunes and pandora.  Many people don't use these so they wouldn't be seeing the slowdown, but for me, it was taking an extra few seconds each time I reloaded.  So I made changes to do a better job caching those as well.  (the demo will now load about twice as fast as it used to, on a fresh login!)


The other area that I've spent (probably too much) time optimizing in the last few days is the load speed on the iPhone or iPod touch.  I found it a bit frustrating on my large library (granted, I also have a not-yet-released feature of my photo library being loaded, which is something like 2000 more playlists to render) but I still thought it could use some speedup.  So I've reduced the image sizes using some cool compression tools that compress images losslessly, and more importantly, I ditched the dependency on Scriptaculous/prototype on the iPhone!  I seriously regret ever having started using Scriptaculous, it brings in something like 60kb (compressed) of javascript libraries for a few tasks (mostly the drag and drop of songs on playlists, etc. in the regular browser)... and there's no fine grained modularity (no way to say, I only want this feature, give me the bare minimum javascript library!)  So, the iPhone interface now loads in about half as much time as it used to (at least on my own library).  There is still a lot of room for improvement, but I'm pleased with the progress that's been made.


I also made some needed changes to the interface on the iPhone.  No longer do you have to tap 10 times to get a song to play (it's still more than anyone would like but I've reduced it as much as I can, tapping a song once now loads the song and one more time on the quicktime play button and it should begin playing).  Radio stations and movies are even better.  One tap and they are playing!   (the reason is that they don't do back to back playlists so they don't require the little play button to be pushed).  I wish apple would give us some REAL javascript controls for the embedded quicktime player, but it doesn't seem to be top on their priorities.  However, it's much better now that I fixed my own problems.  


Now if only I could have made more progress on MooTunes.  It's coming along but my love for "speed optimizing" just overwhelmed my love of making tons of money!


Also, please send me your suggestions and requests for improvements!  I would have probably never made some of these changes if someone wouldn't have spoken out about it!


Tuesday, November 11, 2008

App store rejects... it's time for change!

In following a thread on the macrumors forums about another app (castcatcher) that was rejected (an update actually) on grounds of using too much bandwidth.  This one maybe is a bit too close to home for me, so it's got me a bit more worried than the "pull my finger" app that didn't make the cut. Is anyone aware of a petition to apple to be more open about their acceptance of apps? (too lazy to google but strangely not lazy enough to not write about this).

It seems that if enough registered developers signed a reasonably written, petition (and had some of the major developers of major indy apps) sign on, they may be able to be heard. My guess is that those with a lot of success are scared to "bite the hand that feeds them" but the uncertainly is extremely demoralizing to a developer. I'm not going to stop developing because of the fear, but it does certainly make me want to hedge my bets and not "risk everything" on the hopes that my apps get accepted into the store. True innovation, however probably does require more of the "risk everything" attitude. It may simply take getting some exposure on the front of a few of the apple news sites, and a few big developers in an "open letter" to bring about some change. Does the NDA override our right to unite and beg for some clearer groundrules? Is there any reason the SDK can't include the same tests that Apple themselves are using to vet applications (if such things truly exist? Things are appearing more subjective these days... and admittedly some have to be judgement calls, but something like bandwidth usage is easily implemented in a test suite).