javascript


Catching Android’s Back Button in PhoneGap

This little bit of code is going to be useful to those of you developing a “singe page” app inside of PhoneGap. This applies to Sencha Touch (big fan), but doesn’t as much to jQuery mobile and jQTouch, as it’s a multi-page/navigation based event framework (it uses the app’s url string to do things like move around to different link anchors). This is really important on these single page apps because the Android hardware back button will send the PhoneGap app to the background. You need some way to intercept it so you can start building your own history management mechanism. Sounds fun, right? It’s actually not that hard.

On app initialization, add an event listener for Android’s back button, and the callback to handle it. PhoneGap takes care of the interface between Android and your app.

That’s enough to get you started, and it should be pretty apparent if it works or not.

How about history management? It will depend on the app and what makes sense, BUT you’ll probably want to create a history array, and pop off some value that directs the app each time you hit the hardware back button. Here’s another idea: change the destination of the back button depending on the view. I personally like the idea of the latter because apps built on Sencha Touch are going to have easy tie-ins through predefined listeners JS Objects that define screen elements like buttons.




Mobile Platform Detection on the web

I had a use case recently where I need to determine whether the client browser was a desktop/laptop/etc or a mobile device that supports tap events in JS. This will be useful to people who are dynamically binding different events to elements.

You would use it like this




ReadOnly Form Elements

Here’s a quick note for the frustrated:
When setting the readonly parameter on a form element via javascript, make sure you use a capital “O” as follows:
elem = document.getElementById('myInputElement');
elem.readOnly = true;

Why it took me so long to find that out, I have no idea why. Most forums threads by others seem to think the disabled parameter is the best way to go. Actually, the sheer number of people suggesting that makes me think it’s a bad idea – just following the crowd. This is why readOnly might be the right option: You’re still allowed to post the form value, but the user isn’t able to change what’s inside the box. When using disabled *nothing* gets posted from that element. So if all you want to do is prevent a user from editing the value of a form element, use readOnly. If you don’t want that value posted, then go ahead and use disabled.

Enjoy!




Dynamically set onClick events in IE and Firefox

I’ve had a couple of small tasks where I’ve needed to toggle the onclick events on a page element. It was surprising how difficult it is to get a straight answer on how to do this.


function hide_field() {
my_element.onclick = function() { show_field(); };
}
function show_field() {
my_element.onclick = function() { hide_field(); };
}




Cool Download Page

I’m looking into new JS frameworks for frontend enhancements, and came across MooTools on recommendation from a friend. The framework has lots of cool features and seems pretty simple, but one thing I’m most impressed with is the download page. It acts just like the *nix package managers – allowing to you pick and choose which modules you’d like to download – even auto-selecting dependencies. Definitely a novel idea for the web.




Pre-QA isn’t good for interviews

I’m just going to throw this out there… if you have a piece of software, site, etc that isn’t quite at the QA stages, no matter how rockin’ in might be, you might want to consider holding off on showing it to others until you know the demo is going to work. I think I’m done showing people demonstrations of Mr. Fish Lite until the backend VTK issues are ironed out, which thankfully is *not* my job. There are some pesky UI issues I need to iron-out with IE box models and transparent PNG support as well, but at least those are things I can fix pretty quickly.

My advice, show some screenshots or maybe even make a snazzy video demonstration where you can control all the variables.

In the meantime you can see a screenshot of Mr. Fish Lite here




Mr. Fish Lite is coming

If you’re interested in the DFL project, you’ll be happy to know that German and I are tasked with a bit of a crack programming job in the next week or so. Actually, we told our boss the idea we had about making a “Lite” version of the data viewer program that runs through some fancy AJAX and DOM scripting, with a Java frontend on VTK for the image production.

Crash course on DOM here I come!

Enjoy…