Мобилни web наспроти мобилни native апликации

Ова е интегралниот текст на презентацијата што ја одржав во рамките на Mobile Monday во „Клубот на новинари“ во Скопје, на 7 ноември 2011.

Оригиналната најава на настапот беше „HTML5 ќе владее со светот“, со што потполно се согласувам.

Многу се изненадив од бројното присуство на колеги -- програмери, воглавно млади луѓе, кои беа заинтересирани за темата. Има надеж.

Би сакал да им се заблагодарам на сите пријатели за добрите зборови по повод презентацијата. Ме натеравте да поцрвенам :)

---

Добродојдовте,

Моето име е Ванчо Орданоски. Јас сум (по редослед) програмер, сакам да возам мотор, претприемач, активист и гик.
Моите координати се:

vordan@infoproject.biz

@ordanoskiv

http://vanco.ordanoski.name

http://instantekspert.blogspot.com

Професионален информатичар сум веќе 26 години, а последниве 22 (заедно со мојот партнер) ја поседувам и ја водам фирмата Инфопроект (http://www.infoproject.biz/).

Денешната тема е посветена на мобилните апликации и разгорената дискусија дали ќе надвладеат оние во web или во native технологија. Ако сакате дефинитивен одговор, ќе ви го дадам: КОМПЛИЦИРАНО Е!

За ова кратко време кое ни е на располагање, се ограничив на трите најважни компликации, кои ќе се обидам да ги објаснам.

Прва компликација, погрешно е можната база на апликации да се гледа само како поделба на Apple и Google корисници, а особено предвид да се имаат само сопствениците на смартфони.
Пазарот е многу поширок од ова (Samsung, Nokia...). На пример, не треба да се занемари Microsoft, кој, иако прилично издишан, има многу средства (пари, програмери, логистика, сопствеништво на Nokia...) и огромна база на корисници за своите останати производи.
Потоа, диверсификацијата на мобилни уреди не оди само хоризнотално (смартфони, таблет-компјутери, итн.), туку и вертикално. Земете го предвид новиот Amazon Kindle Fire, кој е полуотворена платформа, или прилично успешниот Nook на Barnes&Noble.
Постои уште цела планина постоечки или надоаѓачки уреди, на пример GPS-таблет хибриди, уреди за автомобилската индустрија, не-мобилни уреди како што се интернет-енаблирани телевизори, па дури и фрижидери и машини за перење алишта.

Втора компликација. Постојат повеќе од две опции (web наспроти native). Попрецизно, можат да се согледаат барем четири можни технички комбинации:

- Web-базирани апликации. Всушност, се работи за веб-сајт кој е специјално кодиран за одредена платформа или формат на мобилни уреди. Примери за овој вид на апликации се апликацијата на Financial Times, LinkedIn, итн. кои најдобро функционираат на Android и iOS уреди. Пишувани се со стандардните веб технологии, како што се HTML, CSS, JavaScript и сл.
До апликациите се достапува преку веб-прелистувачот на уредот, но можно е да работат во модус на full-screen, каде што „хромот“ на прелистувачот (адресното поле, копчињата, насловот...) не се гледа.
Основен предуслов за нивно функционирање е интернет конекција, бидејќи апликацијата се вчитува од интернет. Втор услов е да постои веб сервер кој ја нуди апликацијата и ги чува податоците. Одредено количество на податоци може да биде сочувано и на самиот уред, особено со воведувањето на новиот, HTML5 стандард.
Главен недостаток е што немаат достап до хардверот на уредот (телефонски функции, GPS, жиро-уредите, итн.), ниту до неговиот датотечен систем (нпр. контакт-листата и други информации), што е оневзможено од сигурносни причини.

- Native апликации. Тие се кодирани во платформски-специфичен програмски јазик (Java за Android, ObjectiveC за iOS, итн.). Се работи за моќни и брзи апликации, но врзани за одредена платформа. За да се пренесат во друга, мора одново да се искодираат, што е и нивен главен недостаток.
Сепак, нивна огромна предност е неограничениот достап до целокупниот хардвер на телефонот, и тоа на ниско ниво. Вообичаено се инсталираат преку „продавници за апликации“ (AppStore), кои воглавно постојат за да може производителот на уредот за земе некој процент од програмерските куќи, но и како контролна брана за малициозен или лошо напишан софтвер.
Незаменливи се кај игрите, особено оние кои бараат брза графика и процесорска моќ.
Не мора да бидат поврзани на интернет за да функционираат, иако во одредени случаи се практично неупотребливи без онлајн-конекција (на пример, апликациите на Твитер и Фејсбук, итн.)

- Хибридни апликации. Овие се потпираат на специјални развојни рамки (frameworks), со кои се овозможува интер-платформска компатибилност, но притоа и достап до хардверот на уредот и неговиот датотечен систем.
Сепак, интер-платформската компатибилност е релативно ограничениа и зависи од универзалноста и понудата на развојата рамка. Познати рамки се jQuery/jQueryMobile, Sencha, Titanium, PhoneGap, ParticleCode, Corona, итн.
За да се користат, ваквиот вид на апликации треба да се инсталира преку AppStore, при што се инсталира и рантајмот на развојната рамка, а потоа поголем дел од апликацијата, и особено податоците, се повлекуваат преку интернет.
Интересен пример за ваков вид на апликација е Dominate на издавачот IGN.

- Генерички web апликации. Всушност, се работи за веб-сајтови кои се направени да работат на било кој мобилен уред, како на пример мобилниот сајт на Wikipedia.
Очекувано, тие се со најширока можна корисничка база, но и со најмала контрола врз мобилниот уред.
Дизајнот на апликацијата мора да биде релативно едноставен, за да се прилагоди на различните екрански формати, вообичаено не се користат никакви хардверски компоненти од уредот (дури ни копчиња), и комплетно се сервираат во веб-прелистувачот на уредот, со мала или никаква можност за локално чување на податоци.

Трета компликација: Што да се избере? Сѐ зависи од тоа во која од следниве три групи припаѓате:
1. Корисници - потрошувачи
2. Компании - обезбедувачи на решенија (провајдери)
3. Програмери
Корисници/потрошувачи
Според истражувачите на Forrester, native апликациите за корисниците се често во улога на „lean-back“, седнати, навалени наназад, додека web-ориентираните се „lean-forward“, подисправени.
Кога консумирате апликација која е длабоко интегрирана со хардверот на уредот, вообичаено седите и ја употребувате, играте, пишувате...
Мобилниот веб, пак, вообичаено се користи за истражување, добивање на информации додека сте во движење.
Но, разликите се намалуваат и замаглуваат. Едниот вид на апликации сѐ повеќе може да го прави она што го може и вториот, и обратно.
На крајот на краиштата, корисникот ја користи апликацијата за да му исполни одредена потреба, или да се забавува со неа. За корисниците, web или native е само индустриски жаргон. Најмалку важна му е технологијата која таа апликација ја користи. Всушност, добро напишаните апликации треба да направат сѐ за да ја скријат својата внатрешна структура и на корисникот да му дадат квалитетно искуство.
Во поглед на начинот на кој одредена апликација се набавува, корисникот може да има помалку или повеќе мака, да изгуби помалку или повеќе време. Во апликациските продавници, апликациите се класифицирани, контролирани, но -- во крајна линија -- не ги содржат сите можни избори, туку само она што таму се наоѓа.
Вебот е многу поширок и полесен за откривање на апликации, тие се инсталираат и употребуваат едноставно, можат да се добијат повеќе можности, но секогаш постои опасност од малициозност и правење на штета, па треба да се биде особено претпазлив.
Компании - обезбедувачи на решенија
Во светот на бизнисот, сѐ е водено од парите, за сѐ се пресметува трошокот и зарабоиката, загубата и добивката. Затоа, кога зборуваме за компаниите, призмата ќе биде „пари“.

Мислам дека тука има најмалку дилеми. Освен ако не сте огромна компанија која може да си дозволи на платен список да држи посебни ергели на програмерски тимови за секоја платформа, веб-апликациите се единственото економично и одржливо решение.
Да, има мали компании кои се обогатиле на native апликации за една од водечките платформи -- iOS или Android, но со навлегувањето на сѐ поголемиот број на алати заа развој на веб мобилни апликации, и со растот на нивниот квалитет, овој резон сѐ повеќе го губи смисолот.
Особено ако компанијата веќе има одредени други не-мобилни веб решенија, природно е да ја прошири понудата кон мобилни веб-апликации.

За пример ќе ја земам мојата сопствена компанија, Инфопроект (признавам, не е баш скромно, но сметам дека ќе докажам зошто е добар примерот).
Инфопроект веќе трета година го развива и го имплементира својот ERP систем наречен Infomatrix. Системот е комплетно изграден во веб технологии, и сѐ што треба корисникот да има на својата, клиентска страна е веб прелистувач. Наскоро, во декември оваа година (2011), во употреба ќе го пуштиме и нашиот SaaS наречен „Бизнис Херој“, кој веќе неколку месеци е во приватна бета имплементација.
Во развој е и Business Intelligence решение кое природно ќе го прошири работењето со системот. Заклучивме дека дел од корисниците ќе сакаат да имаат информации и кога не се блиску до своите десктопи и лаптопи, туку ќе им требаат информации и кога се мобилни.
Веќе создадовме поголема база на корисници на Infomatrix, а со воведувањето на „Бизнис Херој“ таа многукратно ќе се зголеми (очекуваме стотици нови клиенти).
Оваа широка корисничка база, особено онаа на страната на SaaS-от, не може да се контролира во смисол на тоа кои мобилни уреди ќе ги употребува. Очекуваме да се појават сите можни смартфони, таблетни компјутери и слични мобилни уреди.
Создадовме посебна API спецификација за поврзување на мобилни консументи, а единствено економично решение кое го гледаме за обезбедување со мобилни апликации е веб-платформата.
Заклучивме дека немаме буџет, ниту пак на пазарот на работна сила има доволна квалитетна понуда (со сета почит до колегите), за вработување на посебни програмерски тимови кои би развивале native апликации за  секоја платформа посебно. Дури и да се добереме до некој рок-стар програмер, тоа не е доволно. Апликациите треба да се одржуваат долгорочно, на корисниците треба да се дава квалитатна поддршка, а програмерската работна сила е една од најмобилните на пазарот. Чувствуваме дека многу лесно можеме да се најдеме „заглавени“ со native апликација која можеби е добра, но е во ќорсокак поради тоа што програмерот кој ја развивал повеќе не е во компанијата, а друг нема на повидок...
Исто така, поради поголемата потреба за специјализација на програмерите на native апликации, нив ги има релативно малку на пазарот на работна сила, а со тоа им расте цената -- т.е. платата која треба да им ја дадете -- што директно влијае на трошоците на производство.

Следно, што не е помалку важно, native апликациите би требало да ги дистрибуираме низ продавниците за апликации на поедините производители, а тоа знае да биде долг и чувствителен процес, што ќе оневозможи брзи циклуси на издавање на нови верзии на постоечките, како и нови апликации. Замислете да имате native апликација во која се појавил некој катастрофален баг, а вие не можете лесно да ја надградите затоа што, на пример, задолжените во AppStore на Apple не работат во недела и има уште илјада други „итни“ надградби за прегледување. Вашите корисници ќе бидат бесни, и никој нема да биде среќен.

Сепак, не треба да се биде ригиден. Едноставно, има употребни сценарија во кои, едноставно, веб-технологијата нема да биде доволно добра. На пример, кога треба да се користи некој посебен хардверски дел од мобилниот уред, како што е бар-код читач, или GPS модулот, ќе треба да се употребат покомплицирани програмерски техники и, можеби, сосема да се оди во правецот на native апликација.

Во моментов, ние сме потполно насочени кон тоа да овозможиме веб-базирани апликации, форматирани за најчестите формати на мобилни уреди, без оглед дали се работи за смартфони или таблетни компјутери.
Програмери
Ааах, програмери. Ја разбирам дилемата. И јас сум дел од нив. Кој сака да биде успешен, мора постојано да се надградува, да учи нови технологии, нови техники, нови концепти.

Дали да се избере она што во моментот најмногу се бара? Да се специјализирате за одредена платформа? Тоа веројатно ќе донесе добра плата (ако сте добар во тоа што го правите). Но, технологиите се менуваат многу брзо, и можете да се најдете „заглавен“ во ќорсокак: ја знаете секоја дупка и кривина од платформата, а произведувачот одлучил во следната верзија потполно да ја напушти. Прашајте ги безбројните „експерти“ за Visual Basic 6, или сертифицираните инжинери за изумрени оперативни системи -- тие ќе ви кажат многу за ќорсокаците.

Од сите технологии кои се најизгледни во моментов, веб-базираните се на прво место. Последната реинкарнација на HTML стандардот -- HTML5 покажува добро координиран правец и воведува нови можности за програмирање. Респонзивноста на апликациите никогаш не била поголема и побрза. Можностите за манипулација на содржините и богато корисничко искуство никогаш не биле полесни.
Се појави богатство од библиотеки кои овозможуваат директно комуницирање со хардверот на мобилниот уред, локално чување на податоци, кеширање, оптимизација, додатни ефекти, употреба на случки базирани на допир со прсти или стајлуси, итн.
Некои од нив веќе ги споменавме:  jQuery/jQueryMobile, Sencha (која неодамна доби нова рунда инвестиции од RedHat, IBM и други „тешкаши“), PhoneGap, Titanium, Corona, ParticleCode...).
Еден од најдобрите моменти е што повеќето од овие развојни алати се бесплатни. Секој може да започне да развива уште денес. базичното знаење на веб-програмирање мора да се надгради и да се научат спецификите, но сепак, нема други пречки освен вие самите. Што може да биде подобро од тоа?
Илјадници, десетици илјади веб-програмери во светот сѐ повеќе користат HTML5 и пишуваат за мобилни уреди. На интернет има бескрајно многу ресурси за учење и решавање на програмерски проблеми. Практично, не можете да се изгубите. Отидете на Stackoverflow, или на некој сличен сајт и поставете прашање. Најверојатно ќе ви биде одговорено за неколку минути, и тоа во повеќе варијанти!
Вложувањата за започнување на нов проект, па дури и нов бизнис во оваа област се минимални. Не многу скап компјутер или лаптоп, еден мобилен уред за тестирање и интернет конекција. Никогаш не било полесно!
А најубавото е тоа што целиот свет ви е тезга. Можете да продавате надолж и попреку, низ целата планета. Можете да работите од дома, од кафуле, од купатило, ако сакате.
Како се прави iPhone/iPad Web апликација?

