soledad penadés » javascript

London-New York (and back), via Hong Kong, Macau, Tokyo and San Francisco

sole — Sun, 29 Jan 2012 23:03:40 +0000

The sketch book I mentioned a couple weeks ago has finally been released! To recap (just in case you accidentally ended here and have no context), it is a travel sketchbook depicting our experiences while travelling around the world these past April and May.

I’ve finally settled on building a simple HTML(5) page with a sprinkle of Javascript to navigate the bigger images. Something that gets the job done, which is showing you my crazy sketches!

I might possibly build a Kindle version in the near future, so if you’re a Kindle user, stay tuned ;-)

In the meantime you can read a bit about the background and the “tools” in the project page.

Some notes from Google DevFest Barcelona 2011

sole — Thu, 10 Nov 2011 16:32:14 +0000

I thought I wouldn’t make it to the place. Barcelona’s metro system is still pretty much unknown to me and it’s hard to find navigational help using the official web from the transport entity. Maps are confusing (we need a Beck!). A shame, but I finally did it, after walking the same loooong underground exchange that Fuzzion guys used for recording their famous kukka:r0kasit7e!aarku demo. I arrived a tad late, but I did it! Yay! :-)

And while most of the attendees brought their laptops, I went oldschool and brought a trusty notepad and a ballpen to jot down whatever caught my attention.

First in the morning was the HTML session. I didn’t write anything down about this one, since I was concentrated on looking at the stuff Paul Kinlan was showing. I knew about most of the stuff he talked about, but it was a nice reminder. It was cool that the slides were interactive themselves, so he could demonstrate things without getting out of the “slides environment”. Then went Mr.doob and his short GLSL + WebGL talk. I think it was too short for the topic! Anyway, people were quite impressed with the patterns one could generate by writing a shader, and since he’s released an improved version of the interactive GLSL sandbox tool he used, you can now experiment in the same way he did! :-)

Then came the break time and I got talking and after that I sadly missed much of the talk about Google+ from Ade Oshineye, confiding that I would be able to catch up later on by looking at the docs :-P

I entered the conference area again for the Android sessions with Bruno Oliveira. I was quite interested in hearing what they had to say, after the recent “events”: 4.0 announced, the Android git repo being taken down, the (in)famous fragmentation chart, etc…

… and what I heard was a bit disappointing. It seems to me there’s a fundamental disconnection between what Android developers want and what Google/Android has to offer. It was very obvious when questions time arrived and most of the attendees were asking questions about monetising the apps (or in other words, being able to recover the investment on the platform), and pretty much all Bruno had to answer was that Android intended to be a democratic platform, focused on what the user wants, and not forcing them to do something like entering credit card information when turning on the device for the first time. He also added that Android wasn’t targeted to any specific income range as other platforms do.

When asked about “fragmentation” he said that:

[...] diversity is a feature of the platform, is not really fragmentation. Different operating system versions [...] is what people call fragmentation [...]
It’s a consequence of being open source [...] we don’t want to put pressure on manufacturers. Maybe in a friendly way, releasing cool inspiring phones like the Nexus S, etc… [...]

He was also asked about the agreement between Android and manufacturers regarding updates that was announced and widely discussed on past Google I/O, but after digressing for a while he didn’t give any definite statement on that matter.

Then he went on to give some advice on how to make great apps, suggesting we should detect the available features on each device and act accordingly, activating or deactivating features in our apps, because not being compatible with a certain phone is being arrogant, like saying to the user that he bought the wrong phone.

This is something that particularly irks me, as sometimes there’s no written specification that app developers can consult and be confident will be followed to the letter, as each phone diverges a lot on its behaviour. It’s impossible to know in advance what will happen unless you test it with the real phone. Yes, there’s the emulator, and that famous esoteric compatibility suite that a phone must passed in order to have the Google apps (Market, Gmail…) installed, but that doesn’t guarantee that a real phone will have a proper, complete GL ES implementation, for example.

So making that type of statements did actually sound wildly arrogant on his side. And he went on, happily adding there wasn’t no excuse for not creating all the different versions of resources for all the different screen sizes and densities. This was followed by a general moaning and mumbling in the public, as with each new release of the SDK not only are there new features that need to be used if you want a “cool app” that uses the latest stuff in new phones, but there are also new resources to be created and maintained, thus increasing the complexity required to build something “great” for Android versions ≤ X.

Something else that really worries/annoys me is the insistence in showing raw activation and installation numbers in every presentation they do. It doesn’t make much sense on the long term: I have probably activated four devices but that doesn’t mean I use all of them (as I use them for testing), or that I am four different potential users. Another use case: people using carrier-subsidised phones change them quite often, but that doesn’t mean a new user is created from void each time a new phone is activated. It’s still the same user and he’s not going to expand the market–it actually stays the same, as the old phone will probably get thrown in a drawer. Same goes for installation numbers: that you install an application doesn’t mean you actually use or keep it on your device. They could show uninstallation numbers too, and the ratio between installs and uninstalls would be a way better indicator (but probably not as attractive).

