Scrieți o dată, implementați peste tot: când să deveniți nativ?

Write Once, Deploy Everywhere (WODE) a fost promisiunea multor cadre de dezvoltare în ultimul deceniu, al căror scop este să ușureze durerea de a scrie mai multe aplicații native. Determinarea căii pe care să o ia este una dintre cele mai critice decizii pe care trebuie să le ia un manager de proiect din cauza costului ridicat de pornire, a impactului asupra echipei de dezvoltare și a potențialei imposibilități de inversare.

Soluțiile hibride, cum ar fi Ionic, folosesc tehnologiile web pentru a reda aplicații pe platforme, dar, de multe ori, produsul final nu corespunde așteptărilor unui utilizator cu privire la un aspect și o senzație nativă .

Cu toate acestea, chiar și termenul „nativ” a fost recent tulburat de cadre care se compilează până la cod nativ (de exemplu, React Native, Xamarin etc.).

Acest articol prezintă avantajele și dezavantajele diferitelor căi de dezvoltare pentru dispozitive mobile și le cântărește în raport cu componența echipei, costurile și experiența utilizatorului, într-un efort de a oferi managerilor de produse capacitatea de a lua o decizie mai informată.

Scrie o dată, implementează peste tot

Conceptul de Write Once, Deploy Everywhere se referă la capacitatea unei echipe de dezvoltare de a scrie o aplicație o dată — folosind o singură stivă de dezvoltare, rezumat al platformei (platformelor) pe care va fi implementată aplicația — și totuși să mențină capacitatea de implementare. aplicația pe toate platformele dorite, de exemplu, Android, iOS, Windows etc. În mod ideal, acest lucru este realizat fără a sacrifica mentenabilitatea, performanța sau experiența utilizatorului (UX).

Metoda alternativă - și istorică - de dezvoltare a aplicațiilor mobile implică procesul simplu de a scrie o aplicație separată pentru fiecare platformă, care, desigur, poartă cu ea propriul potențial cost ridicat de timp și resurse.

În general, factorii de luat în considerare atunci când alegeți o cale de dezvoltare includ:

• Vechimea proiectului
• Compoziția și dimensiunea echipei de dezvoltare
• Platforma(e) dorită(e) pentru distribuție
• Timp necesar pentru piață
• Lățimea de bandă disponibilă pentru a schimba pe altă cale dacă este necesar

Din păcate, aplicarea fiecăruia dintre acești factori la fiecare dintre căile disponibile, precum și trecerea prin nenumăratele de opinii disponibile despre subiect, poate fi destul de descurajantă. În plus, acest proces lasă adesea managerului de proiect un sentiment de incertitudine cu privire la calea cea mai bună pentru a îndeplini cerințele aplicației.

La un nivel înalt, diferitele căi de dezvoltare mobile pot fi împărțite în două categorii: native sau WODE, adică native sau orice altceva. Mai simplu, fie scrie o aplicație nativă, fie nu. Categoria WODE este împărțită în două grupuri:

• Cadre hibride - cele care folosesc tehnologiile web pentru a reda aplicații pe mai multe platforme.
• Cadre non-hibride - cele care folosesc componente native ale interfeței de utilizare (de exemplu, butoane, câmpuri de text și chiar manageri de aspect) în loc să redă o vizualizare web în interiorul unei aplicații, așa cum fac cadrele hibride.

Majoritatea cadrelor WODE sunt hibride ; cu toate acestea, pentru a îmbunătăți atât performanța, cât și limitările UX ale cadrelor hibride, oferind în același timp beneficiile unui cadru WODE, tendința actuală este către non-hibrid . Datorită acestei tendințe, cadrele precum React Native, Xamarin și Appcelerator câștigă popularitate.

Fiecare dintre aceste căi – nativă, hibridă și non-hibridă – are puncte forte și puncte slabe diferite și, ca urmare, fiecare are cazuri de utilizare diferite pentru care este cel mai potrivit. Restul acestui articol prezintă avantajele și dezavantajele fiecărei căi de dezvoltare pentru dispozitive mobile atunci când se iau în considerare prioritățile concurente, cum ar fi formarea echipei, costul proiectului și UX. Cu excepția câtorva cazuri de utilizare specializate, scrierea aplicațiilor native maximizează experiența utilizatorului la un cost puțin mai mare.