И покрај целиот ентузијазам, правењето апликација за мобилни уреди не е баш лесно.
Сепак, секој кој има работено со HTML5, CSS и (задолжително) JavaScript, релативно брзо може да направи своја апликација.
Apple вградил многу тагови и темплити во својот мобилен веб-прелистувач Сафари, за да ја олесни работата. Во најновата верзија на iOS -- 5, вградена е и многу побрза JavaScript машина.
Она што ќе го покажеме овде е само запознавање на можностите, но и на релативната едноставност со која можат да се градат апликации. На Интернет има многу туториали, направете пребарување во Google и ќе добиете готови „кувари“ за покомплексни апликации.
Мета-тагови кои се користат

Апликациите се додаваат на хоум екранот со користење на „+“ копчето во Сафари. Но, она што сакаме е нашата апликација да има „native“ изглед, т.е. да не се гледаат копчињата и адресното поле.
Затоа, треба да се стави следниов таг, некаде во <head> секцијата:

<meta name="apple-mobile-web-app-capable" content="yes">

Сеуште не сме готови, бидејќи апликацијата може да биде зумирана со стискање и ширење на прстите.
Нејтив апликациите не го прават тоа, и, за среќа, Apple измислил и таков таг:

<meta name="viewport" content="user-scalable=no, width=device-width">  

