Interfață nativă. Revizuirea soluțiilor multiplatforme pentru dezvoltarea de aplicații mobile

Într-o zi, lipsa cunoștințelor de bază despre aplicațiile mobile va deveni probabil proaste maniere. Între timp, să vorbim despre ce fel de aplicații există. Venind de departe, putem distinge doar trei tipuri: ce este o aplicație nativă, aplicație web și hibridă.

Știți ce este o aplicație nativă?

Pentru utilizator, aplicațiile native sunt cele care necesită instalare. În general, acest lucru este adevărat, la fel ca și faptul că astfel de aplicații sunt dezvoltate special pentru platformele mobile (iOS, Android, Windows Phone). Prin urmare, dezvoltatorului i se cere să aibă abilități de programare într-un mediu de dezvoltare specific (xCode pentru iOS, eclipse pentru Android).

Rezultatul este un aspect plăcut și o interacțiune perfectă a aplicației cu sistemul de operare mobil. O aplicație nativă este, de asemenea, cu mult înaintea atât a unei aplicații hibride, cât și a unei aplicații web când vine vorba de securitate. Astfel de aplicații cu cel mai mic consum de resurse folosesc camera, microfonul, accelerometrul, playerul și alte funcții. În mod convențional, o aplicație nativă poate fi împărțită în două grupuri: aplicații care necesită o conexiune la Internet și aplicații offline.

Aplicațiile web sunt diferite de o aplicație nativă

Utilizarea unui site web obișnuit pe un smartphone este incomodă în cel mai rău caz, aspectul site-ului se destramă și, după aceea, este complet imposibil să lucrezi cu el. Aplicațiile web sunt create în scopul utilizării unui site web de pe un telefon. Deci, în esență, acesta este același site optimizat pentru dispozitive mobile. Spre deosebire de o aplicație nativă, aplicațiile web nu trebuie să fie instalate - rulează în browserul telefonului dvs. Prin urmare, absolut nimic nu depinde de modelul de telefon (pe platforma mobilă, mai precis). De asemenea, indiferent de platformă, aplicațiile web nu pot funcționa cu funcțiile native ale telefonului.

Dar ce este atunci o aplicație nativă în comparație cu un site web mobil? Linia dintre o aplicație web și un site mobil este foarte subțire. Și în această chestiune, nu doar utilizatorii sunt confuzi, ci, în unele cazuri, dezvoltatorii înșiși. Dar există o diferență. Convențional vorbind, site-ul conține informații mai mult sau mai puțin statice și este ceva ca o broșură digitală. Într-o aplicație web, utilizatorul poate gestiona o parte din aceste informații - să-și creeze propriile pagini, să schimbe link-uri, texte etc.

Prin urmare, este mai ușor să apelați tot ceea ce se numește în mod obișnuit aplicații web pentru servicii online. O aplicație web poate fi numită și ceva ce se făcea cândva în Flash, iar acum în HTML5.

Aplicații hibride

O aplicație hibridă se numește hibridă deoarece combină unele dintre funcțiile unei aplicații native și ale unei aplicații web. Aceasta este o aplicație multiplatformă care poate funcționa cu software-ul telefonului. Aceste aplicații, la fel ca și cele native, sunt descărcate din magazinul de aplicații, dar datele sunt actualizate autonom. Prin urmare, au întotdeauna nevoie de o conexiune la internet - fără ea, funcțiile web nu funcționează.

Ce sa aleg? aplicație nativă, hibridă sau web?

Dezvoltarea unei aplicații hibride este mai ieftină și mai rapidă decât crearea unei aplicații native. Dar oricum utilizatorii nu vor observa diferența. Prin urmare, tehnologiile hibride sunt cele mai populare. În ciuda acestei complexități, alegerea tehnologiei pentru dezvoltarea unei aplicații este foarte simplă. Dacă aplicația dvs. nu poate funcționa fără funcțiile native ale dispozitivelor mobile, dacă viteza mare de procesare a datelor este foarte importantă (jocuri, rețele sociale, geolocalizare), atunci nimic mai bun nu poate fi găsit decât o aplicație nativă. Când viteza poate fi neglijată, este potrivită o aplicație hibridă. O aplicație web ar trebui creată atunci când utilizatorul nu are nevoie de nimic de la tine, în afară de informațiile pe care le-ar putea obține de pe telefonul său dacă ar avea internet.

Piața aplicațiilor mobile are mai bine de zece ani, dar se dezvoltă în continuare rapid. Cererea din partea companiilor este în continuă creștere și încă depășește semnificativ oferta, ceea ce duce la o creștere constantă a costului de dezvoltare. O soluție pentru a reduce costul acestui proces este dezvoltarea multiplatformă, când același cod este utilizat pe toate platformele.

Ultima dată am atins despre dezvoltarea mobilă multiplatformă și multe s-au schimbat de atunci. Este timpul să vorbim din nou despre metode și instrumente.

Mai întâi, să trecem din nou peste terminologie.

Nativ

Dacă dezvoltatorii, în procesul de scriere a unei aplicații, folosesc limbajul de programare adoptat pentru o anumită platformă, fie că este Objective-C și Swift pentru iOS sau, o astfel de aplicație se va numi nativ (din limba engleză nativ - nativ, natural).

Avantajele aplicațiilor native:

• viteza și răspunsul interfeței. Aplicația răspunde instantaneu la clicuri, practic nu există întârzieri în animație, defilare, primire și ieșire de date;
• acces clar și ușor la funcțiile și senzorii dispozitivului. Pentru dezvoltator, lucrul cu geolocalizarea, notificările push, realizarea de fotografii și videoclipuri prin cameră, sunet, accelerometru și alți senzori nu este o problemă;
• capacitatea de a lucra în profunzime cu funcțiile smartphone-ului. Ca și în paragraful anterior, sunt implementate, poate nu simplu, dar previzibil, lucruri precum animațiile, crearea de interfețe complexe și operarea rețelelor neuronale direct pe dispozitive;
• . Aplicațiile native funcționează de obicei cu elemente de interfață „platformă”: meniurile, navigarea, formularele și toate celelalte elemente de design sunt preluate din sistemul de operare și, prin urmare, sunt familiare și ușor de înțeles utilizatorului.

