I have found article that skims over this. But my main question is do I need a separate .html file for each screen? I am thinking yes but I would like an unanimous vote. Als
Use multiple single HTML pages. You don't need multiple JS files. Each page should be fully self contained and capable of standing alone. Minify, combine, and compress. Always use a global configuration script on every page. Phone numbers, maps, and emails
href="tel:+1[your telephone number here (numbers only)]"
href="[standard link to google maps here]"
href=mailto:[your email address]
Validate using jQuery Validate Use the ThemeRoller. Use radio button groups instead of select menus. Add Google Analytics Determine which navigation style to use. Don't start with the code.
We have a production jQM site here's how we do things - and yes others may disagree but we found this works for a very large site.
Use multiple single HTML pages, a large multi-page template defeats the benefits of jQM's ajax loading since you're loading all your HTML at the start (unless your site is small)
You definitely want to use ajax loading, jQM only pulls in the code in your <div data-role="page">
BUT this complicates your JS see below
You don't need multiple JS files, BUT you do need to load all your JS at the start, we accomplish this by doing two things: 1. we put an on
listener at the document root, and listen for pageinit/pageshow events. Everytime a page is loaded these are triggered, you also have a handy reference to the current page, and you can use an attr on the page to determine what page it was. 2. Have all the JS in an include of some sort (hopefully you are using PHP, CF or something) and put this on every page, that way no matter which entry point a user browses to your mobile site with, they get all the code loaded
The downside is that all the JS is loaded initially, but minified we find it's no big deal, and if it's really a concern look into RequireJS - plus it makes debugging a breeze since the JS is all there we can easily use the debugger and place breakpoints. If you load JS dynamically on each page you increase the data you need to return on each page transistion and you have ugliness because you reload redundant JS and it's hard to debug dynamic JS.
$(document).on('pageinit pageshow', 'div:jqmData(role="page"), div:jqmData(role="dialog")', function(oEvent){
var pageType = $(this).data('pagetype');
//handle pageinit/pageshow (oEvent.type) for each pageType
This is a very subjective topic but is also becoming a much larger trend. Some prefer single page web sites (mobile apps). The wiki article here does a great job discussing the problem that single page apps solve.
Specifically in JQM, the transitions from one page to the next are much smoother when the data is on the same page. This affect can also be achieved if you prefetch commonly used pages by adding the data-prefetch
attribute to your link.
However it may depend largely on the size of your project. The jQuery Mobile documentation touches on some of the performance issues of large DOMs here.
I think its best to have a different html file for each screen. Not only will it help in maintaining the app code properly and tracking changes, but also prevent dom from becoming bulky as pages will be added when required.
As for js, you can have separate js files during development and debugging, but i'd suggest u should bundle them and minify them before deploying the app and releasing it.