Technologie mobilne w platformach edukacyjnychKOSMIKUS 1.5

STUDIUM PRZYPADKU

Michał ŁukaszewskiSławomir Rodak

Część 1BUSINNES CASE

Cel biznesowy

"Mobile są modne" to nie wymaganie

"Mobile" to ogromne spektrum urządzeń, rozdzielczości, wydajności sprzętowej

Mobile-first? Czy - również? Czy - przy okazji?

Android to koszmar, ale ma większość rynku ("i co pan nam zrobisz?")

Wymagania funkcjonalne powinny być uściślone przed rozpoczęciem produkcji tak bardzo jak to możliwe

Wybór technologii zbyt powiązany z wymaganiami

Zmiana wymagań może w najgorszym przypadku zakopać projekt - może wymusić zmianę technologii i kosztowny refaktoring (w zależności od momentu, w którym zmiana nastąpiła)

Ogrom możliwości?

Trudno znaleźć jedną bibliotekę, która może wszystko

Więc balansujemy pomiędzy możliwościami, a oczekiwaniami

To że dany komponent coś może nie oznacza, że możemy go użyć (bo np. wydajność)

Klęska urodzaju?

Dostępne silniki JS: CreateJS, PaperJS, KineticJS, Phaser, Cocos 2D, Jaws, Solpeo Engine, ImpactJS, iio Engine, Farbric JS, PIXI

Biblioteki JS: jQuery, jQuery UI, Zepto, MooTools, Prototype, ExtJS, Dojo, YUI

Frameworki MVC/MVVC: Angular JS, BackBone, Knockout

Frameworki CSS: bootstrap, Foundation, Pure CSS, Cardinal CSS, Compass

Preprocesory: LESS, SASS

RWD: viewport, media-query

Realne możliwości

Praktycznie rzecz biorąc da się zrobić niemalże wszystko: bajeranckie stronki, prezentacje, singlepage, gry (!), animacje.

Ale bardzo rzadko za pomocą jednego komponentu

Mieszanie komponentów utrudnia rozwój i utrzymanie- konieczne wdrożenie programisty w komponent aby wykorzystać go optymalnie- rosną koszty- rośnie ryzyko błędów- konieczne bardzo szerokie kompetencje albo szeroki zespół)

Ale stosowanie jednej wszystkomogącej biblioteki wszędzie jest bez sensu- zazwyczaj jest duża (jako plik)- niekoniecznie najwydajniejsza- strzelanie z armaty do komara

Na co Cię stać?

Sky is the limit?

Nope - the enviroment

Wydajność niektórych bibliotek jest denna (ilość klatek/żądań na sekundę vs. RAM + obciążenie CPU)

Same różnice pomiędzy PC dają w kość

Urządzenia mobilne to koszmar

Tablety z Biedronki

Zetaphony

Przykład - przeglądarki desktop

Minimalne wersje przeglądarek

Chrome +23 (Blink: post-WebKit)

FF +20 (Gecko)

IE +10 z bólem, IE11 bardzo dobrze (IE9 do najprostszych stron, IE8 nie, nie, nie)

Opera 12 (Presto) - śmieć, ale już Opera +15 (WebKit) jest ok

Safari +6 (WebKit) - OK, ale tylko iOS; na Win jest max 5: nie OK.

Win XP to ciągle ok 30% rynku OS na dektopach - więc np. IE8 to max. - i co z tym fantem zrobić?

Urządzenia mobilne

iOS jako referencyjny (jak to powinno wyglądać i działać).

ale - opieranie się na iOS nie jest wystarczające, nawet jeśli ktoś lubi iOS lub klient ma i musi u niego wyglądać .

W przypadku produktu uwzględniającego telefony na rynek PL musimy brać pod uwagę WP (bo ma ok 30% rynku i rośnie). 

W przypadku EU - różnie w zależności od kraju (np. Hiszpania ma duży udział WP, inne kraje mają inny rozkład)

Android najważniejszy, bo ma największy udział globalny i to się w najbliższym czasie nie zmieni.