Există un singur dezavantaj - costul ridicat de dezvoltare și suport. Pentru fiecare platformă trebuie să scrieți propriul cod. Odată cu creșterea pieței de aplicații mobile, dezvoltatorii au devenit nu doar scumpi, ci și foarte scumpi.

Și nu rude

Aplicațiile cross-platform sunt scrise pentru mai multe platforme simultan într-o singură limbă decât cea nativă. Cum poate funcționa un astfel de cod pe diferite dispozitive? Există și două abordări aici.

Primul este că în etapa de pregătire a aplicației pentru publicare, aceasta este transformată în nativă pentru o anumită platformă folosind un transpiler. De fapt, un limbaj de programare multiplatformă este „tradus” în altul.

Al doilea este că la codul rezultat este adăugat un anumit wrapper, care, lucrând deja pe dispozitiv, traduce din mers apelurile din cod non-nativ în funcții de sistem native.

Se presupune că cea mai mare parte a acestui cod poate fi transferată între platforme - este evident că, de exemplu, logica de a face achiziții, de a economisi mărfuri în cărucior, de a calcula o rută pentru un taxi, de a scrie un mesaj în messenger nu se schimbă. în funcție de faptul că clientul are Android sau iOS. Trebuie doar să îmbunătățim UI și UX pentru platforme, dar acum, în anumite limite, chiar și acest lucru poate fi combinat - de exemplu, meniul hamburger este utilizat activ atât pe Android, cât și pe iOS. Deci, chiar și efectuarea de corecții la interfață, astfel încât aplicația să îndeplinească spiritul și litera platformei dorite este o chestiune de dorință, viteza necesară și calitatea dezvoltării.

Avantaje:

• costul și viteza de dezvoltare. Deoarece trebuie scris mult mai puțin cod, costul muncii este redus;
• capacitatea de a utiliza resursele interne ale companiei. După cum vom arăta mai târziu, dezvoltarea aplicațiilor mobile pe mai multe platforme poate fi realizată adesea de programatorii dvs. existenți.

Defecte:

• interfață non-nativă sau, cel puțin, necesitatea de a lucra cu interfața fiecărei platforme separat. Fiecare sistem are propriile cerințe pentru proiectarea elementelor și uneori se exclud reciproc. Acest lucru trebuie luat în considerare în timpul dezvoltării;
• probleme în implementarea funcțiilor complexe sau posibile probleme de lucru chiar și cu proceduri simple din cauza erorilor din cadrul de dezvoltare în sine. Mediul multiplatformă traduce doar cererile către apeluri de sistem și interfețe într-un format pe care sistemul îl înțelege și, prin urmare, în această etapă pot apărea atât dificultăți de înțelegere, cât și erori în cadrul propriu-zis;
• viteza de lucru. Deoarece mediul multiplatformă este o „superstructură” peste cod (nu întotdeauna, dar în anumite situații), are propriile întârzieri și pauze în procesarea acțiunilor utilizatorului și afișarea rezultatelor. Acest lucru s-a observat mai ales în urmă cu câțiva ani pe smartphone-urile care aveau o putere mai mică în comparație cu cele de astăzi, dar acum, odată cu creșterea performanței dispozitivelor mobile, acest lucru poate fi deja neglijat.

După cum puteți vedea, aceste două metode sunt practic o imagine în oglindă una a celeilalte - avantajele dezvoltării native, dezavantajele dezvoltării multiplatforme și invers.

Platforme și instrumente populare de dezvoltare multiplatformă

După cum am scris mai sus, există două abordări - transformarea codului în nativ în etapa de asamblare sau adăugarea unui anumit wrapper care traduce apelurile către și dinspre sistem.

Cordova și PWA sunt două instrumente care funcționează tocmai în ideologia unui wrapper.

Cordova și HTML5

Una dintre cele mai populare domenii în programarea multiplatformă, care este adesea numită în mod popular PhoneGap. De fapt, este creat un site web mobil, care este „împachetat” într-un mic cod de platformă care transmite apeluri de la sistem la aplicație și înapoi.

Toate dezavantajele și avantajele sunt exprimate aici mai clar decât oriunde altundeva. Puteți folosi dezvoltatori web (HTML, CSS și JavaScript ca tehnologii de bază) și puteți face prima versiune a aplicației într-o lună sau chiar câteva săptămâni pentru bani relativ puțini. Da, va funcționa lent și poate să nu aibă o geolocalizare complet precisă, dar va funcționa pe toate dispozitivele și vă va permite, cel puțin, să testați cererea clienților pe dispozitivele mobile.

Au fost create un număr mare de cadre pentru această abordare, dar toate fac în esență același lucru. Diferența dintre ele este că Cordova (PhoneGap) nu stabilește restricții și șabloane privind logica și interfața de utilizare pentru proiectul tău HTML5, iar cadrele funcționează cu propriile elemente UI gata făcute care imită platformele mobile și propria lor logică de dezvoltare. Un exemplu al acestei abordări este: Ionic Framework - wrapper; Framework7, Mobile Angular UI, Sencha Touch, Kendo UI - cadre de interfață.

PWA

Tehnologia la modă de la Google este aceeași aplicație web, dar prin utilizarea anumitor tehnologii (în primul rând așa-numitul Service Worker - scripturi care rulează în fundal și Web App Manifest - o descriere a aplicației web într-o formă ușor de înțeles pentru mobil system ) pot funcționa ca native fără ambalajul PhoneGap. Acestea pot fi instalate pe ecranul de pornire, ocolind magazinul de aplicații, pot lucra offline, pot lucra cu notificări push și cu funcții native.

Problema este că nici acum nu toate platformele acceptă aceste „anumite tehnologii”. Acest lucru se referă în primul rând la Apple, căruia se pare că nu-i place cu adevărat capacitatea de a distribui aplicații ocolind App Store.

Luând în considerare toate deficiențele soluțiilor HTML5, multe companii au creat instrumente care vă permit să scrieți cod într-o singură limbă, non-nativă, iar apoi este tradus în nativ. Acest lucru ucide două păsări dintr-o singură piatră: există o singură bază de cod, iar aplicațiile sunt cât mai aproape de native.

Xamarin

