jQuery Forum

if I remove the data-role="page" from the div and just leave it as it is (as listed in the docs it's not mandatory

Where on earth did you read that? Can you provide a link?

data-role="page" is most certainly mandatory.

jQuery UI is also included

jQuery Mobile is not compatible with jQuery UI. Compatability with jQuery UI was not a design goal for jQuery Mobile, and they clearly achieved this non-design goal. ;) For one, their CSS conflicts.

Some clever people have gotten some parts of jQuery UI to work with jQuery Mobile, usually by doing a lot of fiddling and modifying. If you want to do this, you are on your own - it is not supported. Find some blogs that tell you how to work around the compatibility issues.

But, first, take out the jQuery UI and get things to work correctly. It's not surprising when jQuery Mobile doesn't work with things it wasn't designed to work with.

But on iOs on iphone 4 via Chrome browser it just doesn't work

You mean somebody actually uses the Chrome browser on iPhone? Really?

All browsers on iOS (unless Jailbreak) use UIWebView. They are just gussied-up versions of the internal iOS web browser. All of the browser controls (buttons, tabs, URL bar, whatever) are provided by the browser app (i.e. Chrome). The actual browser window is a UIWebView.

As such, all such browsers suffer at least one major problem - poor performance relative to Mobile Safari. This is because Mobile Safari uses a special version of UIWebView that does just-in-time compilation. Apple does not allow anybody else to use this special version of UIWebView, so all other apps using a webview suffer poor performance.

I think that users quickly notice the poor performance, and abandon these alternative browsers quickly. That is why I asked you if anybody actually uses Chrome on iOS. I think it is a non-issue, because such a small number of users will use something other than Mobile Safari on iPhone.

There are some other differences besides performance. In general, though, if, say, PhoneGap has a problem, then Chrome will have a problem. That is, anything you read about JQM with PhoneGap here will also apply to Chrome.

If it is not some common issue related to UIWebView, it could have something to do with how, specifically, Chrome has set-up the UIWebView. Unfortunately, this is beyond your control. If you have a problem with a PhoneGap app, and the problem is in some PhoneGap code, ultimately, it is open-source and you can change it. You can't change the Chrome browser app.

Hi,

Thanks so much for the quick and detailed reply.

About the data-role, look here: http://jquerymobile.com/demos/1.1.1/docs/pages/page-anatomy.html at the end of the page under "conventions, not requirements".  :-)   ...I really done my homework before asking for help... and yes, it did feel like somewhere on earth that's hard to reach.

About chrome/iOs: don't know who works with it, but we are testing on as many browsers as possible.

About jQuery-ui, it doesn't say anywhere clearly that it's not compatible - but yes - there are css overrides, and to be able to show a dialog correctly (from the j-ui) I had to do some dirty work... same goes for tabs.
Though draggable and some effects work beautifully!

Again - thanks so much for all the info and pointers!

Regards,
Idan

The page wrapper that used to be required for auto-initialization to work is now optional for single page documents, so there isn't any required markup at all

Do you only have one page?

About jQuery-ui, it doesn't say anywhere clearly that it's not compatible

jQuery-UI was developed long before jQuery Mobile. So, one would look to jQuery Mobile documentation to see if it is compatible. Do you find any such statement?

It's been discussed in the forum several times. So, you can do a search, and see what some people have done to make parts of jQuery-UI work with jQuery Mobile.

Unfortunately, the documentation doesn't always track between products. There is a statement on the jQuery website that jQuery 1.7.2 works with jQuery Mobile 1.1. It doesn't. And the jQuery Mobile web site states such, quite clearly. (It does with with jQuery Mobile 1.2.)

it doesn't say it's not compatible but it can be assumed as it doesn't state that

I've watched too much Steven Seagal movies to assume anything... (Under Siege 2... look for the quote).
But really - if talking about assumptions, one would assume that 2 products from the same family WILL work together.

But to the point - mostly things DO play together. I didn't assume anything, I just tried.
Why not use the so powerful jQuery ui??

I hoped someone can point something more crucial then assumed incompatibilities.
(yes, the incompatibilities are "assumed" just as well as the compatibility is assumed, as it doesn't say the other direction as well)

If I wanted to go just straight forward with what's "safe and sure" I'd use html 4 with css 2 and basic js. It would take much more time to develop, but there won't be any incompatibilities, as all the above are mature and "safe".

Don't get me wrong, I totally understand (and also can see...) the jui and jqm collisions, but why give up from the start?


Thanks for all the great insights so far!  :-)
Looking forward to hear more!

