Aplicații hibride, native și web, sisteme magora

Dar cine trebuie să aibă încredere? Când vrem să cumpărăm un produs sau un serviciu, comunicăm cu vânzătorii, care, din păcate, nu sunt experți în această problemă. În opinia mea, există o singură cale de ieșire în această situație. Luați totul în mâinile dvs. și, cel puțin superficial, să vă înțelegeți problema care vă interesează sau să găsiți un profesionist în acest domeniu și să obțineți părerea lui. Să o facem. Întrebarea în care vom înțelege este: "Care este mai bine - aplicații native sau hibride pentru platforme mobile?".

Hibrizi versus drepți

Îndepărtăm capacul

Se pare că acum știm diferența dintre aplicațiile hibride și cele native. Pe aceasta puteți încheia în siguranță articolul și preluați codul de scriere. Dar nu! Ne amintim: "Nu cred vânzătorii!". Și cei mai mulți dintre cei care au scris toate aceste puncte - sunt vânzătorii, într-o formă sau alta. Deci, înțelegem mai departe.

Aplicații Web

Ideea exactă a unui site care arată ca o aplicație este, desigur, interesantă. Această abordare are atât dezavantaje, cât și anumite avantaje. Dar există o mare întrebare: "De ce?". Imaginați-vă că sunteți un utilizator care nu este împovărat de cunoștințe speciale în domeniul tehnologiilor IT. Deschideți un site web și ... Oh, Doamne! Am o aplicație! Demoni! Acesta este probabil un virus de un fel! Deși opriți, de ce este vizibil șirul browserului? Acesta este un site care - dacă asta? Sau este o aplicație? Hmm, lista de instalat nu este. Lucrează foarte încet. Voi instala o aplicație mai bună, dar nu o primiți.

În general, semnificația acestei mimicii nu este destul de clară. De ce să inducăți în eroare utilizatorul? La urma urmei, cineva poate crede că aceasta este o aplicație și așteaptă comportamentul corespunzător aplicației normale. Vreau să dau următoarea comparație: vom găsi o piatră sănătoasă de formă rotundă și o vom picta astfel încât să pară un fotbal. Apoi intrebam pe primul jucator de fotbal de durere, cu un picior stricat, despre impresiile sale legate de designul nostru original.

Deoarece nu am multă experiență cu PhoneGap și alte cadre de acest gen, am decis să discut această problemă cu dezvoltatorul nostru JS / HTML, care a scris programul folosind cadrul PhoneGap. Se pare că în prezent majoritatea problemelor descrise sunt rezolvate. Pe această pagină, Lordul negru deghizat ne promite că acum reacția la cliques va trece rapid și fără durere. Există o mașină și un cărucior mic de diverse plug-in-uri. care permit accesul la diferite sisteme ale dispozitivului țintă. Și dacă nu este nimic, puteți scrie propriul plug-in. Și se pare că aici este - o soluție excelentă pentru dezvoltarea pe mai multe platforme a dispozitivelor mobile! Dar să ne gândim profund la această problemă.