Platforma Microsoft. Limbajul de programare standard pentru dezvoltarea Enterprise este C#, iar mediul de dezvoltare multiplatformă este Visual Studio. Ieșirea sunt aplicații native pentru iOS, Android și Windows. Adevărat, de dimensiuni relativ mari.

Reacționează nativ

Platforma de la - aplicațiile sunt scrise în JavaScript și folosesc stiluri asemănătoare CSS. Interfața se dovedește a fi nativă, iar codul este interpretat pe platformă, ceea ce îi conferă flexibilitatea necesară.

Fiind o platformă relativ tânără, React Native încă suferă (deși nu în mod catastrofal) de lipsa instrumentelor de dezvoltare și a documentației.

Flutter

Desigur, un astfel de gigant precum Google nu putea ignora subiectul dezvoltării multiplatforme a aplicațiilor Android și iOS. Flutter, deși în prezent este doar în versiune beta, adoptă o abordare diferită de React Native și Xamarin. Nu transformă codul sursă în cod nativ, care este executat de platformă, ci de fapt desenează o fereastră pe ecranul smartphone-ului și redă toate elementele în sine. Limbajul folosit este Dart „proprietar”, pe care Google l-a creat ca o versiune îmbunătățită a JavaScript.

Acest lucru are atât avantaje (de exemplu, interfețe identice extern), cât și dezavantaje (de exemplu, redesenarea interfeței necesită o anumită cantitate de memorie și timp CPU).

Platforma se dezvoltă rapid și Google investește mult efort și bani în ea. Dar, în comparație cu Flutter, chiar și React Native pare un ecosistem foarte stabilit și impresionant.

Ce să alegi

Probabil că ți se învârte deja capul, dar tot nu ai idee ce să alegi. Să vă prezentăm o listă simplă de întrebări care să vă ajute:

• Ar trebui să funcționeze cumva pe orice dispozitiv? Alege HTML ca bază;
• Aveți suficiente fonduri, nu vă grăbiți și doriți o aplicație de cea mai bună calitate? Ai o cale directă către dezvoltare nativă;
• Aveți un dezvoltator web „încorporat” sau doriți doar să încercați rapid și ușor o aplicație mobilă în acțiune? Aici vă putem recomanda Cordova/HTML sau PWA;
• Aveți propriul dvs. sistem CRM și un dezvoltator C# care îl sprijină? Ia-l Xamarin;
• „vrei să încerci”, dar trebuie să faci totul frumos și la modă? Întoarce privirea Reacționează Nativ sau Flutter.

Puteți merge și din partea cealaltă. Uitați-vă la funcționalitatea de care veți avea nevoie în aplicația dvs. și mergeți de acolo:

• o aplicație simplă pentru cărți de vizită? Lua React Native sau HTML5și vei obține două platforme la un preț minim;
• Aveți un site web cu mult trafic și trebuie să vă testați prezența în spațiul mobil? HTML5;
• aplicații complexe cu acces la funcțiile dorite ale dispozitivului? Dezvoltare nativă, Xamarin, React Native.

Dezvoltarea multiplatformă nu este un panaceu

Când alegeți, trebuie să continuați din sarcinile atribuite și resursele existente. Dezvoltarea multiplatformă este o direcție bună și de înțeles, dar cu propriile avantaje și dezavantaje care trebuie reținute înainte de lansarea proiectului. O aplicație multiplatformă finalizată este evident mai bună decât una nativă nerealizată. Puteți să o dezvoltați rapid și ieftin, să o încărcați în magazin și să verificați pur și simplu cererea de la utilizatori - dacă cineva caută aplicația dvs., dacă o instalează, ce funcții folosesc. Pe baza rezultatelor unui astfel de experiment, va fi posibil să decideți soarta direcției mobile în compania dvs. și investițiile în aceasta.

Mai aveți îndoieli și întrebări despre aplicațiile multiplatforme? Citiți despre cum am creat o aplicație pentru obținerea rapidă a unui abonament la una dintre instituțiile sportive ale orașului și încercați aplicația pentru plata pentru tot felul de servicii - de la locuințe și servicii comunale până la comenzi în magazinele online. Mai bine, înscrieți-vă pentru o consultație gratuită, indicând un buget aproximativ și o scurtă descriere a ideii, sau contactați telefonic managerul nostru Katya

Astăzi vă propunem să înțelegem cum diferă o aplicație creată în designer de cea care va fi dezvoltată pentru dvs. în studio.

Aplicațiile native sunt proiectate pentru parametrii și proprietățile unei anumite platforme(OS mobil, ecosistemul asociat și caracteristicile tehnice ale dispozitivului mobil în sine) și utilizează toate capacitățile platformei hardware necesare pentru a funcționa cu aplicația - de la cameră și modulul GPS până la accelerometru, control prin gesturi și alte componente hardware -proprietățile acceptate ale unui anumit smartphone sau tabletă. În plus, o aplicație nativă dezvoltată în studio poate fi obținută ca produs finit și plasată într-un magazin de aplicații mobile (cum ar fi Google Play sau Apple App Store).

Aplicația nativă folosește și sistemul de notificare al fiecărui dispozitiv specific, acceptă notificări Push și poate funcționa în modul offline.

Ce creează majoritatea designerilor online?

Am publicat, dar se poate numi mai degrabă o listă de instrumente de probă (pentru a vedea cum va arăta aplicația „în viața reală”), mai degrabă decât o soluție cu drepturi depline pentru cei care doresc să creeze o aplicație de la zero.

Designerul online nu creează o aplicație nativă, ci o aplicație web, care nu este un produs software în sensul clasic, este în esență un site web special care arată și acționează ca o aplicație nativă, dar de fapt nu este unul. De regulă, pentru ca acesta să funcționeze, aveți nevoie de un browser instalat și configurat pe un dispozitiv mobil cu acces la Internet. Aplicația web în sine este construită folosind HTML5. Acest lucru explică parțial popularitatea în creștere a aplicațiilor web (și faptul că noul sistem de operare mobil Tizen de la Samsung și unele variante de Android utilizează aplicații web cu această tehnologie).

O astfel de aplicație web nu este potrivită pentru toate proiectele (în special, dacă proiectele media și de știri cu bloguri se pot mulțumi cu capabilitățile HTML5, atunci o astfel de soluție nu este potrivită pentru magazinele online și site-urile cu încărcare mare).

