I played with jQueryMobile during the weekend and was really surprised by the productivity you get with the framework. In like 4hrs I was able to create a great looking app that was running with any major glitches on my Android phone. Now when I compare that to the challenges I was experiencing when coding with Android :)
Some lessons learned from the weekend:
- Good IDE for javascript is a must. Aptana really rules in that area, you can add it to your Android Eclipse installation easily - http://aptana.com/products/studio3/download
- There are challenges on Android when you move between pages of the app. The whole screen blinks. Apparently you need to disable the transition effect on Android, like below:
$.mobile.defaultDialogTransition = "none";
$.mobile.defaultPageTransition = "none";
- I18N is not built into the jQM, but there are some interesting workarounds, like http://stackoverflow.com/questions/8134555/jquery-mobile-json-processing-before-mobile-enhancements
- listening for the hardware back button is really easy:
document.addEventListener("backbutton", function(e) {
if($.mobile.activePage.is('#welcomeScreen')) {
e.preventDefault();
navigator.app.exitApp();
} else {
navigator.app.backHistory()
}
}, false);
but the issue is that it didnt work with jQM 1.0.1. It seems to work perfectly with 1.1.rc1 though (it has another bug, that makes it unusable, but that's another story).
- You can easily tap into the area clicked event with the following code:
$(document).find('AREA').bind('click', function(e) {
$.mobile.changePage("#youNewPage");
}
- Reading and setting values from the jQueryMobile inputs is also easy:
currentValue = $('#myComponentId').val();
$('#myComponentId ').val("NEW VALUE HERE"); // here we're setting the value
- Hiding and Showing buttons created with <a> tag is not easy. You need to envelope then with <div> tag and hide that div, so for example:
$("#btnMyButton").parent().hide(); // hide the button
$("#btnMyButton").parent().show(); // show the button
- Afaik there is no way to define a fragment of the code and reuse it on multiple screens. So you end up with defining the footer zillion times (once per screen).
In the end - I really liked jQM. Definition of the UI was intuitive (it's HTML with additional attributes), debugging was painless, google helped a lot :)
Some lessons learned from the weekend:
- Good IDE for javascript is a must. Aptana really rules in that area, you can add it to your Android Eclipse installation easily - http://aptana.com/products/studio3/download
- There are challenges on Android when you move between pages of the app. The whole screen blinks. Apparently you need to disable the transition effect on Android, like below:
$.mobile.defaultDialogTransition = "none";
$.mobile.defaultPageTransition = "none";
- I18N is not built into the jQM, but there are some interesting workarounds, like http://stackoverflow.com/questions/8134555/jquery-mobile-json-processing-before-mobile-enhancements
- listening for the hardware back button is really easy:
document.addEventListener("backbutton", function(e) {
if($.mobile.activePage.is('#welcomeScreen')) {
e.preventDefault();
navigator.app.exitApp();
} else {
navigator.app.backHistory()
}
}, false);
but the issue is that it didnt work with jQM 1.0.1. It seems to work perfectly with 1.1.rc1 though (it has another bug, that makes it unusable, but that's another story).
- You can easily tap into the area clicked event with the following code:
$(document).find('AREA').bind('click', function(e) {
$.mobile.changePage("#youNewPage");
}
- Reading and setting values from the jQueryMobile inputs is also easy:
currentValue = $('#myComponentId').val();
$('#myComponentId ').val("NEW VALUE HERE"); // here we're setting the value
- Hiding and Showing buttons created with <a> tag is not easy. You need to envelope then with <div> tag and hide that div, so for example:
$("#btnMyButton").parent().hide(); // hide the button
$("#btnMyButton").parent().show(); // show the button
- Afaik there is no way to define a fragment of the code and reuse it on multiple screens. So you end up with defining the footer zillion times (once per screen).
In the end - I really liked jQM. Definition of the UI was intuitive (it's HTML with additional attributes), debugging was painless, google helped a lot :)
Comments
Post a Comment