ale - Android nie może być punktem odniesienia, bo segmentacja jest ogromna. Działanie i wygląd w zależności od wersji mogą być bardzo różne - duże koszty. Ale uwzględniać i testować trzeba - potrzeba też szerokiej palety urządzeń. Nexusy jako punkt odniesienia dla Androida .

Segmentacja wersji Androida

Stan na 2.12.2013, dane za: developer.android.com

Wzrost WP

WP jako nr 2 wśród telefonówIndie, Meksyk, Włochy, Chile, Tajlandia, Wietnam, Malezja, Polska, RPA, Ukraina, Węgry, Finlandia, Czechy, Grecja

WP przewyższył sprzedaż iPhoneChile, Kolumbia, Czechy, Egipt, Egipt, Finlandia, Grecja, Węgry, Indie, Włochy, Kenia, Kuwejt, Malezja, Meksyk, Nigeria, Pakistan, Peru, Polska, Arabia Saudyjska, RPA, Tajlandia, Ukraina, Zjednoczone Emiraty Arabskie, Wietnam

Dane na 4Q2014 za Microsoft i adduplex

ALE

głównie modele budżetowe (Lumia 520, 620, 625)

Backend

Backend ma poślednie znaczenie, o ile są kompetencje w firmie

PHP 5.4 i następne dobrze nadaje się do współpracy z GUI mocno opartym o JS

node.js - jeden język programowania po stronie FE i BE, ale ciągle dość świeże rozwiązanie (też ma swoje limity).

Bazy danych bez znaczenia.

Kosmikus 1.5 - technologie

HTML5

Bootstrap 2 (wersja 3 - wydana w trakcie trwania developingu)

jQuery

Create JS (pozwolił na łatwe przejście programistom ActionScript)

SVG Animations (bezkosztowo, dzięki Google Swiffy; przykład)

RWD w oparciu o viewport (całość) i media-queries (częściowo, per typ widoku)

Korzyści- Wygląda ładnie- Minimalna ilość technologii, wygodna separacja kompetencji

Wady- Niektóre ekrany ciężkie: najcięższy ok 3MB + XHR = ~6MB do ściągnięcia - Canvas by Create JS + ponad 300 elementów do wyboru przez użytkownika.- FF vs niektóre animacje na Canvasach ledwo dyszy (inne przeglądarki lepiej, IE11 najwydajniejszy)- Ułomne technologie (np. wprowadzenie dźwięku do animacji)- Błędy i ograniczenia bibliotek: wprowadzaliśmy autorskie zmiany, które trafiły do oficjalnego wydania z opóźnieniem w stosunku do planu wydawniczego mijając się z naszym . - brak kompatybilności wstecz (bootstrap 3 vs boostrap 2)

Podsumowanie

Inwestowanie w nowe technologie czy stosowanie rozpoznanych rozwiązań?

Kryteria wyboru nowej technologii- "próg wejścia"- reużywalność w ramach organizacji- "próg wyjścia"- zaangażowanie zespołu- popularność- wsparcie producenta

Zakres nowych technologii w projekcie

PoC

Kto nie ryzykuje ten nie ma

Cel biznesowy jest zbieżny z celami technologicznymi

Część 2TECHNOLOGY CASE

Silniki JS

Warstwa kompetencji

Możliwe zastosowania

Silniki JS

CreateJS

Dema

http://www.createjs.com/#!/TweenJS/demos/tweenCircles

http://www.createjs.com/#!/EaselJS/demos/spritesheet

http://www.createjs.com/#!/EaselJS/demos/gamehttp://www.createjs.com/#!/EaselJS/demos/cache

http://www.createjs.com/#!/TweenJS/demos/tweenCircles

http://www.createjs.com/#!/SoundJS/demos/soundGrid

http://www.createjs.com/#!/SoundJS/demos/explosion

http://www.createjs.com/#!/SoundJS/demos/visualizer

Wszystkie potrzebne komponenty (bitmapy,sprites,animacje,dźwięk)

Integracja z Flash

Źródła na GitHub

Niski próg wejścia

Wersja 0.51 (0.4 przy starcie prac)

Wolne działanie

Brak komponentów do formularzy - nie najlepsza integracja z elementami DOM