În plus, o aplicație web nu poate fi publicată în unele magazine pentru distribuția de software mobil este mai dificil să implementezi un modul de plată și alte caracteristici pe care le au aplicațiile native; Spre deosebire de aplicațiile native, nici aplicațiile web nu folosesc toate capacitățile unui smartphone, deoarece... nu au acces deplin la platforma hardware și la componentele acesteia.

Există și aplicații hibride (designerul ajută și la crearea lor). Aplicațiile hibride folosesc parțial funcționalitatea nativă și parțial capabilitățile aplicațiilor web. Din aplicațiile native, au preluat capacitatea de a publica pe platformele de distribuție online și de a sprijini accesul la hardware-ul smartphone-urilor. Din aplicațiile web, au suport HTML și funcționează în browser.

Companiile se îndrăgostesc adesea de atractivitatea și accesibilitatea aplicațiilor hibride, atât din punct de vedere al prețului, cât și al vitezei de dezvoltare (abilitatea de a construi o astfel de aplicație în designer pentru mai multe platforme în același timp este și ea captivantă).

Dar acest lucru are și dezavantajele sale, care sunt de obicei vizibile în proiectarea aplicației: „funcțiile” native ale unei platforme pot să nu funcționeze corect pe alta și invers. Drept urmare, se dovedește că nici o aplicație hibridă nu este lipsită de dezavantajele unei aplicații web.

Ce ar trebui să alegi?

Fiecare tip de aplicație are propriile sale avantaje și dezavantaje, iată doar cele mai semnificative:

Acces la capabilitățile dispozitivului: Aplicațiile native au acces deplin la platforma hardware, dar aplicațiile web nu au astfel de capabilități. Deci, dacă intenționați să utilizați capacitățile camerei, geolocalizarea și transferul de date fără fir, atunci o aplicație nativă mai degrabă decât o aplicație adaptivă este potrivită pentru dvs.

Lucrul fără acces la internet: O aplicație nativă este alegerea ta dacă este important să funcționeze fără nicio formă de conexiune la internet. Aplicațiile web se bazează pe o conexiune la Internet și pe stocarea în cache a browserului.

Abilitatea de a căuta informații și aplicația în sine: Aplicațiile web sunt mai bune la căutarea prin conținut, dar dacă intenționați să căutați prin conținutul unei aplicații fără acces la Internet, va trebui să faceți fie o aplicație hibridă, fie una nativă.

Viteza de operare: Aplicațiile native funcționează cel mai rapid. În 2012, Mark Zuckerberg spunea că cea mai mare greșeală pe care a făcut-o rețeaua sa de socializare a fost lansarea unei aplicații web, mai degrabă decât dezvoltarea unei soluții native (până atunci, Facebook folosea o aplicație hibridă, în care majoritatea conținutului era disponibil doar atunci când era conectat la Internet și era bazat pe HTML c În 2012 a fost înlocuit cu unul nativ). Totul tine de viteza de raspuns.

Procesul de instalare:În timp ce aplicațiile native și hibride trebuie să fie instalate pe dispozitivul dvs. și să li se acorde permisiunea de a accesa anumite componente ale platformei software și hardware, o aplicație web este în esență „instalată” prin simpla adăugare a unui marcaj în browserul mobil.

Gestionarea și întreținerea aplicațiilor: După fiecare actualizare, o aplicație nativă trebuie repostată în magazinul de aplicații, în timp ce într-o aplicație web pagina și conținutul sunt în esență actualizate, „ambalate” sub forma unui fel de site mobil.

Legarea la o anumită platformă: Deoarece browsere diferite pot accepta versiuni diferite de HTML5, indiferent de tipul de platformă hardware sau de sistemul de operare mobil instalat, aplicațiile web sau aplicațiile hibride sunt alegerea celor care doresc să se dezlipească de platformă. Dacă dezvoltarea separată pentru fiecare platformă individuală nu te sperie, atunci poți paria pe o aplicație nativă.

Lucrul cu conținut, procedura de adăugare în magazinul de aplicații și plăți suplimentare: Aplicațiile native și hibride trec printr-un proces special de aprobare după ce sunt adăugate în magazinul de aplicații. În plus, acestea pot fi supuse anumitor restricții din cauza regulilor și politicilor interne ale App Store și Google Play (mai ales dacă vorbim despre conținut „adulți”, jocuri de noroc, alcool sau subiecte similare).

În plus, aplicațiile native care vând abonamente plătite ca parte a aplicațiilor adăugate în App Store trebuie să împartă redevențe cu Apple. În consecință, prețurile și bugetele în cazul aplicațiilor native trebuie ajustate ținând cont de valoarea acestor deduceri.

Cost de dezvoltare: Pe de o parte, dezvoltarea de aplicații web și soluții hibride este mult mai ieftină (în plus, versiunile elementare ale unor astfel de aplicații pot fi create în designer gratuit sau cu o reducere semnificativă). Pe de altă parte, chiar și pentru a crea o aplicație web sau o aplicație hibridă trebuie să ai abilități de dezvoltare mai mult sau mai puțin acceptabile, iar numărul de restricții privind posibilitățile de utilizare a platformei hardware pune sub semnul întrebării fezabilitatea „economiilor”.

Interfața cu utilizatorul: Iar unul dintre argumentele cheie în favoarea dezvoltării native mai degrabă decât a soluțiilor web sau hibride este consistența interfeței cu utilizatorul în aplicație și în sistemul de operare mobil. Componentele vizuale, grafica și interfața aplicației web pot fi, de asemenea, cât mai apropiate de cele care sunt implicit în sistemul de operare în sine, dar pentru o conformitate cât mai completă merită totuși să folosiți o soluție nativă.

Doriți să comandați o aplicație nativă? Trimiteți cererea dvs cu subiectul „Dezvoltare aplicație” pe e-mailul nostru - și vă vom contacta în termen de 24 de ore și vă vom clarifica toate detaliile pentru discuții ulterioare.

