Qual è la prassi migliore per organizzare un'applicazione jQuery Mobile?

Question

Ho trovato article che sfiora questo. Ma la mia domanda principale è che ho bisogno di un file .html separato per ogni schermata? Sto pensando di sì, ma vorrei un voto unanime. Inoltre, questo vale anche per i file JS separati?

Modifica: l'app JQM è fondamentalmente destinata agli utenti e ai ruoli.

Answer 1

Abbiamo un sito di produzione JQM ecco come facciamo le cose - e sì altri potrebbero non essere d'accordo ma abbiamo trovato che questo funziona per un sito molto grande.

1. Usa più pagine HTML singoli, un grande modello di multi-pagina sconfigge i vantaggi di Ajax carico del jQm dal momento che stai caricando tutto il codice HTML in partenza (a meno che il sito è piccolo)

2. È sicuramente vuoi usare il caricamento Ajax, jQM inserisce solo il codice nel tuo <div data-role="page"> MA questo complica il tuo JS vedi sotto

3. Non hai bisogno di più file JS, MA devi caricare tutto il tuo JS all'inizio, lo facciamo facendo due cose: 1. inseriamo un listener on nella root del documento e ascoltiamo gli eventi pageinit/pageshow. Ogni volta che una pagina viene caricata, questi vengono attivati, hai anche un utile riferimento alla pagina corrente, e puoi usare un attr sulla pagina per determinare quale pagina era. 2. 2. Avere tutto il JS in un pacchetto di qualche tipo (si spera che tu stia utilizzando PHP, CF o qualcosa del genere) e inserirlo in ogni pagina, in questo modo, indipendentemente dal punto di accesso che un utente visita nel tuo sito mobile, ottengono tutto il codice caricato

il lato negativo è che tutto il JS è caricato inizialmente, ma ridotte di noi troviamo non è un grosso problema, e se è davvero un problema guardare in RequireJS - più si fa il debug di un gioco da ragazzi dal momento che la JS è tutto lì, possiamo facilmente usare il debugger e posizionare i breakpoint. Se caricate JS dinamicamente su ogni pagina, aumentate i dati necessari per il ritorno su ogni pagina di transistione e avete brutto perché ricaricate JS ridondante ed è difficile eseguire il debug di JS dinamico.

$(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 

Answer 2

Penso che sia meglio avere un file html diverso per ogni schermata. Non solo aiuterà a mantenere correttamente il codice dell'app e il monitoraggio delle modifiche, ma eviterà anche che Dom diventi ingombrante poiché le pagine verranno aggiunte quando necessario.
Per quanto riguarda js, è possibile avere file js separati durante lo sviluppo e il debug, ma suggerirei di raggrupparli e ridimensionarli prima di distribuire l'app e rilasciarla.

Answer 3

Questo è un argomento molto soggettivo, ma sta anche diventando una tendenza molto più ampia. Alcuni preferiscono single page web sites (app mobili). L'articolo wiki qui fa un ottimo lavoro discutendo il problema che le app a pagina singola risolvono.

In particolare in JQM, le transizioni da una pagina all'altra sono molto più agevoli quando i dati si trovano sulla stessa pagina. Questo effetto può essere ottenuto anche se si prelavano le pagine di uso comune aggiungendo l'attributo data-prefetch al collegamento.

Tuttavia può dipendere in gran parte dalle dimensioni del progetto. La documentazione di jQuery Mobile tocca alcuni dei problemi di prestazioni di large DOMs here.

Answer 4

Utilizzare più pagine HTML singole. Non hai bisogno di più file JS. Ogni pagina dovrebbe essere completamente autonoma e capace di stare da sola. Minimizza, combina e comprimi.Usa sempre uno script di configurazione globale su ogni pagina. Numeri di telefono, mappe e messaggi di posta elettronica

href="tel:+1[your telephone number here (numbers only)]" 
href="[standard link to google maps here]" 
href=mailto:[your email address] 

Convalida utilizzando jQuery Convalida Utilizzare il ThemeRoller. Utilizzare i gruppi di pulsanti di opzione invece di selezionare i menu. Aggiungi Google Analytics Determina quale stile di navigazione utilizzare. Non iniziare con il codice.