I have two HTML files: index.html and settings.html.  Both are multi-page (screen) files.

So, let's say it looks like this:

index.html:

settings.html

I want to use javascript to dynamically go from the visible page (screen) in index.html to a page in settings.html.

If I create a link in "#second" using HTML in index.html:

and a "back" link in settings.html (anywhere),

everything works fine.

So, I'm trying to understand the proper way to replicate in javascript what happens using these HTML snippets.

If I do $.mobile.changePage('settings.html'), only the first screen in that file is loaded into the DOM and nothing else. So, if in the #settings screen (in settings.html), I try to do $.mobile.changePage('#prefs'), it doesn't work because it doesn't exist.  The same behavior happens if I do  $.mobile.changePage('settings.html', {reloadPage: true}) or if I do  $.mobile.changePage('settings.html#settings', {reloadPage: true})

Similarly, to go back, the only thing I can do is history.back() because I don't know which "page" in index.html I came from.  If I do that, it goes to the first page in the index.html file (#first).

I've been through the documentation several times.  I understand that the rel="external" makes it impossible for jQm to do its ajax thing (which is very cool and I use it a lot).

So, the bottom line is that if I'm going to have multiple files, each one should have only one screen in it.  Then, changePage and history.back() will work as expected.

I was thinking that it would be nice to have just a few multi-page files so there would be fewer requests of the server... Do you think that's an issue?

What about performance in phonegap apps?  Am I better off having a large, single HTML file with all the screens in it or individual files, one for each screen?

Thanks for your help.

What about performance in phonegap apps?  Am I better off having a large, single HTML file with all the screens in it or individual files, one for each screen?

There's almost no latency when loading a page. There's no need for multi-page documents.

I do use both data-dom-cache and occasionally data-prefetch in native apps (PhoneGap and Rhodes). I almost always use iScroll, and so with data-dom-cache, users can return back to a page and not lose their place.

Those two will cover most any case where you might be tempted to use a multi-page document.

From the user's standpoint, using data-prefetch is superior to a multi-page document. They get the page they want to see initially more quickly, and then other pages will typically already be delivered by the time the user decides to tap on a link.

A multi-page document might be better for your server. But, are you designing your app for your users, or to minimize server load? If you are delivering pages that the user might or might not ever read, you've already answered the question. You are at least trying to design for the user. So, go all the way and really design for the user, not to minimize server load.

I guess I'm going to have lots of little html files around 

Great frameworks by the way... jQuery and jQueryMobile have made a huge impact on my development projects.

Actually, we are developing a phonegap app plus website access to our services.  We're using yii on the backend.