Response title
This is preview!
Move this topic
In the graded browser support chart (http://jquerymobile.com/gbs/) PhoneGap is similar, but not quite as good, as the Native column. My initial assumption is that PhoneGap uses the default browser for each device, which would mean it doesn't require its own column in this chart. Is this not true? I noticed John Resig mentions PhoneGap "uses WebKit as its rendering engine" in this presentation (http://www.slideshare.net/jeresig/testing-mobile-javascript?from=ss_embed), which would imply the PhoneGap folks developed their own WebKit browser that works across popular mobile devices.
1
Replies(8)
Not an expert here, and I don't have the PhoneGap source in front of me, but WebKit is a rendering engine not a browser, it's up to the browser/phone/OS vendor to implement functionality around it, like hardware acceleration, bookmark management, tabs, etc. I'm not sure about other platforms, but iOS provides a component in its API that is essentially an embeddable browser, it would make sense for other platforms to provide something similar to reduce duplicated functionality and application bloat.
With that being said, this embeddable browser is not necessarily the same as the default browser, for instance, in iOS 4.3 the embeddable component does not have the new and improved JavaScript engine for security reasons. (Resulting in all of the noise about Apple "crippling" webapps run from the home screen.)
-Eric
Leave a comment on edelabar's reply
Eric - thanks this definitely helps clarify. I'm going to confirm with the PhoneGap team, but it sounds like PhoneGap leverages what you describe as the WebKit API component on iOS, and likely the equivalent for Android, Blackberry, etc. So in the case of the jQuery Mobile GBS chart, the each operating system's WebKit API component is what's represented.
This make sense as to why the support is similar, but not exact. The PhoneGap team based their interpretation of each OS's browser component on WebKit, but as every implementation of WebKit differs, therein lies the variation.
The good news is, if the PhoneGap team keeps up the good work and sticks with WebKit for each mobile OS, it will be the easiest "browser" to ensure jQuery Mobile is compatible with. It already has more "A"s than any other browser.
Personally, I think the talk about Apple intentionally negatively impacting web apps is nonsense. They added enhanced JS performance for their mobile web browser, which make sense to be higher on the priority list than web apps launched from the home screen, as more people use the iPhone to browse the web than any other device. I think any enhancements will eventually make it to all areas of iOS, but should be seen as enhamcements, not bugs. I'm not worried.
Leave a comment on withinsight's reply
After working quite a bit with jqm and phonegap, keep in mind that there are many thing not working between them. Ajax loading of pages is broken, progmatic loading of pages is broken, etc. etc.
Seems to me that Phonegap would only work if you build your app to be entirely local. Currently, jqm only makes ajax calls for urls that belong to the same host/domain. Phonegap requires that the html be stored locally. You can make ajax calls externally for data, but the html to your app has to be stored locally.
One strategy would be to have your app access "templates (or empty pages)" then use the "pagebeforeshow" event to make a request for external data and bind it into the template.
I'm experimenting with this and a few other strategies. Has anyone else done any work in this area?
Leave a comment on epsd.jquery's reply
You do not need to store the html locally in phonegap, you can easily modify the jqm js to load whole pages into phonegap, html and all, via ajax.
Whether that passes muster with the app stores is another question...
Whether that passes muster with the app stores is another question...
Exactly why I suggested localizing the HTML. Also, as easy as it is to modify jqm, an app dev shouldn't need to modify the framework to get what it to do what you want.
Leave a comment on epsd.jquery's reply
epsd.jquery and rmanalan - I think what you're both scratching the surface of is that keeping your markup local, but pulling your data from a remote source is the combination that will both allow jQuery Mobile to work within PhoneGap, and be your best bet for app store submission.
Also, I've read, and am planning to test, that AJAX calls, when packaged with native apps, don't fall under the same-domain policy that has plagued us in desktop browsers for years (http://mobile.tutsplus.com/tutorials/mobile-web-apps/use-jquery-mobile-to-build-a-native-android-news-reader-app-part-3/). While the same-domain AJAX rule may apply to jQuery Mobile sites when viewed via a web browser (either on desktop or mobile devices), my belief is that when packaged with a native app, we're good.
Leave a comment on withinsight's reply
You are 100%, the same domain issues do not apply. As long as you provide some functionality standard in the native app, you should be good to go.
Leave a comment on epsd.jquery's reply
Change topic type
Link this topic
Provide the permalink of a topic that is related to this topic
Reply to withinsight's question