Silniki JS

Paper JS

Dema

http://paperjs.org/examples/nyan-rainbow/

http://paperjs.org/examples/meta-balls/

http://paperjs.org/showcase/

Obsługa wektorów i bitmap

Matematyczno - wektorowy

Źródła na GitHub

Brak obsługi dźwięków

Silniki JS

Kinetic JS Szeroki wachlarz funkcji (obrazy,sprites,animacje,eventy,warstwy, filtry,selektory)

Źródła na GitHub

Spójny

Brak obsługi dźwięku

Wbrew obietnicom - nie jest szybki

Silniki JS

Phaser

Dema

http://grimpanda.com/games/sandbox/connectme-sfx/

http://www.bbc.co.uk/cbeebies/peter-rabbit/games/peter-rabbit-hide-and-seek/

http://gametest.mobi/phaser/examples/_site/view_full.html?d=filters&f=fire.js&t=fire

Silnik do tworzenia gier

Zawiera wszystko co trzeba (nawet dźwięk)

Renderowanie na CANVAS i WebGL (Pixi.js)

Źródła na GitHub

TypeScript

Kompletny silnik do wytwarzania gier

322kB - po kompresji

Silniki JS

Cocos 2D

Dema

http://www.cocos2d-x.org/games/all?p=15

Kompletny silnik do tworzenia gier

Źródła na GitHub

Wysoki koszt wejścia

Silniki JS

Solpeo Engine

Dema

http://ck.solpeo.com/

Produkt polski

Zwarta dokumentacja

Silnik gier 2D/3D

Nie wiadomo w jakim stadium rozwoju jest produkt

Silniki JS

Impact JS

Dema

http://phoboslab.org/#games

http://impactjs.com/games

Kompletny framework do gier

Edytor poziomów, fizyka, dźwięki

Dokumentacja

Dojrzały projekt

Płatny (99$)

Silniki JS

PIXI

Dema

http://www.pixijs.com/examples/

http://www.goodboydigital.com/pixijs/bunnymark/

https://github.com/GoodBoyDigital/pixi.js/

Silnik graficzny

Bardzo szybki

CANVAS + WebGL

Dokumentacja

Źródła na Github

Silnik graficzny

Biblioteki JS

Warstwa kompetencji

Możliwe zastosowania

Biblioteki JS

jQuery Doskonała obsługa zdarzeń

Świetna obsługa DOM

Doskonała obsługa komunikacji asynchronicznej via Ajax

Powolny (req per sec)

Różna jakość pluginów

Biblioteki JS

jQuery UI Ogromne możliwości

Ogromna baza pluginów

Możliwość customizacji FW

Bardzo ciężki

Customizacja utrudnia kontrolę możliwości

Pluginy różnej jakości

Biblioteki JS

Zepto Leciutki (~9kB skompresowany)

Kompatybilny z jQuery

Zaprojektowany jako alternatywa dla jQuery dla mobilek

Pełne wsparcie tylko dla najnowszych przeglądarek

Relatywnie niewielki zakres możliwości

Brak wsparcia dla IE < 10

Biblioteki JS

Dojo Bardzo rozbudowane środowisko (Dojo Toolkit, od prostych pluginów po kompletne widgety - Dijit, Dojox)

Możliwość dobierania komponentów wg potrzeb, rozszerzeających możliwości core

Używany w dużych projektach komercyjnych

Alternatywny do jQuery wszystkomogący FW

Bardzo złożone środowisko, tylko do dużych, złożonych projektów

Kontrolery widoku

Angular JS Implementuje MVC tam gdzie dotychczas go nie było

MVVM (Model-View-ViewModel)

Upraszcza część back-endową

Obecnie wspierana i firmowana przez Google

Wysoki próg wejścia

Kontrolery widoku

Backbone

Knockout

Frameworki CSS

Warstwa kompetencji

Możliwe zastosowania

Frameworki CSS

Bootstrap Oparty o grid - duża wygoda

Relatywnie łatwo skalowalny

Dostarcza pełny LESS

Opiera się o grid - ograniczenia

Wymusza LESS

Brak kompatybilności wstecz pomiędzy wersjami 2 a 3