Smartphone-urile continuă să câștige din ce în ce mai mult spațiu la soare, nu doar ca instrument pentru consumul de fotografii cu pisici și videoclipuri XXX, ci și ca instrument de lucru. Prin urmare, cererea de dezvoltare mobilă este în creștere. Este în general acceptat că forța de muncă și cool sunt Objective-C/Swift pentru iOS și Java/Kotlin pentru Android. Fără îndoială, este o muncă grea și mișto, dar există un număr mare de scenarii reale în care utilizarea cadrelor multiplatforme este mai de preferat în comparație cu instrumentele native.

Unii dezvoltatori se așteaptă ca cadrele multiplatforme să le rezolve toate problemele vieții, în timp ce alții le sunt ostili. Ambele „tabere în război” au propriile lor concepții greșite cauzate de lipsa de înțelegere a modului și a ceea ce funcționează. Acest lucru adaugă combustibil focului, deoarece emoțiile sunt folosite în loc de argumente tehnice.

De asemenea, printre dezvoltatori, în special începători, există multe mituri despre cadrele mobile multiplatforme. În articolul nostru le vom analiza pe cele mai populare dintre ele. Dar mai întâi, să privim dezvoltarea mobilă prin ochii unei afaceri care furnizează bani pentru întregul blackjack IT.

De ce avem nevoie de instrumente multiplatforme?

Din punct de vedere istoric, pe piața calculatoarelor a existat întotdeauna concurență, iar fiecare producător a furnizat setul optim de așa-numite instrumente native pentru dezvoltarea aplicațiilor pentru sistemele și dispozitivele lor de operare.

Instrumente native = furnizate de proprietarul ecosistemului.

Toate celelalte semne de „nativitate” sunt SECUNDARE - comportament și interfața aplicației, acces la capabilitățile sistemului de operare, performanță etc.

În plus, aproape întotdeauna s-a dovedit că instrumentele native sunt incompatibile între ele nu numai la nivel de limbaje de dezvoltare, convenții și arhitecturi acceptate, ci și la nivelul mecanismelor de lucru cu sistemul de operare și bibliotecile. Ca urmare, pentru a implementa aceiași algoritmi și interfețe, a fost necesar să scrieți o aplicație pentru mai multe medii în diferite limbaje de programare, apoi să o susțineți pe o bază „o comandă pe platformă”. În același timp, capacitățile și aspectul aplicațiilor de pe diferite platforme sunt aproape întotdeauna 90% identice. Doar pentru distracție, compară implementarea programelor tale preferate pentru iOS și Android.

Al doilea punct important este prezența cunoștințelor și experienței necesare în cadrul echipei: dacă nu sunt acolo, atunci va dura timp pentru a învăța.

Pentru a rezolva ambele probleme, instrumentele de dezvoltare multiplatformă (nu doar mobile) au apărut de mult pe piață, oferind:

• maximizați baza de cod comună într-un singur limbaj de programare, astfel încât produsul să fie mai ușor de dezvoltat și întreținut;
• folosiți competențele și specialiștii existenți pentru a implementa aplicații pe platforme noi.

Deoarece acum există o mulțime de limbaje de programare (și medii) (și specialiști care vorbesc aceste limbaje), există un număr destul de mare de instrumente pentru dezvoltarea multiplatformă. De exemplu, ne vom concentra pe cele populare din zona noastră PhoneGap, Xamarin, React Native și Qt.

Acum putem vorbi despre mituri.

Mitul 1. Magie

Cel mai des întâlnit mit care bântuie mintea dezvoltatorilor începători este legat de credința în super-algoritmi (și super-programatorii care i-au creat) care transformă magic aplicațiile multiplatforme în native. Ceva de genul „conversiei codului JavaScript în Swift și apoi compilarea unei aplicații Swift”. Acest mit este alimentat de dezvoltatorii de instrumente multiplatforme înșiși, promițând ca rezultat crearea de „aplicații native”. Și nu este că cineva minte aici, dar imaginația bogată și neînțelegerea mecanismelor de bază îi determină uneori pe dezvoltatori să se gândească la tehnici șamanice.

Principiul principal care stă la baza soluțiilor multiplatforme este împărțirea codului în două părți:

• multiplatformă, trăind într-un mediu virtual și având acces limitat la capacitățile platformei țintă printr-o punte specială;
• nativ, care oferă inițializarea aplicației, gestionarea ciclului de viață al obiectelor cheie și are acces deplin la API-urile de sistem.

Pentru a conecta lumea „nativă” și lumea „cross-platformă”, este necesar să folosiți un special pod, el este cel care determină capacitățile și limitările cadrelor multiplatforme.

Când utilizați o punte, performanța este întotdeauna redusă datorită conversiei datelor între „lumi”, precum și conversiei apelurilor și bibliotecilor API.

Deci, toate aplicațiile cross-platform trebuie să aibă o parte nativă, altfel sistemul de operare pur și simplu nu le va putea lansa. Deci, să aruncăm o privire mai atentă la ce API-uri și mecanisme de sistem sunt furnizate de iOS, Android și Windows. Să trecem la următorul mit.

Mitul 2. Nu nativ!

Deci, avem o parte multiplatformă a aplicației care trăiește într-un mediu virtual și interacționează cu sistemul de operare prin infrastructura cadru și bridge.

Toate sistemele de operare: iOS, Android și Windows UWP oferă acces la următoarele subsisteme (seturi de API-uri de sistem):

• WebView (un browser web în aplicație) este utilizat în mashup-urile bazate pe PhoneGap și acționează în esență ca un mediu de rulare pentru site-ul web local;
• Motoarele JavaScript sunt utilizate în React Native și analogii pentru executarea rapidă a codului JS și schimbul de date între Native și JS;
• OpenGL ES (sau DirectX) este folosit în motoarele de jocuri și aplicațiile bazate pe Qt/QML sau analogi pentru redarea interfeței;
• Subsistemul UI este responsabil pentru interfața de utilizator nativă a aplicației, care este relevantă pentru React Native și Xamarin.

Aplicațiile multiplatforme au o parte nativă și același acces complet la API-urile de sistem ca și aplicațiile native. Diferența este că metoda de sistem este apelată prin intermediul podului și al infrastructurii cadru:

WebView- aplicația locuiește în browserul său web, similar unui site web de o pagină. Nu există acces la controalele native (butoane, liste etc.), totul se bazează pe HTML/CSS/JavaScript. Pe de altă parte, un dezvoltator web se va simți ca un pește din apă.