În general, se aplică zicala „ obții ceea ce plătești ”, așa că dacă costul contează mai mult decât experiența clienților, nativul poate să nu fie alegerea potrivită. Cu toate acestea, odată ce UX devine vital, aplicațiile native devin alegerea clară, deoarece, pentru a îmbunătăți UX, aplicațiile bazate pe WODE suportă un cost considerabil sub formă de timp sau expertiză nativă, ceea ce înfrânge scopul de a alege un non-nativ. calea de dezvoltare în primul rând.

În plus, chiar dacă acest cost este plătit, produsul final bazat pe WODE va ​​oferi întotdeauna un UX inferior în comparație cu omologul său nativ. Ca rezultat, nativul este aproape întotdeauna alegerea potrivită pentru majoritatea echipelor de dezvoltare și pentru majoritatea proiectelor.

Aplicații native

Aplicațiile native sunt scrise în limbajul de bază al platformei date. De exemplu, aplicațiile Android sunt scrise în Java, în timp ce aplicațiile iOS sunt scrise fie în Obj-C, fie în Swift. Acestea necesită ca inginerul de dezvoltare să înțeleagă limbajul, precum și nuanțele specifice platformei, care includ, de exemplu, integrarea pachetelor terță parte, gestionarea aspectului, interacțiunea cu sistemul de operare (OS) și așa mai departe.

Pro

Extrem de personalizabil . Deoarece fiecare aplicație este scrisă folosind componente native, singura limitare a personalizării este interfața cu cadrele de bază, și uneori nici măcar atunci. După cum vor atesta majoritatea inginerilor de dezvoltare nativi, există adesea o modalitate de a îndeplini o anumită sarcină, în ciuda unei interfețe limitate.

O simplă dovadă a acestei idei poate fi găsită răsfoind comunitățile de suport pentru o anumită platformă. Se vor găsi numeroase exemple despre cum să îndepliniți o sarcină care ar putea fi „în afara rezervării”, în ciuda limitărilor cadrelor de bază.

Un exemplu concret iOS de o astfel de sarcină aparent simplă ar putea fi afișarea unei suprapuneri pe tot ecranul, mai presus de toate elementele externe ale UI, de exemplu, o bară de file, bară de navigare etc. După cum se arată în Figura 1 , aceasta este în mod normal în afara domeniului de aplicare al stratul de interfață de utilizator normal este prezent în prezent. Ca atare, pentru a avea o suprapunere pe întreg ecranul, aceasta trebuie adăugată la stratul ascuns deasupra barei de file din stiva de vizualizare. Acest tip de personalizare este de obicei posibil numai în aplicațiile native.

Cea mai înaltă performanță . După cum era de așteptat, o aplicație nativă stabilește standardul de performanță. Deoarece majoritatea celorlalte tipuri de cadre adaugă unul sau mai multe straturi intermediare, acestea rulează în mod inerent mai lent decât o aplicație nativă.

Cele mai întreținute . Sistemele de operare se schimbă constant. Perioadă. Când o fac, în funcție de faptul că s-au făcut modificări nerespective, o aplicație trebuie să fie actualizată în timp util, pentru a nu pierde partea din baza de utilizatori care face upgrade la sistemul de operare mai nou. Evident, cu cât trece mai puțin timp între momentul în care modificarea este pusă la dispoziția utilizatorilor și o aplicație este actualizată, cu atât mai bine. Acest timp este minimizat atunci când nu există dependențe care să fie actualizate pentru a suporta acest nou sistem de operare, ceea ce este cazul când lucrați pe o aplicație nativă.

Contra