Moving on, it was lunch time, which we used to discuss the above points. Most people dismissed Bruno’s compatibility strategy as it’s plain unrealistic (unless you have an infinite number of testing resources, or simply build very basic and unexciting apps). Some jokes were made about the fragmentation “feature”: it’s not a defective phone, it’s a feature!.

After lunch we got Paul Kinlan again, explaining several strategies for “making a business out of apps”. Again he relied massively on AdSense, which has proven to be a very unreliable and arbitrary source of income. He also mentioned the Chrome Webstore, of course, but it’s not very widely extended yet. This session wasn’t as enlightening as the HTML session, as the concepts weren’t new and … well, you can imagine the rest.

Next was Danny Hermes with an strange session on the Shopping API. He sounded slightly apologetic and felt like out of place since there wasn’t even a “Shopping” icon on the banner, whereas there were G+, Android and Chrome icons, but at least was really enthusiastic about his topic. I guess this talk could be interesting for people integrating Google’s Product Search with online shops, but this is not something I’m currently interested at so I didn’t pay much attention.

Sam Dutton’s Chrome Dev Tools session was way more interesting. It was funny that we were commenting: it would be cool if you could save the changes you do live… And then he said: here’s this new feature: now you can save the changes you made to the document!.

It also made me slightly envious: the Chrome developer tools are an amazing platform for developing, and the Android toolset pales in comparison. It’s all “hacks” here and there: a separate app for tracing, another one for viewing the layout, an app for debugging… Seems like Google should invest more in the Android team ;-)

It was time for “snacks” again. I had a coffee, thanks to the help of @thespite which showed me how to use a Nespresso machine. Yes, I had never used one before–I’m a slow-food sort of person and generally use a french coffee maker instead ;-)

And finally it was time for more Ade Oshineye talks, this time on the Google+ Hangouts API, but for some reason (saturation?) my brain squarely refused to pay attention. I’m so sorry Ade! See, if the talks had been recorded I might be able to watch them ;-)

After the talk finished, it was “Pitch your app” time, where several attendees tried to convince us that their app was the best ever. The best demonstration got a voucher redeemable for a Nexus S, since the phone is not available for sale yet. I was nicely surprised by the level of English demonstrated by the guys pitching the app. They still have a lot of Spanish accent but they aren’t kicking the grammar like a punch bag every two words, and that’s something you can’t say about most mono-English speakers! So well done on that front!

Regarding the apps, I was a bit less impressed, as most of them weren’t really surprising: weather aggregation services, GPS tracking+Maps, cloud CMS integration, a football game, a chess game, bike rental locations aggregation/visualisation… nothing that got me enthusiastic about :-P

What did surprise me in fact was that one of the pitchers connected his laptop to the projector and I could see how he opened a terminal and wrote “pm-suspend” prior to disconnecting the computer from the projector. Now that is hardcore! Who needs widgets to suspend the computer? A terminal is all you need! \o/

So to sum up, it was quite an event-packed day, quite professionally organised. Thanks and well done, Google! It not only provide me with some new ideas and tricks, but it also got me thinking about the true Google strategy on Android. Unfortunately the post was getting too long, and that discourse seemed slightly out of place, so I cut that part out and will refine and publish it in the near future as a separate post.

Here’s hoping there’ll be a future DevFest BCN 2012! :-)

Macabre Pool

sole — Mon, 31 Oct 2011 17:49:04 +0000

This is the result of my fascination with skeletons* and me wanting to learn about Box2D in Javascript.

Since everything is randomised, you might get two big skeletons or a big one and a small one, or two small ones. They sometimes look like they are alive, with spasms and all, while they jump around the screen with the head in their hands. It’s very creepy.

Try it if you dare!

Box2DWeb is quite funny; I should do more stuff with it. I had tried to learn Box2D.js before, without success, but this time I stumbled upon Seth Ladd’s series of brilliant Box2DWeb tutorials, and you can deduct the rest.

The graphics are SVG based. I drew them all with Inkscape. I then use CanVG for loading SVGs into Canvas (everything is rendered into a big Canvas), as there isn’t a native SVG method for getting a bitmap from a rendered SVG object. Mr.doob suggests using SVG directly instead of going through canvas, because it might be faster. I guess I’ll try that with something else; for now I’m just rendering to bitmap/canvas once, so it’s a relatively low overhead. I also cache the SVG to Canvas results, so even if you request the same asset several times it won’t be read and regenerated each time.

Finally I also used a couple of web fonts and some CSS 3 stuff such as box and text shadows, which can be finally used without -moz or -webkit prefixes (at least with Chromium 15 and Firefox 7). Pretty cool!