Regards,
Idan

Do you only have one page?

it's not saying "one page only" website, it's saying:

single page documents

and I'm not using any caching, so my documents should stay single-paged, don't they?
As I got it, each time a page is loaded via ajax, it's changing only the data-role="content" div, no?

Anyway, whatusiware, I started by saying that if I leave the data-role="page" div, the document get stuck on this line when loading it (only on chrome on ios). So removing it was a test (and it works, until not firing the pageshow/pageinit).
Any ideas about that?

Really appreciate the help and the clever conversation!  :-)  Really!
(and forgive my English as it's not my native language)

As I got it, each time a page is loaded via ajax, it's changing only the data-role="content" div, no?

No. That's not the way it works at all.

It loads the new page into the document. If there is a transition specified, it then does the transition from one page to the next. If there is no transition, it does the change immediately. After the page change is done, both pages are now in the document. In order to do transitions, it is necessary to have both pages loaded into the document at the same time.

If you do not specify data-dom-cache="true", you will see at one time no more than 3 pages in the document at any given time.

Every JQM developer should use Web Inspector, Firebug, etc. to examine the DOM and understand how pages work. Once you see it you will be clear about it.

This, also, is one of the major issues with compatibility. jQuery Mobile essentially fills a hole in HTML functionality, and does so in a way that is incompatible with many scripts that assume that only a single page is ever loaded into a document. That includes just about every website ever written.

So, the dirty little secret - which I wish the JQM folk would be more up-front about - is that JQM is it's own world, and plays nice only with others from it's own world.  Some random Javascript you found to solve some problem probably has a somewhat less than 50% chance of working with JQM without some kind of modification.

It's best to start with a fresh project and the documentation, follow it to the letter, once you have that working, you can try to integrate other stuff from outside of the JQM world.

As far as jQuery-UI is concerned, I think there were some decisions to be made quite some time ago. Should jQuery-UI be expanded to support mobile, or was there a need for an entirely new product? The decision that was made was the latter. Since it was felt it was too difficult to modify jQuery-UI to be suitable, it should follow that the jQuery Mobile team did not feel obligated to provide support for jQuery-UI, and I believe that this has been the case from the outset - there was never any intent to provide compatibility with jQuery-UI.

I disagree philosophically with the way the JQM team is handling these issues. I'm sure they feel that they don't want to red-letter these issues. But not doing so is causing a lot of wasted time by a lot of people.

jQuery Mobile doesn't have the comprehensive set of widgets that jQuery-UI has yet, because it is so new. We all have to wait for third-party authors to write the plugins, or write them ourselves. I've been doing the latter, and sharing them - mostly backfills for annoyances specific to using JQM in native applications that use a webview.

Hi watusiware,

...That is why I asked you if anybody actually uses Chrome on iOS. I think it is a non-issue, because such a small number of users will use something other than Mobile Safari on iPhone.

Although I totally agree with you about the necessity to use or support Chrome on iOS,

Our project is still must support iOS clients that downloaded Chrome,

Can you guess, or do you know if in the future Chrome (iOS)
will be supported on following versions of JQM ?
Or some work around that you can suggest .

Regards,

Dima

jQuery Mobile is used successfully by many PhoneGap projects and other iOS native apps that use the same UIWebView control that Chrome uses. Chrome does not use it's own browser engine, as Apple does not allow that. It simply wraps a UIWebView with user controls, such as address bar.

I use JQM myself in this environment, and have no trouble with it.

Did you try the JQM demo site in Chorme? If it works, then it is almost certainly a problem with your own code.

I would only using JQM 1.2 for this at this point, since iOS got an update to 6.0 recently and updates are always quickly adopted by iOS users, and pretty sure that 1.2 is the only version that was tested in development with iOS 6 browser.

I see a lot of developers here sticking with old, obsolete versions of JQM. While in many cases, it is prudent to stick with "tried and true" versions of software, this is not one of those cases. JQM is unfortunately highly sensitive to browser changes, and the browser makers keep moving the cheese. If you use JQM, you need to commit to keeping-up with new releases or you will be passed-by.