Motoare JavaScript a devenit popular relativ recent, deoarece un mecanism similar a fost adăugat la iOS doar în versiunea 7.0. Una dintre caracteristicile care merită luate în considerare este necesitatea de a serializa structurile complexe de date transferate între JavaScript și mediile native în JSON. Pentru a descrie pe scurt această clasă de soluții, codul JS care controlează aplicația nativă este executat în mediul JavaScript.

OpenGL ES și DirectX sunt subsisteme de nivel scăzut și sunt folosite pentru a reda interfața cu utilizatorul în jocuri și, de exemplu, Qt/QML. Adică, atunci când folosesc OpenGL/DirectX, dezvoltatorii înșiși desenează controale și animații, care pot fi similare doar cu cele native. Pe de altă parte, este un subsistem de nivel scăzut, cu performanțe foarte ridicate, motiv pentru care este folosit și în motoarele de jocuri multiplatforme.

Toate aplicațiile multiplatformă au o parte nativă și, prin urmare, potențial același acces complet la API-urile de sistem ca și cele native. De asemenea, aplicațiile multi-platformă sunt construite și împachetate cu instrumente native în pachete de instalare native. Întrebarea cheie este cum este organizată interacțiunea dintre partea multiplatformă și cea nativă. De exemplu, în WebView sau folosind Open GL ES / DirectX nu există nicio modalitate de a crea o interfață de utilizator cu un aspect complet nativ, dar în același timp există acces deplin la GPS, Notificări Push și alte funcționalități. Și codul în JavaScript sau C# poate controla destul de liber aplicația nativă și comportamentul acesteia, oferind un aspect complet nativ.

Pentru a rezuma, da, este „non-native” în ceea ce privește instrumentele de dezvoltare folosite (nu de la Apple, Google). Dar o aplicație poate fi complet nativă în ceea ce privește accesul la API-urile de sistem și poate oferi un aspect complet nativ. Și trecem la următorul mit.

Mitul 3. O cârjă pe o cârjă

Aici merită să înțelegeți că API-urile native nu sunt considerate cârje în mod implicit (deși aici există opinii diferite), așa că toată indignarea este îndreptată către partea multiplatformă. Evident, mediul de execuție (de exemplu, WebView, motor JavaScript sau Mono) este, de asemenea, greu de numit cârjă - soluții mature mature cu o istorie lungă.

Se pare că cârja este modul în care se integrează partea multiplatformă cu cea nativă. Pentru a înțelege mai bine cum funcționează diferitele cadre, folosind exemplul PhoneGap, Xamarin, Qt și React Native, ne vom uita la acele mecanisme ale sistemului de operare care sunt utilizate pentru a lega părțile multiplatforme și „native”.

Vom începe cu PhoneGap. Mai jos este arhitectura de nivel superior a unei aplicații bazată pe acest cadru.

O aplicație pe PhoneGap este de fapt o aplicație nativă care afișează un WebView ca singur control UI. Prin ea are loc interacțiunea cu partea nativă. Toate WebView-urile standard din iOS, Android și Windows UWP acceptă capacitatea de a adăuga propriile dvs. handlere native pentru proprietățile și metodele JS. În același timp, codul JS trăiește în propriul său mediu izolat și nu știe nimic despre partea nativă - pur și simplu trage metodele JS necesare sau modifică proprietățile JS necesare. Totul se află în interiorul web DOM standard, la care pur și simplu se adaugă elemente noi asociate cu implementarea nativă.

Când creează aplicații în React Native, dezvoltatorul va trebui aproape întotdeauna să implementeze partea nativă în Objective-C, Java sau C#, iar gestionarea aplicației native în sine va veni din JavaScript. De fapt, motorul JavaScript este un element WebView care este disponibil separat. Interacțiunea are loc prin aceeași punte JS ca și în cazul PhoneGap. Cu toate acestea, în React Native, codul JS nu controlează arborele web DOM, ci aplicația nativă.

Vă rugăm să rețineți că, din cauza limitărilor iOS (nu există nicio modalitate de a implementa JIT), codul JavaScript este interpretat din mers, mai degrabă decât compilat. În general, acest lucru nu are un impact semnificativ asupra performanței în aplicațiile reale, dar merită reținut.

Acum să ne uităm la Xamarin.iOS și Xamarin.Android clasic, deoarece Xamarin.Forms (care acceptă Windows UWP) este un supliment pentru acestea.

Xamarin folosește biblioteca Mono pentru a interacționa cu sistemul de operare țintă, ceea ce vă permite să apelați codul nativ folosind mecanismul P/Invoke. De asemenea, este folosit pentru a comunica cu API-urile native în iOS/Android. Adică, pentru toate metodele API native publice, wrapper-urile sunt create în C#, care, la rândul lor, apelează API-uri de sistem. În acest fel, puteți accesa toate API-urile de sistem din aplicația Xamarin.

Și, în sfârșit, să ne uităm la Qt, deoarece există o mulțime de întrebări despre acesta din partea dezvoltatorilor experimentați.

Qt este un „lucru în sine”, acesta are atât avantaje, cât și limitări. Bibliotecile Qt se conectează pur și simplu la API-urile sistemului C++ găsite pe toate sistemele de operare. Pentru a reda interfața cu utilizatorul, sunt folosite mecanisme de nivel scăzut, dar propriul motor grafic acceptă stilul nativ. În acest caz, pe Android trebuie să accesați API-ul Java printr-o punte specială (punte JNI), iar pentru Windows UWP, utilizați convertorul de apeluri Open GL ES în DirectX, deoarece Open GL nu este disponibil pentru UWP.

Pentru a rezuma: toate cadrele multiplatforme folosesc capabilități native standard ale sistemelor de operare, sunt mature și sunt create de echipe experimentate și de comunitatea open source cu sprijinul giganților din industria IT. Și, în sfârșit, este timpul pentru „cel mai puternic” argument.

Mitul 4. Încet

Un atu important pe care oamenilor le place să îl folosească în disputele legate de cadrele multiplatforme este performanța scăzută. Din nou, depinde de ce să compari și de ce papagali să numere.

Să ne amintim că particularitatea aplicațiilor multiplatforme este existența paralelă a două lumi conectate printr-un pod:

• PhoneGap: HTML/JS și Java nativ / Objective-C / C#;
• React Native: JS și Native Java / Objective-C / C#;
• Xamarin: mono și nativ Java/Obiective-C;
• Qt: C++ și Java nativ / Objective-C.

Astfel, atunci când comparăm performanța, trebuie să țineți cont de viteza de funcționare:

• parte cross-platform;
• parte nativă;
• pod.

Dacă introduceți într-un motor de căutare, de exemplu, reacționați performanța nativă versus performanță rapidă, puteți analiza multe teste diferite și multe dintre ele observă că performanța scade brusc odată cu utilizarea activă a podului, inclusiv manipularea activă a interfeței de utilizare din codul platformei. Pentru Xamarin, situația arată la fel - partea multiplatformă este foarte rapidă și comparabilă cu cea nativă în procesarea datelor, dar atunci când se folosește bridge-ul, performanța poate scădea. Qt funcționează în general la nivel C++, care este rapid în sine. Dacă luăm în considerare soluții bazate pe PhoneGap, atunci performanța va depinde în mare măsură de WebView, dar totuși nu ar trebui să schimbați în mod activ interfața de utilizare în codul JavaScript sau să efectuați calcule științifice.

Încet? Da, scăderile de performanță sunt posibile datorită interacțiunii inepte cu sistemul de operare prin bridge. Cu toate acestea, lumile multiplatforme sunt la fel de rapide ca și cele native.

*În acest articol, ne uităm la aplicațiile hibride bazate pe browser web.

Nativ sau hibrid - aceasta este întrebarea. Pentru a face alegerea corectă, trebuie să înțelegeți clar ce este fiecare tip de aplicație și ce scop servește.

Interesant! Conform statisticilor de la Flurry Analytics, petrecem 90% din tot timpul pe telefon în aplicații.

În timp ce fiecare tip are susținătorii săi înfocați, aplicațiile native și hibride se sufla unul în spatele celuilalt, ceea ce face dificilă alegerea unui câștigător clar.

Având mulți ani de experiență în dezvoltarea de aplicații native și hibride, am studiat temeinic caracteristicile ambelor tipuri. În acest articol am încercat să colectăm principalele avantaje și dezavantaje ale nativilor și hibrizilor, pentru a vă ajuta să faceți alegerea corectă.

APLICAȚII HIBRIDE ȘI NATIVE

Deci, prin ce diferă aceste două tipuri de aplicații unul de celălalt?

Aplicație nativă este nativ pentru fiecare platformă, indiferent dacă este iOS sau Android, și este scris special pentru aceasta într-o anumită limbă.

Pentru a scrie o aplicație nativă pentru iOS, se va folosi Swift sau Objective-C. Pentru aplicațiile native Android, Java sau Kotlin sunt potrivite.

Cu toate acestea, conform statisticilor de la VisionMobile, 47% din toate aplicațiile native iOS și 42% din toate aplicațiile native Android folosesc de fapt și HTML5.

Și iată un exemplu de aplicație nativă:

Renumita aplicație de comerț electronic Bounce a fost scrisă de dezvoltatorii noștri în Swift pentru iOS și Java pentru Android.

Aplicația este disponibilă în magazin AppleȘi Google Play.

Spre deosebire de nativ aplicații hibride sunt dezvoltate pentru ambele platforme simultan și scrise într-un limbaj universal.

Vă puteți familiariza cu hibrizii folosind exemplul celeilalte aplicații ale noastre, răspândită pe piața occidentală - LASIK pentru căutarea online a chirurgilor și programarea.

Aplicația este disponibilă în magazin AppleȘi Google Play.

Să aruncăm o privire mai atentă la fiecare dintre tipuri și să aflăm secretele lor cele mai adânci. Să începem cu aplicații hibride cu două fețe.

PRO ALE APLICAȚIILOR HIBRIDE

• Economisire . Dacă nu sunteți pregătit să vă goliți portofelul în căutarea aplicației perfecte, dar doriți o aplicație simplă la un preț accesibil, atunci hibridul este opțiunea dvs. Gândește-te doar cât vei economisi creând o aplicație pentru două platforme simultan!

• Intră pe piață pe 2 platforme deodată . Deoarece o aplicație hibridă este scrisă pentru două platforme simultan, ajunge pe două piețe simultan. Din acest motiv, se dublează și numărul de potențiali utilizatori, alături de șansele ca aplicația dvs. să fie descărcată. Cu toate acestea, aici se termină punctele forte ale aplicațiilor hibride și merită să acordați atenție punctelor slabe ale acestora.

DEZAVANTAJELE APLICAȚIILOR HIBRIDE

• Impracticabilitate . Chiar și o aplicație hibridă bine concepută poate deveni rapid învechită. Progresul nu stă pe loc, iar proprietarii de aplicații încearcă să țină pasul cu el. De îndată ce apar noile tehnologii, fiecare dintre proprietari încearcă să adauge o funcție ciudată aplicației lor cât mai curând posibil. Din nefericire pentru hibrizi, va dura 3 până la 6 luni pentru a schimba cadrul și adăugați-i o nouă funcționalitate. Abia atunci dezvoltatorii vor putea să-ți îmbunătățească și aplicația. În aplicațiile native, inovațiile pot fi adăugate imediat după ce sunt anunțate.

Este puțin probabil ca aplicația noastră să fie solicitată în rândul utilizatorilor dacă se dovedește a fi de proastă calitate și instabilă:

Conform statisticilor, aproape jumătate dintre utilizatori elimină imediat aplicațiile plictisitoare și prost proiectate de pe smartphone-urile lor și instalează în locul lor alte aplicații, mai competitive.

• Viteza mica . Adesea, aplicațiile hibride sunt pagini web care nu sunt deosebit de eficiente, de exemplu, în defilarea conținutului greu: imagini, animații etc.

Defilare – defilare verticală sau orizontală a unei pagini.

În plus, dezvoltarea hibridă bazată pe aspect web suferă diverse compilații, ceea ce reduce și viteza aplicației și nu mulțumește deloc utilizatorii.

Compilarea este procesul de traducere a unui limbaj de programare de nivel înalt (PHP, Java, JavaScript) în limbaj de mașină.