Ce știi despre durere? WebView pentru Android versiunea 4.3 este extrem de lentă atunci când trebuie să arate ceva mai complicat decât textarea. În versiunea 4.4, motorul pentru WebView este Chromium, deci poate că acest lucru va rezolva puțin situația. În general, pentru toate phonogames și ilk lor, aceasta înseamnă durere și suferință atunci când încearcă să lanseze aplicația pe Android. Pe iOS, situația cu acest lucru este mult mai bună, deoarece motorul de pe safari funcționează mai bine.
- Scuzați-mă, sunteți femeie? - Voi fi ceea ce vrei, puștiule. În funcție de dispozitiv, pot fi utilizate diferite stiluri pentru interfața aplicației. Acest lucru, desigur, nu este rău, dar logica designului nu se schimbă. Există un buton Back pe iOS - aceasta înseamnă că va fi pe Android. Și nu contează că nimeni nu o vrea acolo. Un alt exemplu este Bara de acțiune. Pe iOS, este situat în mod tradițional în partea de jos a ecranului, pe Android - în partea de sus a ecranului. În aplicația din PhoneGap, Actiobar nu va schimba poziția în funcție de dispozitiv, ci va arăta diferit. Și încă un lucru: fiecare OC are anumite trăsături. De exemplu, animație. Uită-te la iOS și Android. Animarea tranzițiilor între ecrane. Este diferit! Aplicațiile hibride nu vor putea să reproducă aceste caracteristici.
Ruina nu se află în dulapuri, ci în capete. Un alt factor important, care, din anumite motive, nimeni nu ia în considerare. Dezvoltatorii pe PhoneGap sunt, de obicei, dezvoltatori Front-end. Ei nu au nici o idee despre modul în care interfața ar trebui să caute Android sau iOS, deoarece nu au citit ghiduri de stil. Ei nu știu nimic despre caracteristicile platformei, pentru că nu au citit documentația. Dar ei sunt buni în a face site-uri web. În consecință, primiți o aplicație care arată ca un site web. O vrei? Chiar ai nevoie de ea? Uită-te la fotografia asta? Încă mai aveți încredere în alegerea dvs.?

Aplicații hibride, native și web, sisteme magora

În general, ce vreau să spun? Cross-platforma în acest caz, imaginar, și aplicațiile vor arăta ciudat. Cred că aplicațiile hibride ar trebui să fie utilizate ca prototipuri, unde puteți evalua reacția utilizatorului la ideea dvs. și puteți obține feedback. Pentru versiunea de producție, este mai bine să folosiți aplicații native. Acest raționament este relevant pentru toți hibrizii care lucrează la pachetul HTML / JS.

Despre nativ nu voi scrie nimic special. Aici și totul este clar. Lucrează rapid, arată bine, au capacități de personalizare largi. Și sunt vrednici. Deși primele trei elemente sunt relevante numai dacă nu ați angajat o echipă de profesioniști puternici cu șapte ani de experiență din New Delhi.

Tru cross-platform

În opinia mea, un singur cadru care vă poate permite să scrieți o aplicație mobilă cross-platform în acest moment este C ++ Qt. Acest cadru generează codul nativ Android utilizând Android NDK. Prin urmare, performanța ar trebui să fie la nivelul codului scrise de programator cu ajutorul SDK-ului Android, iar pentru fragmente folosind calcule mai grele, chiar mai mari - datorită NDK. Qt este o bibliotecă de calitate testată. Acest lucru înseamnă că nu veți fi în curs de a prinde orice bug-uri stângaci. În caz de orice problemă, puteți să aruncați o privire la codul sursă Qt. Aceasta este, într-adevăr, o oportunitate foarte necesară pentru dezvoltatori. În unele cazuri, acesta este singurul mod de a depăși bug-ul. Pentru a obține programul pentru platforma țintă (Android sau iOS), trebuie doar să recompilați sursele. Deși, din câte știu, uneori încă mai trebuie să scrieți codul nativ pentru platformă, deoarece nu toate caracteristicile sunt accesibile prin bibliotecile Qt. Sper că acest lucru va fi repede în curând.

Dar există și dezavantaje. Pentru dezvoltarea producției, va trebui să achiziționați o licență Qt - care, prin urmare, costă bani. Pentru incepatori, aceasta este o problema serioasa. În plus, în prezent, Qt pentru dezvoltarea mobilă este încă umedă. Așteptăm următorii versiuni.

În momentul de față nu există niciun mijloc care să poată fi numit cu o conștiință clară un mediu real-cross-platform pentru dezvoltarea aplicațiilor mobile. Poate că în viitor acest loc va fi ocupat de Qt, dar în acest moment este vacant. Pentru a vă testa ideea dezvoltând un prototip, puteți utiliza o varietate de cadre JS / HTML, dar nu le recomand să le folosiți pentru a dezvolta aplicații de producție complexe. În această sferă de dezvoltare nu există o alternativă la aplicațiile native în acest moment.

Articole similare

Pagina anterioară