Frameworki CSS

Foundation Mobile First (od v.4)

Więcej wbudowanych komponentów

Technologicznie, krok do przodu

Real fluid layout

SASS - więcej możliwości

Znacznie mniej popularny niż Bootstrap

SASS - ciężka składnia

Frameworki CSS

Pure CSS Małe rozmiary

Skin Builder

Brak źródeł: LESS,SASS

Stosunkowo mała popularność

Frameworki CSS

Semantic Idea semantycznego kodu

Ładny na starcie (w przeciwieństwie do Foundation)

LESS

Semantyczność - poprzez nazwy klas :)

Popularność

Preprocesory

Warstwa kompetencji

Możliwe zastosowania

Preprocesory

LESS Bardzo łatwa składnia

Niezła dokumentacja

Bardzo duże możliwości

Bardzo popularny, vide źródła bootstrap

Łatwo spuchnąć wynikowy CSS

Przy dużych, zaawansowanych zestawach trudno zachować kontrolę nad tym co gdzie jest

Przy zaawansowanych układach bywa mało czytelny

Preprocesory

SASS Główne zalety i wady jak w LESS

Trudniejsza składnia, oferująca jednak więcej możliwości

Mniej popularny

Preprocesory

Coffee Script Ułatwia pisanie zaawansowanych, wieloplikowych rozwiązań JS

Specyficzna składnia, teoretycznie dążąc do ECMA, w praktyce własny narzut

Niepomijalny koszt wejścia

RWD

Warstwa kompentencji

Możliwe zastosowania

RWD

viewport Podstawowy mechanizm skalowania

Nie wymaga fw css

Dobra dokumentacja

IE wie lepiej

RWD

media queries Ogromne możliwości manipulowania renderowaniem elementów oraz układem per rozdzielczość

Łatwo zabagnić CSS

W praktyce: konieczność stosowania preprocesorów CSS

SEO/SEF

Ajax vs SEO

FW2 vs SEF

Canvas vs SEF

HTML5

location vs replace

Urządzenia mobilne

iOS i Windows na tabletach są spoko: konkretne rozdzielczości, konkretne przeglądarki, łatwo ogarnąć.

iOS na telefonach i WP wcale nie muszą renderować strony tak samo jak przeglądarki na tabletach (dotyczy też Win RT vs WP)

Android to koszmar: nasz mega kwiatek - różnice w działanie JS  na tej samej przeglądarce pomiędzy 4.0.3 a 4.0.4

Nexusy jako podstawa testów dla Androida albo śmierć przez walenie głową o klawiaturę .

Backend

Backend nie ma krytycznego znaczenia

Jeśli jest kasa i kompetencje można eksperymentować

PHP min. w wersji 5.4, wyższe lepsze (wbudowany OpCache, listy asocjacyjne ) - np. możliwość posługiwania się listami = mniej konwersji w komunikacji z GUI opartym na JS (spójny wygląd kodu po stronie BE i wynikowej - ułatwione debugowanie)

Bazy danych bez znaczenia, ale jeśli aplikacja (i budżet) pozwala można np. rozważyć noSQL posługujący się składnią JSON - ponownie jedna składnia itp.

Można rozważyć node.js - jeden język po stronie BE i FE, ale kwestie wydajnościowe, load balancing: nie wierzyć w foldery reklamowe, kopać mocno pod kątem problemów i wąskich gardeł, które będą zbliżone do tych jakie będziemy mieli w aplikacji.

W praktyce - nie szalej.

Wybór technologii

Inwestowanie w nowe technologie czy stosowanie rozpoznanych rozwiązań?

Kryteria wyboru nowej technologii- "próg wejścia"- reużywalność w ramach organizacji- "próg wyjścia"- zaangażowanie zespołu- popularność- wsparcie producenta

Zakres nowych technologii w projekcie

PoC

Kosmikus 1.5 Bootstrap 2

- wystarczający zakres funkcjonalności- brak możliwości migracji do Bootstrap 3