• Provocări de proiectare . Dacă doriți ca aspectul aplicației dvs. să se potrivească cu designul de sistem profesional și bine cercetat al fiecărei platforme, fie că este iOS sau Android, va trebui să proiectați pentru ambele sisteme de operare separat. Aplicațiile iOS și Android au propriile standarde de design unice și, deoarece o aplicație hibridă nu îndeplinește aceste standarde, aspectul său va trebui ajustat pentru a se potrivi cadrului corespunzător. Se pare că la sfârșitul lucrării vei primi o singură cerere, dar ai cheltuit timp și bani pe două.

• Nesiguranța codului sursă . Unul dintre dezavantajele serioase ale aplicațiilor hibride este nesiguranța acestora. În timp ce o aplicație nativă poate fi criptată înainte de a fi lansată în magazinul oficial, o aplicație hibridă rămâne „dezgolită”. Deoarece multe aplicații hibride se bazează pe o pagină HTML, nu costă nimic să te uiți la codul sursă și să înțelegi cum funcționează aplicația în sine. Cel puțin, codul tău poate fi furat. Cel mult, un atacator poate folosi aplicația dvs. în propriile sale scopuri egoiste, de exemplu, pentru a obține informații și date private despre aplicație.

AVANTAJE ALE APLICAȚILOR NATIVE

• Calitate superioară . Un dezvoltator nativ de aplicații foarte specializat vă va scrie cod curat și unic. Mulți ani de experiență în dezvoltare și standarde clare pentru aplicațiile native iOS și Android vă vor ajuta să creați un produs de înaltă calitate, cu funcționalități largi și să reduceți aproape la minimum riscul de erori.
• Probabilitate scăzută de respingere pentru plasarea în App & Play Stores . Deoarece o aplicație nativă îndeplinește inițial cerințele standard ale unei anumite platforme, este puțin probabil să întâmpinați probleme la lansarea aplicației pe App Store și Play Store oficiale.
• Utilizarea 100% a designului UX . Utilizatorii moderni sunt răsfățați de interfețe colorate și detaliate, iar aplicațiile simple și standardizate este puțin probabil să-i intereseze. În dezvoltarea nativă, designul UX este utilizat 100%, ceea ce vă permite să creați o aplicație de înaltă calitate și interesantă. Cu o aplicație hibridă, obțineți o interfață standardizată pe ambele platforme.

• Varietate de instrumente de dezvoltare . Datorită multor ani de experiență în dezvoltarea de aplicații native, există un număr mare de cadre diferite, șabloane și alte instrumente dovedite care vă vor permite să vă faceți aplicația unică, individuală și stabilă.
• Comunitate mare de dezvoltatori . Și, desigur, atunci când dezvoltați o aplicație nativă, este puțin probabil să întâlniți o problemă pe care nimeni nu a rezolvat-o până acum. Aceasta înseamnă că nu va trebui să petreceți timp suplimentar căutând o soluție potrivită, ci veți putea apela la experiența altor programatori.

DEZAVANTAJELE APLICAȚILOR NATIVE

• Preț . După cum se spune, brânza gratuită este doar într-o capcană pentru șoareci. O aplicație nativă este un produs unic, de înaltă calitate, a cărui creare necesită mult timp și, desigur, un dezvoltator înalt calificat, cu mulți ani de experiență. Prin urmare, o astfel de aplicație costă în consecință.

FAPT INTERESANT

Vei fi surprins când vei afla ce este cu adevărat dezvoltarea unei aplicații native iOS costă mai puțin decât un hibrid . Nu mă crezi? Convinge-te singur!

Când dezvoltați o aplicație nativă, aveți o mare varietate de instrumente incluse în SDK-ul unei anumite platforme. Adică, tot ce ai nevoie este să folosești aceste instrumente în aplicația ta nativă.

În cazul unui hibrid, trebuie doar să speri că există o adaptare pentru unul sau altul instrument nativ pe baza cadrului ales pentru dezvoltarea hibridă.

Dacă nu există un astfel de instrument, va trebui fie să așteptați să apară, fie să luați în considerare cadre alternative, adică există mult mai multe bătăi de cap cu un hibrid.

Pe baza acestui lucru, se dovedește că, creați o aplicație nativă iOS este mai ieftină decât o aplicație hibridă iOS.

Dacă comparăm dezvoltarea unei aplicații hibride și a celor două native, prețul hibridului va fi mai mic, așa cum era de așteptat, deoarece într-o aplicație hibridă backend-ul și frontend-ul sunt potrivite pentru două platforme simultan.

Într-o aplicație nativă, trebuie să dezvoltați două front-end-uri separate care să îndeplinească standardele general acceptate ale fiecărei platforme.
De aici preturile:

APP HIBRID iOS– 11,5 mii USD
APLICAȚII HIBRID iOS + Android
12,5 mii USD

APLICATIE NATIVE pentru iOS– 10.000 USD
APLICAȚII NATIVE pentru iOS + Android
18.000 USD

Cu toate acestea, dacă te uiți cu atenție, vei observa că costul aplicațiilor native nu este cu mult mai mare decât costul celor hibride.

Acum gândiți-vă dacă să economisiți bani atunci când dezvoltați o aplicație sau nu? Sau poate faceți două native deodată?

La urma urmei, atât aspectul aplicației, cât și cât de convenabil și de înaltă calitate va fi sunt foarte importante pentru utilizatori.

CE APLICAȚIE AR TREBUI ALEG?

In acest caz, vei fi 100% sigur ca banii nu au fost irositi si ca urmare vei primi exact aplicatia pe care ai comandat-o.

ASA DE ,

Alegeți o aplicație hibridă daca vrei sa primesti:

• aplicare simplă
• aplicație pentru două platforme la un preț de buget
• 1 aplicație cu capacitatea de a intra rapid pe două piețe (IOS/Android)

Alegeți o aplicație nativă, dacă aveți nevoie:

• aplicație profesională care îndeplinește toate standardele platformei selectate
• aplicație complexă cu funcționalitate largă
• aplicare de mare viteză

Acum că știți totul și mai multe despre aplicațiile native și hibride, puteți face cu ușurință alegerea potrivită.

Realizează-ți toate cele mai nebunești vise și idei .