If your using jPlayer and your doing something like this:
($jplayer
.jPlayer('clearMedia')
.jPlayer('setMedia', {
mp3: '/some.mp3'
})
.jPlayer('play')
);
... and maybe you've looked at the android logs and seen "Attempt to call getDuration without a valid mediaplayer". The problem is the 'play' command. You should move the play command to an event.
I've been toying with this idea and I can't say I've seen it before... it goes a little something like this:
Take this blog ( I didn't write the software obviously but thats beside the point ), there is the page chrome ( the stuff around the edges ) and the content. The content consists of a bunch of ( uninteresting ) blog posts.
The page chrome isnt overly interesting... its exactly the same for every page you view - and its sent every time you view any page. Sounds bad to me! Plus for mobile users we probably dont even need half the chrome. We might want a little header or someting but not all the sidebars and whatever. Now you could say "media queries!" but that doesnt stop useless HTML being sent to the browser.
The blog posts themselves can obviously cached as well. Once we've seen them (or at least the browser has) we really don't need to fetch them again unless they updated for some reason.
( If I'd thought this through a bit better I would of used a different example now... ) If this was some sort of web app we'd also have a bunch of JS that would be loaded... but we don't... but imagine we do.
So I see a lot of waste here to show a page of this blog. I dont need the chrome, its probably not changed. I dont need the (imaginary) JS code, its probably not changed. I dont need the posts we've already seen - they probably haven't changed... Urrrm... we probably do want to see if there any new posts! So you can see there is quite a lot of waste going on here.
The classic method of optimising your HTML page is to heavily cache CSS ( oh i forget CSS! ), JS and images. The best way to do this in my opinion is use some sort of revisioned URL's. For example /img/r12345/foo.png. You can grab the revision from your repo in your build scripts or just use a hash or whatever and shove it in the url in your HTML/CSS/JS so that links reference a specific version of the file. That file will have headers to never ever ever expire. When you update your HTML/CSS/JS with a new URL the browser will refetch the resource. Its absolutly the best because the browser will never attempt to refetch a resource. What if we could take this idea a little further...
I'm a massive fan of what I call JS templates - essentialy any form of client side templates. These are great. They mean you send a load of JSON to the browser and it can render HTML client side ( because we all know heavy DOM manipulation to create/update/delete DOM elements is a sin right? ). And plus im always polling or doing websockets or something to pull in new data and then I need the templates client side anyway. So what if we use client side templates to render the page chrome...? "What? Why?" your saying I would think. Well one reason is because in the client you can check the environment your running in a whole lot better than guessing by looking at the UA on the server.
I'm going to stop talking now and show some code:
index.html:
<html><head>
<meta name="viewport" content="width=device-width" />
<script src="/js/r12345/main.js"></script>
<body></body></html>
main.js:
var handheld = window.matchMedia('only screen and (max-device-width: 480px)').matches;
if( handheld ) {
some_module_loader.require([...JS/templates/CSS required for mobiles ...]);
} else {
some_module_loader.require([...JS/templates/CSS required for desktops ...]);
}
So we've sent the browser a single index file. It just loads a single versioned JS script which in turn loads a bunch more versioned URLs that are specific to the device its running on. We can now perfectly tailor the experience to the device. Also new versions of files will only be downloaded when they change.
The downside is, if you were visiting this blog, we'd request once our tiny HTML file and then you'd need one more request to check there were no new blog posts. This may or may not be a problem depending on what your doing. It would be kind of bad for a blog but for an email app it wouldnt be too bad. ( I'm currently having wild ideas about cookies sending the last blog post they saw in the initial request which would then mean you could send in the HTML file a list of new blog posts too... not quite thought that through... ). The upside to this techique is of course incredibly small requests. I have absolutely no profiling data to show for this idea - but it does sound pretty good!
So has anyone done this? Is it stupid? Tell me!
Blimey.. over a yea since the last post! Definatly time for a new one... Well what have I been doing in all this time? Mostly getting excited about Javascript! I'm now addicted to NodeJS and generally only want to write things in javascript. My day job is still 50% python ( tho it gets lower with each passing hour ) and I still like python as a language, but Javascript is where my interests are at.
I find the Browser world incredibly exciting these days, it moves so fast and I dont like getting bored! The new stuff coming out of Mozilla is fantastic. With fantastic browsers we need fantastic servers and NodeJS fills that hole perfectly. Gone are the days when I could write a Pylons/WSGI app off the top of my head, now I fire up npm, install express and away I go.
But what have I actually been doing with any of it? Well I blogged (all that time ago) about the "XUL Challenge" - could I convert entirely to using the browser for all my apps. In retrospect I meant "browser" not really XUL... In closing I wrote "I would find it most amusing to run firefox in my .xinit and have no window manager... we shall see." Well we have seen, Mozilla saw too, now they are making B2G (Boot 2 Gecko). Sounds perfect to me!
I did for a while play around with the idea of trying to make a window manager again. I was thinking you could redirect windows to offscreen bitmaps, send those to a browser somehow and draw them in canvas elements, scripting the whole lot with javascript. You'd have easy scripting via javascript and themeing via css. While I still like the idea the concept of a window manager doest really seem as usefull to me anymore. Everything is just tabs these days. I have firefox on one desktop with a bunch of app tabs, irssi with a bunch of windows (that look pretty much like tabs), more terminals for projects - all tabbed... I dont need to be managing windows! Everything runs full screen with a row of tabs at the top. Heck - the window manager I use at the moment (awesome) even has what could be called tabs at the top of the screen for switching desktops and apps. Anyway... the window manager ideas are basically out.
My next stream of ideas was for shells, something like bash, that ran in a browser and talked to my local computer somehow ( its all well and good "running in the cloud but first we need to walk on the ground where all our stuff still is! ). I played around with this for a while but didnt really get going until I saw termkit. The philosophy was exactly what I was thinking. This resulted in kuya-shell2. I got it mostly working and was pleased with the result but something wasnt quite right...
The realisation came that I didnt really want to be launching all those linux commands inside my own shell. I didnt want to be writing something that could run cp/mv/df/du/vim/grep/etc, I wanted the shell to implement those itself. I didnt need a way to launch processes, all I needed was a way to manipulate files and directories by talking to a server and I could implement all those things myself. This meant I could change my complicated server that could handle piping command input/output to other commands and doing all sorts of other things to a very simple server CRUD server that listed directories and served files. Yay - KISS for me
So now Im working on, the imaginativly named, kuya-fileserve ( yet to be put on github ). A simple server and browser front end for managing files via the browser. Its ultra clean and slick and packed with HTML5 goodness. The nice part is that the front end can easily be split out to a more generic file browsing app that could be connected to anything you can think of - managing the files on my computer is the priority at the moment but only because all my files are on my computer.
That does still leave me with the problem of seeing a file in a window and not being able to do much with it apart from copying it around or .. urm.. deleting it. As I was pondering the problem I discovered Web Activites / Web Intents. Joy! The perfect fit! If I intend to edit a file, I just tell my browser so and it can offer me a selection of apps to do so! The puzzle is complete. ( In fact the file browsing part could actually become an activity: "I intend to browse this servers files" - server here could mean localhost ).
So thats where I am now, trying to get to grasps with thes activities/intents and browsing files. Its still a fairly new topic but I'm happiest firmly pressed against the bleeding edge!
Thats all for today - hopefully it wont be so long before the next post but I always say that. Iv actually quite enjoyed writing this one and looking back on the last year. I cant really believe all the things Iv learnt this year and whats changed in the world.
See you soon.