Create JS- bardzo łatwe wejście dla programistów Action Script- braki lub niedoskonałości w zaskakujących miejscach- nonszalanckie podejście do planu wydawniczego- animacje w zależności od przeglądarki mogą ubić procesor- konieczność stosowania XHR dla mediów

SVG animations - animacja sobie, dźwięk sobie.

jQuery- bardzo wygodny do podstawowej manipulacji DOM- dobrze współpracujący z CSS- eventy - najmocniejsza strona- bardzo wygodna obsługa ajax'a, ale trzeba uważać, żeby pisać zgodnie z bieżącymi zaleceniami obsługę zdarzeń powrotnych- niektóre pluginy (np. Validator) mają słabą wydajność, ale za to działają np. z nietypowymi mailami

LESS- ogromna wygoda w zarządzaniu CSS'ami (których jest sporo)- trzeba mieć dużą samokontrolę bo łatwo niechcący mocno spuchnąć wynikowy CSS (zwłaszcza przy wejściu w media query)- minimalizacja wynikowego CSS by default (konsole dev w przeglądarkach są do sprawdzania i testowania, efekty nanoszone są do LESS, CSS nikt nie rusza)

RWD- viewport jako podstawa - obejście problemu ze skalowaniem Canvasów- media queries - oszczędnie, dla konkretnych elementów gdzie warto było zmienić ich wzajemny układ.

Kosmikus 1.5

Komunikacja backend - frontend

Ustandaryzowane obiekty JS wstrzykiwane w kod strony

Specjalizacja obiektów JS podawanych scenie- obiekt użytkownika- dane "konfiguracyjne"- dane aplikacyjne (np. język)- dane sceny (np. media)- dane o callbackach per akcja na scenie

ajax do walidatorów formularzy rejestracyjnych/profilowych i na niektórych stronach wewnętrznych (tam gdzie to ułatwiało i/lub przyspieszało działanie strony)

dla FW2 konieczność własnego layout.php- oryginalny ma przestarzały układ (CSS, JS, osobny <script> dla każdego addScriptCode; wszystko w head)- powinno być: CSS w head, JS-libs oraz JS-code przed </body> (w tej kolejnosci)

Ścisła (samo)kontrola - JS-code zawsze via addScriptCode, nigdy przez tpl; efektem jest możliwość kontrolowania kolejności kodu na wynikowej stronie, uruchamianie silnika JS once-per-view.

Oznacza to generowanie JS przez PHP - specjalizowane moduły i komponenty do (de)kompozycji jako dobra praktyka.

Kosmikus 1.5

Programowa blokada przeglądarek w zbyt niskich wersjach (oparta o browsecap)

Programowa blokada urządzeń o zbyt niskiej rozdzielczości (min 1024px szerokości, badane przez JS) - bye, bye tablety z Biedronki.

Zasłanianie contentu (Empiria) w orientacji portrait (problemy ze skalowaniem)

Widoki administratorów, sprzedawców, rodziców czy nauczycieli mają RWD w wersji minimum - opierają się na minimalnej szerokości i viewport: niższe koszty, łatwiejsze projekt i realizacja.

Jakość kodu FE

Javascript nie jest już dodatkiem do zabezpieczenia formularzy tylko pełnoprawnym językiem

Dotyczą go wszystkie zasady dobrego programowania jakie znamy z innych języków

Wzorce i antywzorce

CleanCode, SOLID itp, itd

Podział funkcjonalny - warstwy, komponenty, biblioteki

Zależności: DI, promises, overload i override

BDD i testy automatyczne

Jeden duży plik vs szereg mniejszych (require.js)

Wnioski

Technologie mobilne wymuszają nieustanne i sprawne poszerzanie swoich kompetencji

Zawsze będą specjaliści w danym obszarze, ale trzeba rozumieć oczekiwania BE vs FE aby optymalnie dobierać rozwiązania i je implementować

Biznes nie ma szans tego ogarnąć (mają swoje obszary, ten jest nasz)

Rola technicznych w procesie kształtowania wymagań może być krytyczna

Rolą technicznych nie jest rzucanie kłód pod nogi (" sięnieda") tylko kompilowanie dużych obrazków i szukanie rozwiązań, którymi da się je narysować. Lub nie. I co wtedy?

