You are currently browsing comments. If you would like to return to the full story, you can read the full entry here: “Developing Better PhoneGap Apps”.
No related posts.
Comments on “Developing Better PhoneGap Apps”, Page 1
Developing Better PhoneGap Apps
You can follow all the replies to this entry through the comments feed.
Pings
[...] Developing Better PhoneGap apps If you’ve started researching what it would take to get from mobile web to native app, you’ve likely come across PhoneGap—a framework allowing you to wrap a mobile web app and deploy it as if it were written natively. We’ve done quite a bit of work in PhoneGap lately and the question inevitably comes up: are apps built in PhoneGap “slow”? A quick Google search returns a page full of reasons that would keep you from wanting to pursue using web technology in your next app. Before you write it off, however, we’ve come up with a few tips that have drastically improved our own PhoneGap apps. (tags: performance tips ios javascript mobile phonegap) [...]
[...] DiscoverThe Best Free Apple iPad ResourcesNice links here for you iPaddies.(tags: ipad resources)Developing Better PhoneGap appsIf you’ve started researching what it would take to get from mobile web to native app, you’ve [...]
[...] within an App wrapper such as PhoneGap, you ought to take a look at Float Mobile Learning’s Developing Better PhoneGap Apps. Coincidentally, there’s also an interesting story today on how all HTML5 apps [...]
[...] Developing Better PhoneGap Apps ：http://floatlearning.com/2011/03/developing-better… [...]
The issue with using touchstart instead of onclick is that it can mess with the expected browsing experience, the main one being scrolling.
If a user tries to scroll down the page but touches an element that fires a ontouch event, the page will automatically load the next page whereas an onclick event will cancel itself if it detects any movement, i.e. scrolling up/down/left/right.
You make an excellent point, Ciaran. One of the big issues with touchstart right now is that every vendor is implementing them ever so slightly differently. If your application requires scrolling, using touchstart is going to produce unwanted effects.
One solution that we’ve used is to listen for touchstart, touchmove, and touchend. If touchstart and touchend occurred without a touchmove, then it is a tap (and this actually more closely models how the standard iOS and Android interfaces respond). If there is a touchmove, then it was a scroll or a swipe or a cancel. It is kind of reinventing the “click” but without the delay.
I neglected to mention that in my “word of warning.” I’m going back and editing it now.
Thanks!
Daniel, can you share the code you guys use to compare touchstart, touchend, and touchmove?
You got it, Ben!
http://floatlearning.com/2011/03/developing-better-phonegap-apps/#update2
a workaround for the 400ms delay/scrolling is to use touchstart instead of onclick, but also check if the user is scrolling
http://code.google.com/intl/ro-RO/mobile/articles/fast_buttons.html
You say “Find the processes which are taking the longest to complete”. I have not found a good technique yet within Phonegap to achieve this. Do you have any recommendations for profiling techniques within Phonegap applications?
Truthfully, it’s been a mixture of guessing and checking by bookending segments of code in new Date() and comparing the before and after values.
On a related note, a login form in one of my iPad apps was giving me a lot of grief with flickering. It seemed whenever the keyboard was used, all CSS transitions/animations started flickering. I ended up completely working around the problem by placing the login form in a modal view using a PhoneGap plugin to pass data back and forth.
Is there a way to get responsive input for forms on initial selection, that brings up the keyboard? I tried using the above technique (as per links), but with both ios and android, it didn’t seem to make much difference. On android the input selection was slightly faster, but on both systems the keyboard came up with a noticeable delay.
Thank You! Thank You! Thank You! Thank You! This is a really “snappy” solution to touch events. I almost abandoned my project until I found your tip (:active pseudo-class selector in CSS). I was getting painfully slow touchStart feedback. Now I’m back in action.
Thanks again!
Cheers.
I know I’m a little late to the game here, but for click event replacement, I’ve been using the HTML5 Mobile Boilerplate Fast Button Click. It’s basically the Google Fast Button click mentioned above, but accounts for scrolling and other things. I’ve put it in place on a mobile website, and it’s much more responsive. Super easy to implement, thought it might help someone.
Here is a test I did for work with several different touch events paired with touch styled media queries for moblie. Each subsequent screen (after clicking the next button) uses a different event, from click to touchstart to touchend to the fast button click.
Daniel,
Great article!
Do you know if apps built with phonegap can receive push notifications when they are in the background? The sample code from their wiki suggests that the app has to be running (foreground?) for it to receive push notifications.
A second part this question is: if the app could receive remote notifications, can it send events to the elements on the page – e.g. refresh table entries?
Thanks in advance!
Hi Srini,
There are two different types of notifications on iOS devices–push notifications (received from a remote server) and local notifications (scheduled by the app on the device). Both are attainable with PhoneGap:
Local notifications: https://github.com/purplecabbage/phonegap-plugins/tree/master/iPhone/LocalNotification
Push notifications: http://www.easyapns.com
As far as sending events to elements on the page, you cannot truly execute JavaScript or update the DOM while the app is in the background; changes will be queued and ran immediately upon resuming the app. But it sounds like what you want to do is for the app to receive a notification while it is in the background and have an updated view for the user when they return to the app. The easiest thing to do would be to update the table every time the app returns to the foreground. This way every time the app is opened (whether its from a notification or not) it will have the most up-to-date data.
Hope that helps!
Thanks,
–Daniel
I’ve just started with Phonegap development, and I was advised to use jQuery Mobile, which of course relies on jQuery core. The reason given was that jQMobile does a good job of emulating native UI components. I haven’t made the switch to xui because I’m developing by myself and don’t have the resources to roll my own UI elements. Can you comment on the tradeoff and what one could do to make xui or zepto look more native? Many thanks.
Hi Ari,
jQuery Mobile and the jQuery library together (even when minified) come in at over 170kb–and that’s just for the core for your application. We recently released a PhoneGap-based application to a client (a decently complicated application) where all the JS for the entire app only came in at 70kb (built on Zepto.js). It’s not so much the size difference (because really, what’s 100kb anymore) but it’s what the size represents. A difference of 100kb of minified JS is a lot of code. The real problem is that of all this code being stored in your devices memory and taking away resources from the rest of your app–much of it will never be used (like all the jQuery code for IE6). There is a noticeable performance difference in apps of any substance or complexity. At this point in the game, I am not considering jQuery Mobile for use in any of my projects (although I still follow it).
That being said, I understand your dilemma. jQuery Mobile has a very attractive feature–it helps you build the UI of your app so that it looks more like a native app. If that’s a big need of yours, then you definitely don’t want to write it off just yet. But there are alternatives: Have you looked at Jo (http://joapp.com/) or iUI (http://www.iui-js.org/)? Thomas Fuchs has a great resource for micro JS libraries as microjs.com–be sure to check it out!
Thanks!
–Daniel
How can u call an alert feature when an app is in the background
Hi Don,
I’m assuming you’re talking about iOS devices. In this case, there are two different kinds of notifications: local notifications and push notifications. Both are very attainable with PhoneGap:
Push notifications: http://www.easyapns.com/
Local notifications: https://github.com/purplecabbage/phonegap-plugins/tree/master/iPhone/LocalNotification
There are likely more resources, these are just two I know about.
Thanks!
–Daniel
Hi Daniel,
Any best practices for the UI specifically for setting font size, image size…I’m using em’s values and the same HTML/CSS files doesn’t behave the same in iOS size and Android screen sizes? Any reason or am I missing something?
Why 1em doesn’t look the same in different screen sizes …not even close! :p
Thanks in advance for the help.
Hi laminina,
It sounds like you may have a misunderstanding about the way em sizes work–they are NOT an absolute measurement but a relative one.
For example, if I set my body text to 12px and then set my header text (h1, for example) to 2em, it will appear as twice the size as my body text. What sounds like is happening is that you are using em sizes for all the text in your application so it is basing the relative size off the device’s default stylesheet (which has different fonts and sizes between Android and iOS). Try using px measurements or, in your body tag, set the default font size to 14px to standardize the default size across the platforms.
Hope that helps!
–Daniel
I wrote a follow up to this post a few months ago that I believe a lot of people missed:
http://floatlearning.com/2011/05/how-well-does-phonegap-scale/
It discusses using a client-side templating engine to improve the performance of a PhoneGap application. We recently released a PhoneGap-based application to one of our clients that utilizes the approach outlined in this post and it saw noticeable performance improvements and benefits.
Thanks for this overview.
One thing that you may want to modify in our article is that you shouldn’t delete variables names.
function init() {
//application code here
delete init;
}
… will result in a JSHint error because the delete keyword should be used on objects, not variables.
Thanks for the heads up, Alex. I actually pulled that recommendation from the Apple JavaScript Development guidelines…but you are absolutely right. Deleting variables is (technically) not supposed to work. That’s just for releasing objects.
The goal is to release unneeded variables/functions from the global space (such as an initialization function).
this is really nice matter given here specially for the beginners
Actually the delete keyword in javascript is not for deleting objects, it is for deleting properties of objects. The reason this may seem to work is because you may be removing the property from the global object (window). But not all objects are deletable and you cannot delete a property that an object inherits from a prototype. The best you can do is remove as many references to an object as possible. Keep in mind that any closures referencing the object will keep it alive.
More info:
https://developer.mozilla.org/en/JavaScript/Reference/Operators/delete
Thanks for the clarification, Matt. I’m fixing the article now. That silly Apple JavaScript Developer Guidelines got me all confused about this…apparently Apple got rid of that document since I wrote this article. Probably for the best…