Znalazłem article, który przegląda to. Ale moje główne pytanie brzmi: czy potrzebuję osobnego pliku .html dla każdego ekranu? Myślę, że tak, ale chciałbym jednomyślnego głosowania. Czy to samo dotyczy oddzielnych plików JS?Jaka jest najlepsza praktyka organizowania aplikacji jQuery Mobile?
Edytuj: Aplikacja JQM jest przeznaczona głównie dla administratorów i ról.
Mamy stronę produkcyjną jQM o tym, jak robimy różne rzeczy - i tak inni mogą się z tym nie zgodzić, ale stwierdziliśmy, że działa to w przypadku bardzo dużej witryny.
korzystać z wielu stron pojedyncze HTML, duża matryca wielostronicowy pokonuje korzyści ajax załadunku jQM od czasu jesteś ładuje cały swój kod HTML na początku (chyba, że witryna jest mała)
Ty zdecydowanie chcesz użyć ładowania ajax, jQM tylko ściąga kod w twoim <div data-role="page"> ALE to komplikuje twój JS patrz poniżej
Nie potrzebujesz wielu plików JS, ALE musisz załadować wszystkie swoje JS na początku, osiągamy to przez robienie dwóch rzeczy: 1. umieszczamy detektor on w katalogu głównym dokumentu i nasłuchujemy zdarzeń pageinit/pageshow. Za każdym razem, gdy ładowana jest strona, są one wyzwalane, masz także przydatne odniesienie do bieżącej strony i możesz użyć atr na stronie, aby określić, która strona była. 2. Czy masz wszystkie JS w jakimś pliku (mam nadzieję, że używasz PHP, CF lub czegoś podobnego) i umieszczasz to na każdej stronie, w ten sposób, bez względu na to, który punkt wejścia przegląda użytkownik na twojej stronie mobilnej, dostają cały kod załadowany
minusem jest to, że wszystkie JS jest załadowany wstępnie, ale minified znaleźć to nic wielkiego, a jeśli jest to naprawdę problemem spojrzeć RequireJS - plus to sprawia, że debugowanie wiatr od JS jest tam wszystko, z czego możemy łatwo korzystać z debuggera i umieszczać punkty przerwania. Jeśli dynamicznie ładujesz JS na każdej stronie, zwiększasz ilość danych, które powinieneś zwrócić na każdym transistionie strony i masz brzydotę, ponieważ ładujesz ponownie nadmiarowy JS i ciężko jest debugować dynamiczny 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
Uważam, że najlepiej jest mieć inny plik html dla każdego ekranu. Pomoże to nie tylko w prawidłowym utrzymaniu kodu aplikacji i śledzeniu zmian, ale także w zapobieganiu powstawania dużych ilości stron, ponieważ strony będą dodawane w razie potrzeby.
Jeśli chodzi o js, możesz mieć oddzielne pliki js podczas programowania i debugowania, ale proponuję, abyś ułożył je i zminimalizował przed wdrożeniem aplikacji i jej zwolnieniem.
To bardzo subiektywny temat, ale staje się także znacznie większym trendem. Niektórzy wolą single page web sites (aplikacje mobilne). Artykuł wiki świetnie sprawdza się w rozwiązywaniu problemu, który rozwiązują aplikacje na jednej stronie.
W przypadku JQM przejścia z jednej strony na drugą są znacznie płynniejsze, gdy dane znajdują się na tej samej stronie. Ten wpływ można również uzyskać, jeśli wstępne pobieranie często używanych stron zostanie dodane do atrybutu data-prefetch.
Może to jednak w dużej mierze zależeć od wielkości projektu. Dokumentacja jQuery Mobile porusza niektóre problemy z wydajnością w wersji large DOMs here.
Użyj wielu pojedynczych stron HTML. Nie potrzebujesz wielu plików JS. Każda strona powinna być w pełni niezależna i zdolna do samodzielnego działania. Minimalizuj, łącz i kompresuj.Zawsze używaj globalnego skryptu konfiguracyjnego na każdej stronie. Numery telefonów, mapy i maile
href="tel:+1[your telephone number here (numbers only)]"
href="[standard link to google maps here]"
href=mailto:[your email address]
Weryfikuj jQuery Weryfikuj Użyj ThemeRoller. Użyj grup przycisków radiowych zamiast wybranych menu. Dodaj Google Analytics Określ styl nawigacji, którego chcesz użyć. Nie zaczynaj od kodu.
Bardzo niewiele rzeczy związanych z "najlepszą praktyką" ma "jednogłośny głos". – Chad