Последната работа која пречи е да се оневозможи екранот да биде „повлечен“ надолу, при што се гледа заднината. За ова ни треба малку JavaScript, која се додава веднаш по почетокот на <body> секцијата:

<script>

function BlockMove(event) {

  event.preventDefault();

}

</script>

Иконка за десктопот

Ова е едноставно: Во графички едитор направете иконка со големина од 72х72 пиксели и снимете ја под името apple-touch-icon.png, во истиот фолдер во кој се наоѓа апликацискиот index.html.
Ова мора да ѝ го „пријавиме“ на апликацијата со следново парче код:

<link rel="apple-touch-icon" href="./apple-touch-icon.png">

Не се мачете да додавате ефекти на иконката, оперативниот систем автоматски ќе ја направи со „сјај“, за да биде слична по стил со останатите.

Проблемот со линкови

Ако користите стандардни линкови во апликацијата, од типот:

<a href="nekoj-link.html">Кликни овде</a>

со допирање на ова, ќе скокнете надвор од апликацијата и директно во Сафари. Се разбира, тоа не е она што го сакаме, а за да го решиме овој проблем, повторно мораме да употребиме малку JavaScript. Во нормални услови, би го користеле onclick event-от, но тоа прави „задршка“ од околу една секунда при допирање на линкот и изведување на акцијата.
Apple го решил ова со додавање на специфичен ontouchstart event, кој го прави токму она што и го очекуваме, реагира на допир со прст и отвора линк, без да излезе од апликацијата.
Идеално.

