Tym razem spojrzałem na koncepcję zawartą w Building Modern Mobile Web Apps. Jakieś ogólne wrażenia? Trzeźwy, miejscami wręcz smutny, produkcyjny realizm bez popadania w entuzjazm odnośnie najnowszych osiągnięć z HTML5 i CSS3. Co jest zrozumiałe, bo za cel postawiono sobie możliwość obsługi w jakimś stopniu jak największej liczby mobilnych urządzeń, także tych starszych, sprzed kilku lat… O ile zrobienie uniwersalnej webowej aplikacji wspierającej w miarę nowe standardy, wymaga pewnej rozwagi, o tyle zrobienie mobilnej aplikacji webowej wiąże się z parokrotnie większą złożonością zadania. Oprócz większych różnic i ograniczeń przy wspieraniu nowych standardów HTML5 i CSS3, dodatkowo dochodzą znane nie od dzisiaj przypadłości związane z urządzeniami mobilnymi tj. limitowany ilościowo dostęp do sieci, który może być wolny; mniejsza wydajność itp. Tak więc nadal w wielu przypadkach nie wystarczy zmienić tylko layout i wygląd strony w CSS, by cieszyć się na danym urządzeniu szybką i odpowiednio wyglądającą stroną Web. Czasami trzeba zmienić pewne koncepcje, zrezygnować z części używanych bibliotek itp.
A teraz parę rzeczy, na które chciałem zwrócić uwagę.
W temacie pisania aplikacji mobilnych pojawia się często pytanie, czy pisać natywne czy może lepsza byłaby aplikacja webowa w HTML5. Jest na to oczywista odpowiedź, że jest to zależne od naszych wymagań, naszych możliwości i na jakim zbiorze urządzeń chcemy udostępniać nasze oprogramowanie. Wiadomo HTML5 jest najbardziej uniwersalny i tańszy niż dobre rozpoznawanie każdej z platform z osobna, ale strony webowe nadal nie mają dostępu do różnych funkcjonalności urządzeń, nie pozwalają na dokładnie taki sam user experience jak aplikacje natywne. Pewnym kompromisem między aplikacjami natywnymi a webowymi są aplikacje hybrydowe. Są to aplikacje natywne zawierające kontrolkę przeglądarki webowej, które zazwyczaj używają frameworków opakowujących w JavaScript część natywnej funkcjonalności (wiele urządzeń pozwala z poziomu kontrolki odwoływać się do natywnej aplikacji).
Device APIs Working Group - powstające standardy pozwalające stronom HTML korzystać z kolejnych funkcjonalności urządzeń
Frameworki do tworzenia międzyplatformowych rozwiązań
- http://floatlearning.com/2011/07/which-cross-platform-framework-is-right-for-me/
- http://www.amlcode.com/2010/07/16/comparison-appinventor-rhomobile-phonegap-appcelerator-webview-and-aml
Bogaty, niezależny od platformy interfejs.
Przydatne preprocesory: LESS, Sass
We used the number input type to improve the user experience on supported browsers. Using this input type triggers a numeric keyboard on many touch browsers, and constrains keyboard input to numbers only on many QWERTY or T-9 devices.
We chose not to implement HTML5 form validation, as support for this feature on target browsers was poor and the specification insufficient for our particular needs. We also already had robust server-side data validation in place using ASP.NET.
We chose not to implement the HTML5 date input type, as support was inconsistent on our target browsers. We instead implemented the range feature using two select menus, each prepopulated with a month and date value.
It’s possible to detect support for this input type using a JavaScript feature test, but due to spotty implementation, a large number of devices return a false positive. These devices pass a feature test for the date input type, but only display a simple text input field.
Placeholdery: placeholder według W3C nie powinien być używany do danych liczbowych
Własne widgety wejścia - możliwe, ale najlepiej unikać
Obrazki
- CSS Sprites
- Umieszczanie zakodowanych obrazków w atrybutach data-* (przydatne narzędzia typu “data uri generator”)
- SVG i Canvas - nadal różnie wspierane
- Dostarczanie różnych wersji w zależności od gęstości pikseli
There will be no single, pixel-perfect reference version of the design. Each device (and browser) will render the design to the best of its capabilities.
The first benefit comes from a mobile-first approach to structuring your style sheets. Most smartphones now include a browser that supports CSS media queries, but users may be using an older device, or a low-cost feature phone. A mobile-first approach structures your CSS so that the smallest, and least capable device doesn’t receive the styles destined for more capable devices.
When developing an explicitly mobile experience, it’s a best practice to provide users with an easily discoverable link to the original desktop web app. This is useful for several reasons:
- Mobile devices are typically small, so it’s not always possible to include the same content and features that were found in the desktop version. Users may therefore be looking for something quite specific from the original app and it’s important to provide them a means of accessing it.
- Despite your best efforts, the mobile optimized version may not be suitable for a user’s device. It’s unlikely the (typically far heavier and more complex) desktop app will perform any better, but as mobile devices vary greatly in their capabilities, access to the desktop version may be useful to certain users.
- Many explicitly mobile experiences are accessed using a subdomain or different URL (e.g. m.domain.com, domain.com/mobile). Users on blogs or social networks may share this URL and it’s therefore possible users will reach your mobile site accidentally after clicking such a link. Successfully detecting and rerouting these users may not always be possible, so it’s important to have this link in place.
Obsługa różnych przeglądarek i urządzeń
- user-agent + korzystanie z baz danych o przeglądarkach po stronie serwera
- wykrywanie funkcjonalności po stronie klienta
Remember as well that mobile devices have much slower CPUs and significantly less RAM than their desktop counterparts. You may therefore not be able to use a library in the same way as you would have on the desktop. Just because the library supports an animation, effect, or transition, doesn't mean it will make sense to use it in a production environment. This is particularly true of animations and transitions performed using JavaScript (as opposed to those using CSS).
Autorzy wybrali frameworki: mobilne jQuery, Mustache (lekkie templetowanie)
Single Page Application (SPA)
Single page applications have become very popular. As a consequence, there are many JavaScript frameworks and libraries that are specifically intended to support this pattern. In general, they are often referred to as "JavaScript MVC". Some popular frameworks at the time of writing are:
Those of you following the HTML5 specification may ask why we choose to use the hashchange event instead of the newer (and better) pushstate. Our reason was simply that some of our targeted devices did not support pushstate, whereas they all supported hashchange. There are libraries such as history.js that will attempt to use pushstate and fall back to hashchange only as necessary. However, we wanted to avoid taking another external dependency. In general though, using pushstate is preferred over using hashchange because it allows URLs to be consistent between SPAs and their more traditional counterparts.
The jqPlot library was not used in the Mileage Stats Mobile web app due to its size (more than 200KB minified and gzipped). Charting libraries such as flot and Flotr2 were also considered but were not utilized in Mileage Stats Mobile due to limited support across the set of target browsers. In order to provide a consistent and predictable solution to all target browsers, the server-side rendered chart technique was chosen.
Posty
Brak komentarzy:
Prześlij komentarz