Resurse suplimentare . Când scrieți aplicații pentru mai multe platforme, o echipă de dezvoltare este formată de obicei din unul sau mai mulți ingineri de software mobil pentru fiecare platformă acceptată. Acest lucru, desigur, crește în mod inerent dimensiunea și costul unei echipe de dezvoltare. De asemenea, necesită ca echipa de ingineri să aibă o varietate de abilități, spre deosebire de o bază omogenă de abilități. Acest lucru are potențialul de a fragmenta o echipă în ceea ce privește sprijinul și colaborarea.

Ciclu de dezvoltare mai lent . Aplicațiile native au potențialul de a avea un ciclu de dezvoltare mai lent, pur și simplu pentru că trebuie scrisă o aplicație separată pentru fiecare platformă dorită. Cazul extrem este atunci când există un singur inginer de dezvoltare mobilă în echipă, deoarece fiecare aplicație este în esență scrisă în serie.

Performanță scăzută . Ar putea părea ciudat să ai performanță atât ca pro și ca contra. Pe de o parte, aplicațiile native oferă dezvoltatorului suficient spațiu pentru a crea o aplicație de înaltă performanță, reglată fin. Pe de altă parte, însă, îi oferă dezvoltatorului suficientă frânghie pentru a se spânzura. Dacă nu știu ce fac, în cele din urmă, vor ajunge cu o aplicație slabă în cel mai bun caz.

Notă: în general, acest lucru se aplică tuturor căilor cadru (native, hibride și non-hibride). Dacă inginerii care dezvoltă o aplicație au competențe insuficiente pentru ceea ce încearcă, aplicația rezultată probabil nici nu va îndeplini cerințele de proiectare și nici nu va fi bine acceptată de utilizatori.

Aplicații hibride

Aplicațiile hibride sunt scrise de obicei folosind HTML/CSS/LESS pentru a proiecta interfața cu utilizatorul: „V” în modelul de design MVC. „C”, sau controlerul, este apoi scris de obicei în JavaScript - în mod ideal, folosind un cadru JavaScript MVC, cum ar fi AngularJS. Utilizarea unui cadru precum AngularJS permite o mai bună separare a claselor și responsabilităților decât este posibilă de obicei folosind doar jQuery.

Un exemplu de acest tip de stivă de cadru hibrid ar fi un strat de vizualizare Ionic susținut de AngularJS, care în cele din urmă este convertit și redat într-o vizualizare web pe platforma dorită folosind PhoneGap și Cordova. Evident, acest tip de cadru WODE vine cu prețul unei complexități suplimentare.

În plus, utilizarea JavaScript aduce cu sine propriile limitări bazate pe design și probleme bazate pe limbaj. Scopul acestui articol nu este de a dezbate meritele sau defectele oricărei limbi; cu toate acestea, în calitate de manager de proiect, alegerea de a utiliza JavaScript în stiva tehnică mobilă nu ar trebui făcută ușor. Următoarele sunt doar câteva exemple de articole bine scrise despre motivul pentru care JavaScript ar trebui evitat dacă este posibil:

• Problema JavaScript
  
• De ce nu sunt un dezvoltator React Native

Pro

Echipa de dezvoltare minimă . Cadrele hibride permit unei echipe mici de dezvoltare – și în special uneia a cărei bază principală de cunoștințe este dezvoltarea web – să producă rapid aplicații simple pe mai multe platforme. Acest lucru îi permite unui manager de proiect să-și mențină echipa mică, precum și să elimine nevoia echipei sale de a învăța limbile native și cadrele pentru mai multe platforme.

Ciclu de dezvoltare mai rapid . Pe lângă o echipă mai mică, cadrele hibride oferă un ciclu de dezvoltare mai rapid atunci când sunt implementate pe mai multe platforme, deoarece trebuie proiectat doar un singur strat de vizualizare folosind tehnologii web.

Contra

UX potențial slab . Dezavantajul de a scrie doar un singur strat de vizualizare este că unul rămâne cu un singur strat de vizualizare. Acest lucru poate duce la un UX slab, deoarece o abordare universală a designului UI nu reușește să ofere aplicației cuiva un aspect și o senzație confortabilă și familiară utilizatorilor de pe toate platformele. În plus, deoarece aplicațiile hibride sunt în esență o vizualizare web încorporată în interfața de utilizare, poate da utilizatorilor impresia că vizionează de fapt o pagină web în loc să interacționeze cu o aplicație nativă. Această experiență are aproape întotdeauna un impact negativ asupra satisfacției utilizatorilor și, în cele din urmă, asupra reținerii.