<a ontouchstart="window.location=nekoj-link.html">Кликни овде</a>

За детектирање на движење на прстот по екранот постои сличен event наречен ontouchmove, итн.

Уште некои совети

• Ако сакате да имплементирате drag-n-drop функционалност, постојат повеќе JS библиотеки кои само треба да ги вклучите при вчитувањето на страницата.

• Избегнувајте големи слики (дури и мали, ако може).
• Не користете CSS градиенти. Ако треба, тогаш цртајте го градиентот во HTML5 <canvas> тагот.
• Слично, избегнувајте и CSS сенчење. За glow и shadow, употребете го <canvas> тагот.
• За анимација, користете CSS, но нека биде едноставна. Сепак, се работи за релативно поспори машини, и хардверското забрзување не е сјајно.
• Избегнувајте CSS провидност (opacity), понекогаш се однесува така што го исклучува хардверското забрзување.
• Користете проверени JavaScript библиотеки, но внимавајте да не бидат преголеми. Пишувајте сопствен JS код, каде што е можно.
• Користете 3D CSS анимации, дури и кога се работи за 2D, бидејќи Mobile Safari нуди хардверско забрзување само за 3D транслации.

Чување на податоци на уредот
За да правиме offline веб апликации, треба да имаме можност на некој начин асетите на аплиакцијата да ги чуваме локално, на самиот уред.
За почеток, потребно е да се направи cache manifest, кој ги опишува сите асети на апликацијата. Во суштина, се работи за текст датотека со содржина слична на оваа:

