You half assed it. That is why your PhoneGap application sucks.
sintaxi.com
sintaxi.com
Phonegap apps look and feel like phonegap, but 'run everywhere'.
I think Phonegap is a suitable replacement for Android & Blackberry where cheap > good.
On iOS I'm not sure how receptive the market would be... I think we all know how horrible Java apps feel on OS X, because it uses a slightly different UI paradigm (one menu bar).
I do think that you can do quality work on Phonegap, however, it's never going to 'feel' native iOS for a few years until the CPU performance improves on iPhone. That said there are certainly places when writing 'native' code that you throw in a UIWebView because getting iOS to do what you want is a major PITA.
The only example of well-received custom widgets on my iPad is eBay.
http://www.appannie.com/app/ios/itranslate-voice/
http://www.appannie.com/app/ios/camera/
http://www.appannie.com/app/ios/instaframe-pro-photo-frame/
http://www.appannie.com/app/ios/djay-for-iphone-ipod-touch-s...
I took the time to analyze Top Grossing US without games. I've gotten a lot of inquiries about HTML5 based apps recently, so this was interesting.
#3 MLB, stock; #5 Pandora, stock; #12 MotionX GPS, custom; #17 and #26 comics, slightly customized navigation bar & stock tab bar; #27 Zoosk, faux stock UI; #30 eHarmony, stock; #38 TeleNav, stock; #46 WhatsApp, stock; #52 iTranslate, custom; #68 Nike+ GPS, stock; #72 Camera+, rather custom; #74 MyCalendar, stock; #81 Pages, stock; #83 DC Comics, slightly customized navigation & stock tab bar; #85 Grindr, sotck; #86 Instaframe, custom; #88 Badoo, stockish; #90 Free Music Download, stock; #93, Palm Reader, custom; #96 TurboScan, stock; #97 iMovie, stock where applicable.
Some of the UIs are badly imitating UIKit, like Zoosk. They still often replicate the navigation concepts, UIKit shadows (skeuomorphism), widget sizes … - I don't think the stock look & feel is dead yet.
This is more pronounced on the iPad I think.
In the last two they replaced stock controls with custom ones, even where they didn't have to, and that supports your hypothesis.
But all of the others, however, are using stock controls for all the controls where there is a stock control, and only using custom controls where there is no stock control.
The ability to customize the stock controls has increased a fair bit and gotten more popular as its gotten easier. But these developers (at least, I can't speak for the whole appstore) are using the standard controls.
What is true is that they aren't using the blue-pinstripe look of the original iPhone anymore.
The reason this distinction is important is that its a whole lot harder to do a custom control (like a turntable) than it is to use a standard control, and its also very easy to take that standard control and make it just the right shade of grey, or make it look like wood, etc.
Thus customizing how these standard controls look has gone up dramatically, yes.
That's what I mean and that's why I don't think people should waste so much time trying to emulate that look down to the last pixel in Phonegap apps. Users don't care anyway as long as your app looks good.
I'm not convinced that normal people care that much about design. If the app solves a pain point for them, they could care less about how native it feels.
When this is brought up, I point people to Cyberduck. http://cyberduck.ch/
My point is it's possible to do a functional and native-looking app with non-native tools. But of course, not all tools are equal. I was just answering to Java on OS X.
Do _not_ assume this will always work. If you bind to the tap events and change content positions you _will_ end up firing the click on an unintended element. Remember the click almost always trails the tap (save for on the Windows Phone platform). He mentions that jQuery Mobile does some "magic" to deal with the click and tap. This is the vmouse module and you can use this independent of the library for just this purpose.
"JQuery is enormous and has no business being on a phone"
It's a phonegap application, the assets can be packaged with the application itself which means that in many cases this doesn't apply.
"Massive Footprint. 248k wowsers"
I'm still confused why this matters if you are packaging your assets with the phonegap build which I would expect most people do.
He's very right. Phonegap is no trumpcard, but I'd appreciate a more thorough treatment of the "best practices" he espouses.
> I'm still confused why this matters if you are packaging your assets with the phonegap build which I would expect most people do.
Ignoring download time, loading, parsing, and evaluating 250k of javascript is not free[1].
[1] http://carlos.bueno.org/2010/02/measuring-javascript-parse-a...
That article is on a desktop (well, laptop) processor. The timings on mobile are obviously higher. JS parse & load is mostly ignored on the desktop but I know I've read at least one article where a team was pulling down their JS as plain text and eval()ing it later to get their load times down.
Your point is well taken though, and thanks for the link.
I don't recall when this kind soul made this document public, but I believe it was in a similar discussion on hacker news and I've had it bookmarked since.
I have also done my own tests, and the iOS numbers are similar (depending on the device of course).
Additionally mobile browsers are often slow to execute, so loading a lot of JS can bog down your app. For a while there was a big stink about iOS only using their best JS engine in Safari and not web controls, not sure if that every got solved, but laggy HTML based apps is a big problem.
Second, ontouchstart is a tricky game. It's wonderfully fast, but breaks scrolling completely if you start scrolling from an ontouchstart-bound element.
Basically, it's a shortcut around learning Objective-C. You get a lot of quick wins, but the end product isn't quite as good - except if you're doing something unusual, like one-page apps with no scrolling. I find it's good for prototyping.
It also means being able to add more functionality at will without having to rebundle, or worse, work on basic functionality helpers. Just seems like wasted time for such a small improvement. These devices were built to have application code on them.
http://itunes.apple.com/us/app/totally-editable-calculator/i...
I've built a few apps in Objective-C and in HTML5 and on both platforms you've got to be careful about performance. I don't think it's a HTML specific problem:
I remember building my first Objective-C application and having it perform terribly. I had to learn to reuse table cells and not to redraw an entire UIView.
Each platform has its quirks and if you're willing to learn about them you can make terrible and good apps in either.
You certainly cannot approach HTML5 apps as a standard chrome browser. That's just unrealistic.
TW7XME4JH6RN
NWWTRHHNMYPT
HKXELLNFFAJM
JY9WLFTR9Y7T
J4XTAFW9MA6K
4HEL349WWPKH
MLNKFM46KAXX
3AL9FJ7LWFW6
AH43J9KA6ERN
FH4RFWXMMW76
Nice app. Simple, works. Just need to make it iPad compatible.
He's also absolutely right about results equalling effort. I've seen plenty of terrible mobile apps developed in JS, and I also have yet to see a jQuery Mobile app that feels right to me. I think some of this stems from attempting to recreate stock native UI elements and failing halfway. I wasn't interested in doing so with ChainCal, so I avoided that issue altogether.
As for performance, JS execution has never really been a bottleneck -- it's DOM manipulation. My advice would concur with the author's: use CSS transitions for everything. If you put in the time with benchmarking small operations and you approach things in different ways to squeeze out performance, your app can feel native. Trial and error led me to plenty of performance discoveries. As an example, using translate3d to move an element offscreen is tremendously faster than setting its display to 'none'.
Finally, I will agree about jQuery being a very large library with a lot of cross-browser support that isn't necessary for mobile. However, from my benchmarking, it would seem jQuery is still faster at most DOM operations than Zepto.
Happy to answer any questions about my experience with PhoneGap.
LRXTYFWEMJXM
JMH34LFNX44W
3N7YXP7HN9P7
PF3RLT4PHWML
MWFHXK669M4L
I dig Quantified Self stuff so I am looking forward to playing with this. Thanks for sharing.
https://play.google.com/store/apps/details?id=webworks.gangs...
It pushes HTML5 canvas to its limits to create a completely cross-platform 2.5D action shooter. Also, a lot of players really like it and that is really the only metric that matters.
The game has its share of mobile specific optimizations, none of which are related to it being a PhoneGap application. Overall, PhoneGap just gets out of the way, the way things should be.
(EDIT: Forgot to mention, you can try the game in your browser at http://www.gangstagangsta.com/play)
http://itunes.apple.com/us/app/totally-editable-calculator/i...
Here are some vouchers:
NLXEH6NE7W43
XL6AF63J7K9P
MNJKYR3YAN9M
3ARXXHX3HMYN
6WXJA97FL9LK
Thanks for posting this example. It's pretty responsive... not sure if I would have known it was PhoneGap.
One bug report: Divide-by-zero seems to act as if nothing happened, rather than reporting an error or NaN value.
Figuring it out is probably going to be redoing much of it correctly. You might want to read up on responsive design.
http://itunes.apple.com/us/app/chaincal/id499195302?ls=1&...
I posted some promo codes in the parent thread. Let me know if those run out and I can add some here.
In that case you don't need it. It exist mainly to paper over the differences between the different browsers (i.e IE) which you don't care about.
You will find that HTML5 can do most of the nice things jQuery can.
Two big tips: 1. Turn off the transitions, they perform poorly and look out of place on most devices. 2. Don't use the navbar, it just doesn't work properly on all devices, I wasted so much time trying to work out the issues with it before changing my navigation scheme.
Jokes aside, yes... it is that bad. I help out in the PhoneGap IRC channel, and I see more frustration surrounding jQuery Mobile in the PhoneGap community than any other single tool.
One of the core PhoneGap devs even tried to use it just so he could try and help people who come to us with issues relating to it. The experience was so bad I think he gave up on the idea.
I ended up making the above joke tumblr instead ;) I just try and steer people away from it.
Its performance and (in my opinion) visual appearance bely it's post 1.0 version number.
Basically, jQuery Mobile wants your whole app to be on one page. You can either have one giant HTML file that has a bunch of divs representing multiple pages, or you can have several different HTML files and link them as normal. Then jQuery Mobile will take all of your anchor links and turn them into something that fetches that page's contents and inserts it into the DOM of the current page, instead of loading a new page. Then their "page transitions" are triggering hide and show actions on the various pages in the DOM.
This also makes registering event handlers awful. First, all of your javascript has to be in one file and it has to be included in every page that a user could possibly navigate to. This means that you can't just bind on document.ready like normal, because some of the elements you're binding to don't actually exist on the page until you try and navigate to the page.
Then, jQuery Mobile uses custom events to tell you when there's been a page transition. However, you can't put your event bindings in there, either, because then your event bindings will be reapplied every time the user navigates away from and back to that page - basically, every action will be applied multiple times. Terrible.
So this means that all of your bindings have to be live bindings. Oh, also, you need to make sure none of your elements on different pages have the same id since, in the long run, jQuery Mobile mashes them all onto one page.
Yeah, I may be a bit bitter.
I'd wager a guess that the "single codebase" app written in PhoneGap get exponentially more complex with each platform due to browser/device/OS quirks, whereas the native implementation means an effectively linear complexity for each additional platform.
Seriously?
I'd rather write a web app in Ruby than C++ any day of the week.
I would like to see a light-weight Javascript UI and MVC library that is recommended by Phonegap.
-moz-transition: opacity .15s ease-in-out;
transition: opacity .15s ease-in-out;
Any recommendations for JQM alternative in regards to UI/design components?
So this guy thinks knowing your target platform is a burden and not knowing it somehow is a pro?
On topic of half-assing: If you're using a multi platform 3rd party layer because you're too lazy/reluctant to learn the native technology you are already half assing it.
Take a look at all those multi platform desktop frameworks like Qt, wxWidgets, etc. Apps made with those don't feel native and usually deliver subpar user experience. It's not much different with PhoneGap, RubyMotion and friends.
The goals are different. Flipboard and InstaPaper wanted to make great iOS apps and spent the time and effort to learn the right away. And it took well over a year for a native Android port of InstaPaper. When your value proposition is finesse and performance, go native.
If BingoCardCreator wants an iOS port so teachers can easily drag and drop words using touch on an iPad while sitting in front of the TV, I don't see why Patrick/BCC should spend months and months learning ObjC when he could just hook something up easily with jQuery draggables UI.
I've released ObjC and PhoneGap apps on the App Store and frankly, like everything else in life, you have to make the best use of the resources (time/budget/energy) available to you to make the best product. What this blog post is saying, is that just because you use PhoneGap, does not necessarily mean your application will be subpar. You must know how to use it well.
Also, RubyMotion uses the exact same iOS objects as ObjC does (and then some). So it should be no different than coding natively in ObjC.
Especially if the code is using a lot of structs.
This is not actually the case with RubyMotion, since it compiles directly to native code and uses iOS-native UI. A RubyMotion app is indistinguishable from a native Obj-C app.
The only exception is Android maybe, but it's in an experimental phase at the moment ( look Necessitas at http://sourceforge.net/p/necessitas/home/necessitas/ )
Simple is best.
If we're to believe that one day HTML5-based mobile web apps will rule, what is wrong with PhoneGap exactly?
To me, it's like using Java for a Windows desktop app.
Do you just have a problem with the native components that are all always there versus just the shim pieces you need, etc? Any evidence that that really causes any sort of perceivable issue? It seems like it would all be microscopic compared to... anything else in a real application.
Even examples of "web with native wrapper" apps, like Facebook and OkCupid, are dramatically, dramatically worse than best of breed native apps.
Companies like OkCupid and LinkedIn, whose apps both rely heavily on web views, need to think about the benefits of using the same code across multiple platforms. I'd tend to argue that both of those apps are pretty well-done. They certainly lack some of the really slick transitions and polish of an app like Tweetbot, but I definitely don't think either one feels cheap.