Costos de personalizare . Îmbunătățirea UX prin proiectarea de UI personalizate pentru fiecare platformă are ca rezultat cadre de UI complexe și unice, care pot fi costisitoare de creat și dificil de întreținut în timp. Mai mult, pentru a crea elemente de interfață de utilizare care vor ajuta la evidențierea aplicației cuiva (de exemplu, animație, vizualizări personalizate etc.), trebuie create componente personalizate pentru a transpune designul de interfață de utilizator de nivel înalt în ceva ce cadrul de nivel inferior , precum Cordova, vor înțelege. În general, cu cât se personalizează și se îmbunătățește mai mult UX-ul unei aplicații hibride, cu atât mai mult diminuează beneficiul unui ciclu de proiectare rapid și ieftin.

Performanță mai scăzută . Deoarece aplicațiile hibride redă vizualizările aplicației într-o vizualizare web, există un potențial mare de a face greșeli de implementare atunci când aveți de-a face cu cadre de operare (de exemplu, rețele, Bluetooth, contacte de pe dispozitiv etc.), ceea ce are ca rezultat o performanță foarte degradată. De asemenea, este de remarcat faptul că, chiar dacă se acordă o mare atenție performanței, deoarece totul este afișat printr-o vizualizare web, performanța maximă a aplicațiilor hibride va fi întotdeauna puțin mai mică decât omologii lor nativi.

Management non-trivial de pluginuri . Îți amintești de acele caracteristici personalizate pe care echipa de proiectare a petrecut săptămâni de lustruire, care au fost urmate de alte câteva săptămâni, în timp ce echipa de dezvoltare a creat componentele de pod necesare pentru ca Cordova să poată lucra cu ele? Ei bine, nu vor funcționa decât dacă există un plugin Cordova de sprijin pentru ceea ce echipa încearcă să realizeze. Acest lucru înseamnă unul dintre două lucruri: fie echipa îl creează ei înșiși, fie va trebui găsit un plugin adecvat de la o terță parte care să facă treaba. Din păcate, de cele mai multe ori, varianta a doua nu există. Ca rezultat, este nevoie de timp suplimentar de dezvoltare pentru a crea plugin-uri personalizate, urmat de efort de asistență pentru construirea – în timp – pentru a gestiona biblioteca în creștere de plugin-uri Cordova cerute de aplicație. Desigur, atunci când apar actualizări Cordova, există o mare probabilitate ca și aceste plugin-uri să fie actualizate.

Întârzierea suportului sistemului de operare . Problema de componentă a podului în cascadă/plugin Cordova menționată anterior este exacerbată atunci când sistemul de operare își schimbă funcționalitatea de bază. Odată ce Cordova, PhoneGap și Ionic au fost actualizate pentru a suporta modificările, este posibil ca pluginurile personalizate și componentele bridge să fie actualizate și ele. Indiferent de ordinul de mărime pe care l-ar necesita această activitate, are ca rezultat un timp suplimentar în care aplicația nu acceptă utilizatorii finali care s-au actualizat la noul sistem de operare. Acesta, desigur, este cel mai rău scenariu în care Apple sau Google fac modificări nerespective, necompatibile cu retroactiv, ceea ce nu se întâmplă niciodată... nu? În general, orice cadru intermediar care este în afara controlului dezvoltatorului și care trebuie actualizat mai întâi servește doar la întârzierea procesului. În cele din urmă, bazarea pe un cadru intermediar poate fi o bătaie de cap pentru managerii de proiect pentru a planifica, deoarece momentul acestor cadre este atât de necunoscut.

Aplicații non-hibride

Aplicațiile non-hibride încep viața la fel ca și omologii lor hibridi - un strat de UI conceput într-un limbaj de platformă non-nativ: React Native utilizează HTML/CSS susținut de JavaScript sau Xamarin, care se bazează pe C# datorită rădăcinilor sale .NET.