CACHE MANIFEST
# Offline cache v1
# html files
sodrzina.html

# css files
assets/_styles.css

# js files
assets/_javascript.js

# images
assets/ico_back_arrow.gif

Името на датотеката мора да има наставка myapp.appcache
Каш датотеката во нашата апликација се специфицира вака, веднаш на врвот на страницата:

<html manifest="myapp.appcache">

Многу важно е на web серверот да му се каже кој е mime типот на овој вид на датотеки, за да може коректно да ги интерпретира. Ова е точка која фрустрира многу програмери, затоа што овој чекор често се испушта.
На Apache, тоа се прави во неговата конфигурациска датотека:

# html 5 application cache - offline access

text/cache-manifest appcache

Не заборавајте да го рестартирате Apache-то послед додавањето на овие линии.



За работни податоци, во HTML5 спецификацијата е вграден storage објект за чување на податоци, а различни browser-и можат да сочуваат различни количини на податоци, генерално околу 5 - 10MB.


За поамбициозни проекти, iOS и Android поддржуваат и работа со SQLlite, вистинска релациона база на податоци. Ова зема доста ресурси, но на поновите модели на уреди ќе работи без проблем.
Заклучок

Како што се гледа од изложеното, треба да се биде внимателен програмер, но и оние со помало искуство ќе можат да направат добри апликации.
Доколку ви е потребна поголема контрола врз уредот, како што рековме претходно, користете некоја од неколкуте библиотеки кои ви се на располагање. Оние кои особено се истакнуваат се  jQuery/jQueryMobile, Sencha, PhoneGap и Titanium.

Уште една работа

Мобилните уреди, особено смартфоните, се со ограничени екрани и ресурси.
Не замислувајте апликации кои прават сѐ и сешто, кои имаат премногу функции. Тоа само ќе ја закомплицира нивната употребливост.
При дизајнирање на апликацијата мислете на тоа дека таа воглавно се користи со прсти, кои не се баш најпрецизната можност, и тоа со една рака. Распоредете ги изборите доволно далеку, не правете километарски изборници (менија), вносот на одредени податоци сведете го на минимум.
Вградете „remember this“ функционалност секаде каде што е можно. Корисникот не мора баш секогаш одново да внесува одредени податоци.
Екранот треба да биде јасен, едноставен, без скролирање, табелите да бидат со малку колони и широк падинг помеѓу податоците.
Секогаш прашајте го корисникот ако некои од податоците ќе се чуваат некаде надвор од уредот, и секогаш барајте дозвола да чувате лични податоци во уредот (може и само еднаш, при изнсталацијата, но побарајте).


Со среќа!