And of course a huge source of inspiration was Mr.doob’s Ball Pool!

* Proof and proof of my skeleton-mania.

HTML5′s custom attributes minigotcha

sole — Sun, 16 Oct 2011 19:29:27 +0000

I was trying to set a Javascript Object as the value for a custom attribute, but I was just getting “[Object object]” as the value when reading it back. This is actually the toString() version of my object, and was also my ‘fault’ for not reading the specs (or for daring to attempt something risky!), as the custom attributes can only contain strings:

element . dataset
Returns a DOMStringMap object for the element’s data-* attributes.

(# source)

[...] The custom data attributes is transformed to a key for the DOMStringMap entry [...]

(# source)

Or more specifically, only ‘DOMStrings’ are allowed.

File upload & drag and drop with HTML5

sole — Mon, 08 Nov 2010 17:40:44 +0000

My use case: I want to drag a file from my local filesystem and drop it into a web page. Then I want to do stuff with the data in the file.

This wasn’t possible until recently, but thanks to HTML5 we can do this natively, without using external plug-ins. Yay!

First thing is to make an HTML element draggable. In practice, this means adding two event listeners to it that, in turn, cancel the event. In my case, I want to make the entire web page the “target” of the dragging, so I’ll add these listeners to the window object:

var cancel = function(event) {

        if(event.preventDefault) {

                event.preventDefault();

        }

        return false;

}

window.addEventListener('dragover', cancel, false);

window.addEventListener('dragenter', cancel, false);

As you see, first we declare a cancel function, then use it as the event handler for both dragover and dragenter events.

Now we need to add a listener for the drop event. Again, we add it to the window object:

window.addEventListener('drop', function(event) {

        var files = event.dataTransfer.files;

        if(files.length == 1) {

                var file = files[0];

                var reader = new FileReader();

                reader.onerror = function(e) {

                        switch(e.target.error.code) {

                                case e.target.error.NOT_FOUND_ERR:

                                        console.log("file not found");

                                        break;

                                case e.target.error.NOT_READABLE_ERR:

                                        console.log("file not readable");

                                        break;

                                case e.target.error.ABORT_ERR:

                                        console.log("aborted");

                                        break;

                                default:

                                        console.log('generic error?');

                        }

                }

                reader.onload = (function(theFile) {

                        return function(e) {

                                var file_contents = e.target.result;

                                do_stuff(file_contents);

                        };

                })(file);



                reader.readAsText(file);

        }

}, false);

Let’s go through the code.

First we look at event.dataTransfer.files. This will contain a representation of the files that have been dropped into the browser window. Since I want to accept exactly one file only, I check for the length of the files property. If it’s not 1, nothing else happens.

And if it is, we create a FileReader, which is a nifty Javascript object that takes care of asynchronously loading the file. We need to define at least the onload event for the FileReader, since that gets called when our file is ready for consumption. We can also define the onerror event, just in case things go awry.

The onerror handler is quite simple conceptually –it simply dumps an error to the console.

The onload handler is a bit more elaborated: we use a function which returns a function which is finally the handler. This might seem overly complicated, but the explanation is that this code can be extended to handle more than one file, and in that case you definitely need this closure-style of function, or otherwise the function will get bound to the wrong argument. The way it is now, onload is finally this:

function(file) {

        var file_contents = file.target.result;

        do_stuff(file_contents);

}

… and that’s because that “(file);” at the end of the “(function {} )” block makes it execute in place :)

If you’re confused, don’t worry. Just re-read everything carefully.

Finally, we just tell the reader to read the file contents plain text. As I said before, this is an asynchronous process, so we don’t get the result instantly. Instead, we get it in the onload handler.

It’s important to understand this, specially if you come from a background of traditional sequential programming, where you would have expected something like this instead:

$file_contents = file_get_contents('filename.txt');

and would have the results immediately in $file_contents, once the read is done. It would also be blocking, i.e. your script would get stuck in file_get_contents until everything is read.

THE Gotcha

You will never get the contents of the dragged file if you’re working with a local page (i.e. the url starts with file:///). Never. This was driving me insane, until I decided to implement the onerror handler, and got a NOT_READABLE_ERR error. That helped me track the error to this bug, but still… I didn’t find it mentioned anywhere else.

So when developing you’ll need to use a local server, and access your code from within it (e.g. http://localhost/test/draganddrop.html). Not that it’s complicated to get a working local web server nowadays, but it’s something to take into account.

Note: Mr.doob has told me about a command line option for enabling local file access with Chrome:

--allow-file-access-from-files

You need to modify your launcher or whatever you use to launch Chrome, so that it uses that flag. E.g.

chrome --allow-file-access-from-files

An example?

I used this technique (and pretty much all the sample codes are taken from there without modification) in my KML to DDMS tool. The code is not obfuscated, so you might want to take a look at it :-)