tl;dr - don't use prototyping tools to build products.
PhoneGap vs. Native: Some Thoughts on Going Native
31–40 of 41 posts
Re: PhoneGap vs. Native: Some Thoughts on Going Native
#32Earlier quoted context omitted.
I'm not a mobile webdev, but about (2), did you try using Webworkers for the background tasks? iOS Safari supports it nowadays, right?
Web workers doesn't really work. Somehow, It still blocks the main UI thread.
That's a bummer. I was planning to rely on them soon.
Any links to more detail?
Re: PhoneGap vs. Native: Some Thoughts on Going Native
#33I spent an inordinate amount of time fighting webkit before switching all of our stuff to native. The four biggest problems, I think, with the state of webkit are: 1) Implicit memory management of large images/surfaces isn't reliable. There's basically nothing you can do (outside of not doing anything) to prevent your page from crashing webkit if you use too many (where too many is undefined) accelerated elements/tot…
Considering 4), i just discovered iWebInspector (http://www.iwebinspector.com/) which allows using the normal Safari developer tools for the iOS simulator. It's wonderful, free, and i don't really get why i haven't discovered this tool a few months earlier. Would have saved a lot of headaches :)
Re: PhoneGap vs. Native: Some Thoughts on Going Native
#34These types of apps sit solidly in an uncanny valley of application design. They appear as if they should work like a native app, and they pretty much do, but not quite. The fact that they look like a native app greatly magnifies that last missing 10%.
Unfortunately, this isn't just a mobile problem, as web apps get more interactive, we're hitting this problem on the wider web as well.
Re: PhoneGap vs. Native: Some Thoughts on Going Native
#35Would it be worth doing a poll on what technologies people are using for mobile development? I've done some native Android/iPhone and now I'm jumping into HTML5. From most of the comments, I'm wondering if it's worth it.
Re: PhoneGap vs. Native: Some Thoughts on Going Native
#36The strength of PhoneGap & Co is the ease of rapid prototype-production cycling and the flexibility in UI construction empowered by CSS3/HTML5. This guy clearly took it as "a way to avoid native framework".
Interesting how one can make the right choice without of knowing what he truly wants and/or the right tool for his intent.
Re: PhoneGap vs. Native: Some Thoughts on Going Native
#37I spent an inordinate amount of time fighting webkit before switching all of our stuff to native. The four biggest problems, I think, with the state of webkit are: 1) Implicit memory management of large images/surfaces isn't reliable. There's basically nothing you can do (outside of not doing anything) to prevent your page from crashing webkit if you use too many (where too many is undefined) accelerated elements/tot…
Considering 4), i just discovered iWebInspector ( http://www.iwebinspector.com/ ) which allows using the normal Safari developer tools for the iOS simulator. It's wonderful, free, and i don't really get why i haven't discovered this tool a few months earlier. Would have saved a lot of headaches :)
Yeah, that's a super useful program. The feature it's based on was only introduced in iOS 5 ( http://hiediutley.com/2011/11/22/debugging-ios-apps-using-sa... ) .. it would have saved me countless hours of misery over the past couple of years if it was possible before.
Re: PhoneGap vs. Native: Some Thoughts on Going Native
#38It's important to distinguish between PhoneGap's performance, and the performance of jQuery mobile or Sencha Touch, which are more responsible for the native sliding and scroll features of the non-native apps.
In my experience with PhoneGap, the framework does a great job of exposing native features of the iPhone, i.e. recording audio, taking pictures. The downside for me came only came when adding the visual effects to mimic a native iPhone app. Trying to fix all of the quirks with jQuery mobile, such as persistent headers and footers (although the latest RC has been looking much better), has ultimately led to my abandonment of the non-native app.
Re: PhoneGap vs. Native: Some Thoughts on Going Native
#39This person successfully managed to trade a bunch of irritating issues for a different set of irritating issues: that generally makes one feel happier, as working around new and thereby relatively exciting irritating issues as a vacation from the worn and tired ones we are now so sick of it makes us want to die, is all many of us can hope for in life.
It's not exactly like that — there will always be issue, we know it, but some are more irritating than other. I can handle Xcode crashing, and needing some help to compile everything — I can live with that. The debugging part otherwise, is subpar. It's (at least for me), a true hell. Appcelerator was the king of unusable error for example, that and a lack of GOOD (heck, even complete) doc were driving me mad. So yes…
Context: I have been doing iOS app development, both native and with massive amounts of mixed in HTML (using a home-grown mechanism similar to, though I will personally claim nearly infinitely better than, PhoneGap) since early 2008 (yes: half a year before the SDK existed).
The day you realize that what version of Xcode you were using when you compiled the application (in addition to the version of the firmware installed on the device) affects the behavior of UI classes on deployed units, and that these effects are not documented (and are in some cases /insane/) is the day you realize that no: it is just different.
To describe this another way: yes... Apple seriously implemented a kind of "quirks mode" (I believe that is the most fair, accurate, and descriptive term to use to describe it, by analogy to web browsers) in the UIKit framework on the device; they will change the behavior of the library slightly, and then do runtime checks to determine "could you have known that we did that".
To be clear: this is not due to compiler bugs; they do it with a runtime function called UIApplicationLinkedOnOrAfter() (to be clear: which looks at the date of the UIKit library used, not the date of the link). I discovered this after spending an incomprehensible amount of time attempting to debug a serious UI issue that only occurred when /some/ of the developers working on my project compiled it: I sat around disassembling and tracing and then... "woah".
The places where I have seen this stuff used, while attempting to maintain an application not over the course of a few months but over the course of now over four years, has been sufficiently "wtf" that on iOS 4.1 I finally wrote a tool that disassembled UIKit, found all of the calls to that function, and attempted to document "for what version it is being compared".
(I intended to at some point even write a detailed blog post about this, with examples, and a chart of all of the usages, but I've never had time. I really wish I had more time to sit around writing blog posts, but the really good ones of those take days to put together, if not even longer ;P.)
In contrast, the stupid WebKit bugs in or changes to iframes and multi-touch that seem to get traded around in every version of iOS are actually tame in comparison: they simply have not caused the kind of debugging hell and frustration that the simpler native components have caused. I have only once been "I upgraded to the latest version of iOS and all of my content disappeared" with HTML (iframes with height=0 stopped auto-sizing: changed to height=1: irritating as now an iframe cannot autosize so small as to disappear), but it has happened four or five times with my native code.
So there: just another set of anecdote to throw in the pile of "irritating garbage" and "debugging hell" that people like to throw around about everything they do. Personally, I find that I'm happiest when I switch back/forth between doing Objective-C, HTML, Python (server), and assembly (reversing) a lot, so that no specific one set of irritating problems ever becomes so depressing that I throw up my arms and quit (which has totally happened a few times).
Re: PhoneGap vs. Native: Some Thoughts on Going Native
#40I am equally productive with web as well as native development so it makes no difference to me. Not surprisingly, Phonegap never appealed much - same work, inferior results, single (but dubious) benefit: cross platform. I was pleasantly surprised by Titanium mobile though when I had to evaluate it at my job 2 years ago. I set to reimplement one of our (non-trivial) apps and summarize my experience. I ended up writing…
Titanium has come a long well, I eval'd it around 18months ago and was frustrated with 'how the heck do I build something that doesn't leak'. I was amazed at how quick I got something running, until it crashed... I hugely struggled with the best way to build an app. 12 months later, the SDK has improved, and documentation has improved. I circled round to Titanium again. Now I've got an app in my spare time that's pre…
Are you targeting multiple platforms with your Titanium based app?
Any other got'chas or suggestions beyond getting a firm grasp of the CommonJS style?