Nie straszymy problemami, tylko szacujemy roboczogodziny

Biznes musi ufać technicznym, techniczni muszą być godni zaufania

Może być tak, że nawet coś trudnego, ale możliwego do zrealizowania będzie ok mimo sporych kosztów: techniczni nie kształtują wartości biznesowej, choć mogą ją podpowiedzieć

Techniczni pilnują też grafików, którzy w trakcie kreacji mogą pominąć aspekt RWD - zawsze jest złoty środek, o ile sygnalizuje się potencjalny problem odpowiednio wcześnie.

Pisz od razu optymalnie; kasy na optymalizację nigdy nie ma, gdy nie ma wartości dodanej dla biznesu.

Literatura i zasobySilniki JS

CreateJShttp://www.createjs.com

PaperJShttp://paperjs.org/

KineticJShttp://kineticjs.com/

Phaserhttp://phaser.io/

Cocos 2Dhttp://cocos2djs.org/

Jawshttp://jawsjs.com/

Solpeo Enginehttp://www.solpeo.com/

Literatura i zasobySilniki JS

Impact JShttp://impactjs.com/

iio Enginehttp://iioengine.com/

Fabric JShttp://fabricjs.com/

PIXIhttp://www.pixijs.com/http://www.goodboydigital.com/pixijs/storm/http://www.goodboydigital.com/pixijs/examples/11/http://www.goodboydigital.com/pixijs/examples/12-3/http://www.goodboydigital.com/to-dom-or-not-to-dom/

Literatura i zasobyZestawienia

http://ntt.cc/2011/01/31/66-open-source-javascript-game-engine-for-serious-developers.html

http://www.backslash.gr/content/blog/webdevelopment/7-10-javascript-canvas-frameworks

Literatura i zasobyBiblioteki

jQuery - (http://jquery.com/)

YUI - (http://yuilibrary.com/)

Dojo - (http://dojotoolkit.org/)

ExtJS - (http://www.sencha.com/products/extjs/)

Prototype - (http://prototypejs.org/)

MooTools - (http://mootools.net/)

Zepto - (http://zeptojs.com/)

jQueryUI - (http://jqueryui.com/)

Literatura i zasobyFrameworki MVC

AngularJS - (http://angularjs.org/)

Knockout -  (http://knockoutjs.com/)

Backbone - (http://backbonejs.org/)

Literatura i zasobyZestawienia

http://jonathanmh.com/best-javascript-mvc-frameworks-2013-2014/

http://www.infoworld.com/d/application-development/the-10-hottest-javascript-framework-projects-228335

http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks

Literatura i zasobyFrameworki CSS

Bootstrap - (http://getbootstrap.com/)http://acc15.kosmikus.pl/http://questrunner.ydp.eu/http://nedu.ydp.pl/http://getbootstrap.com/getting-started/#examples

Foundation - (http://foundation.zurb.com/)

Pure CSS - (http://purecss.io/)

Cardinal CSS -(http://cardinalcss.com/)

Compas - (http://compass-style.org/)

Literatura i zasobyPreprocesory CSS

LESS - (http://lesscss.org/)https://svn.intranet.ydp/ydp/projects/kosmikus/branches/1.5.x/less/kosmikushttp://lesscss.org/#-variableshttp://lesscss.org/#-mixinshttp://lesscss.org/#reference

SASS - (http://sass-lang.com/)

Literatura i zasobyZestawienie

http://www.sitepoint.com/top-10-front-end-development-frameworks/

http://www.sitepoint.com/top-10-front-end-development-frameworks-part-2/

Literatura i zasobyPrzeglądarki vs technologie mobilne

http://caniuse.com/

http://html5test.com/

Literatura i zasobyRWD - kontrola nad ekranem

https://developer.mozilla.org/en-US/docs/Mozilla/Mobile/Viewport_meta_tag

http://css-tricks.com/snippets/css/retina-display-media-query/

http://msdn.microsoft.com/en-us/library/windows/apps/hh453816.aspx

http://blog.kamilbrenk.pl/meta-tag-viewport-kiedy-i-jak-uzywac/