Totuși, aici se termină asemănarea. Aplicațiile non-hibride se compilează în cod nativ și redă aplicația folosind componente native ale platformei în loc să fie randate printr-o vizualizare web. Acest lucru are ca rezultat un cadru WODE care, cel puțin la suprafață, are ce este mai bun din ambele lumi.

După cum sa discutat anterior, alegerea de a folosi JavaScript nu ar trebui să fie o decizie care este luată cu ușurință și ar putea fi o problemă pentru o echipă de dezvoltare care nu dorește să învețe sau nu are interes în utilizarea JavaScript.

Pro

Performanță mai mare decât hibrizii . După cum s-ar putea aștepta, non-hibrizile au în mod inerent o performanță mai mare decât aplicațiile hibride datorită capacității lor de a reda aplicația folosind componente native ale UI (butoane, vizualizări, manageri de aspect etc.) în loc să se bazeze pe o vizualizare web încorporată. Desigur, dezvoltatorii sunt încă liberi să scrie o aplicație care funcționează fie remarcabil, fie oribil. Avantajul aplicațiilor non-hibride este pur și simplu că au o performanță de bază mai mare în comparație cu aplicațiile hibride similare.

Echipa de dezvoltare minimă . Similar cadrelor hibride, non-hibridele permit unei echipe de dezvoltare mici – și în special uneia a cărei bază principală de cunoștințe este dezvoltarea web – să producă rapid aplicații simple pe mai multe platforme. Acest lucru le permite managerilor de proiect să-și mențină echipa mică și să o împiedice să învețe limbile native și cadrele pentru mai multe platforme.

Ciclu de dezvoltare mai rapid . Pe lângă o echipă mai mică, cadrele non-hibride oferă un ciclu de dezvoltare mai rapid atunci când sunt implementate pe mai multe platforme, deoarece trebuie proiectat doar un singur strat de vizualizare.

Iterații mai rapide (React) . Cadrul React oferă o caracteristică puternică care permite ca modificările aplicației să fie redate în timp real: nu este nevoie de recompilare, reconstrucție etc. Ca urmare, emulatorul React este un instrument de dezvoltare incredibil de puternic care reduce dramatic durata fiecărei implementări. ciclu.

Contra

Costos de personalizare . La fel ca omologul său hibrid, atunci când aplicațiile non-hibride necesită îmbunătățirea UX prin proiectarea de interfețe de utilizare personalizate pentru fiecare platformă, rezultă componente complexe și unice ale UI care pot fi costisitoare de creat și dificil de întreținut în timp. Acest lucru înseamnă, de asemenea, scrierea unor componente de punte personalizate pentru a suplimenta lacunele din suportul pentru elementele native ale cadrului. La fel ca hibrizii, acest cost diminuează beneficiul unui ciclu de proiectare rapid și ieftin, dar spre deosebire de aplicațiile hibride, componentele bridge sunt scrise pentru fiecare platformă dorită în limba lor maternă . Aceasta înseamnă că, în loc ca aplicațiile non-hibride să fie o alternativă flexibilă la o echipă care este compusă în principal din dezvoltatori web, echipele care aleg calea non-hibridă trebuie să învețe nu numai limbajul specific al cadrului (de exemplu, JSX sau C#), ci și de asemenea, limba maternă a fiecărei platforme (Java, Obj-C sau Swift).

Dependențe de la terți . Această limitare ia două forme diferite. În cazul lui React Native, acesta ia forma a numeroase dependențe, adică aproximativ 650. Rezultatul este că există o șansă foarte bună la un anumit moment ca una sau mai multe dintre aceste dependențe să fie depășite. De asemenea, înseamnă că, în cazul unei schimbări mari la nivel de sistem de operare, există o probabilitate mare ca majoritatea sau toate aceste dependențe să fie actualizate. Potențiala har de salvare este că Facebook folosește React, așa că cineva va avea în colțul lor gorila de 300 de lb.

În cazul lui Xamarin, problema dependenței terțelor părți este pur și simplu că este extrem de dificil să le integrezi în primul rând. Xamarin este conștient de această problemă și oferă un instrument utilitar numit Sharpie. Scopul instrumentului este de a ajuta la o parte din integrare, dar, din păcate, Sharpie încearcă adesea să compileze și să conecteze resurse incorecte, ceea ce obligă dezvoltatorul să îndeplinească sarcina minuțioasă, care necesită mult timp, de a modifica manual parametrii de compilare de nivel scăzut pentru a finaliza cu succes. integrarea.

Întârzierea suportului sistemului de operare . Aplicațiile non-hibride sunt afectate de aceeași problemă ca și cele hibride. Orice cadru intermediar care este în afara controlului dezvoltatorului și care trebuie actualizat mai întâi servește doar la întârzierea procesului de actualizare a aplicației cuiva pentru a sprijini utilizatorii de ultimă generație. Mai mult, așa cum am menționat anterior, bazarea pe un cadru intermediar poate fi o bătaie de cap pentru managerii de proiect pentru a planifica, deoarece momentul acestor cadre este atât de necunoscut.

Asistență pe termen lung (React Native) . Această problemă este specifică React Native și se referă la faptul ciudat că, până în prezent, Facebook nu s-a angajat la un plan de suport pe termen lung pentru cadrul său. Se poate spune că acesta este un risc scăzut, deoarece compania utilizează propriul cadru pentru aplicațiile sale mobile, dar merită o pauză pentru orice manager de proiect pentru a se gândi de ce Facebook a refuzat să comenteze acest subiect.

Alegerea abordării corecte

Când costul nu este o considerație principală, Figura 2 arată că scrierea aplicațiilor native este aproape întotdeauna cea mai bună alegere atunci când se valorifică componența echipei de dezvoltare față de cerințele aplicației. Când există mai puțini ingineri de dezvoltare decât numărul de platforme dorite, devine puțin mai interesant. În acest caz, utilizarea React este alegerea corectă dacă echipa se află sub un program de lansare foarte strâns; în caz contrar, a fi nativ este încă cea mai bună opțiune.

Când echipa este în primul rând o echipă de dezvoltare web și este necesară o UX personalizată, este mai bine ca unii membri ai echipei să schimbe pălăriile sau să adauge câțiva membri ai echipei pentru a face aplicațiile proprii. Într-adevăr, nu există o opțiune de cadru fezabilă și care poate fi întreținută dacă o aplicație necesită elemente personalizate, ceea ce fac multe aplicații.

Cu toate acestea, dacă nu este necesar un UX personalizat, atunci, în funcție de programul de lansare, ar putea fi mai bine să mergeți cu Ionic sau React. Dacă echipa cuiva nu are timp să învețe JSX, atunci Ionic este alegerea potrivită. În caz contrar, este mai bine să alegeți React, deoarece necesită deja multe dependențe de la terți, iar adăugarea altora nu va afecta ciclul de dezvoltare.

Odată ce costul proiectului este o preocupare principală, de obicei, componența echipei existente devine mai puțin prioritară, deoarece primul pas ar fi acela de a pune echipa potrivită pentru a executa planul de proiect pentru costul proiectat. După cum se arată în Figura 3 , aplicațiile native au un cost de pornire mai mare decât omologii lor WODE, dar și un potențial UX mai mare. Mai mult, aplicațiile WODE vor fi întotdeauna limitate în UX-ul lor, indiferent de câți bani și resurse sunt aplicate proiectului.

Sper că acest articol a aruncat puțină lumină asupra avantajelor și dezavantajelor diferitelor căi de dezvoltare mobile, precum și a ajutat la cântărirea componenței echipei atât în ​​raport cu cerințele aplicației, cât și cu costul proiectului. Mesajul său nu a fost să transmită că cadrele WODE sunt inferioare și nu ar trebui niciodată căutate, ci mai degrabă că, deși există cazuri de utilizare valide pentru a nu deveni native, ar trebui să înțelegem pe deplin ramificațiile acestui lucru.