Napról napra nő a mobilfelhasználók száma, és fejlődik a globális mobilalkalmazás-piac. Egy hozzáértő üzletember nem tudja nem észrevenni ezt a tendenciát, és mindent megtesz, hogy csatlakozzon hozzá. A mobilalkalmazás remek lehetőség egy startup számára.
Az első kérdés, ami felmerül a fejében, hogy milyen fejlesztési technológiát használjon az alkalmazás létrehozásához?
Három megközelítés létezik a fejlesztésre: natív, cross-platform és hibrid. Mindegyiknek megvan a maga sajátossága, és más-más eredményhez vezet. Annak érdekében, hogy ne befolyásoljon egy outsourcing cég választása, és azt fejlesszük, ami a legtöbb megfelel az Ön vállalkozásának sajátosságainak, hasonlítsunk össze minden technológiát.
Natív megközelítés
Az alkalmazást minden platformon „natív” nyelven fejlesztették ki: Java Androidra és Objective-C / C++ IOS-re.
Kezdetben ezt a módszert az eszközbe „beépített” alkalmazások fejlesztésére használták - ébresztőóra, böngésző, galéria, zenelejátszó.
Platformok közötti megközelítés
Ha natív megközelítésben ugyanazt az alkalmazást külön-külön fejlesztik iOS-re és Androidra, akkor a cross-platform megközelítésben mindent egyszerre fejlesztenek.
Az alkalmazás minden platformon működni fog.
A programozási nyelvek szabványosak, mintha webhelyet fejlesztene - HTML és CSS.
Hibrid megközelítés
A hibrid alkalmazások egyesítik a natív és a többplatformos fejlesztés jellemzőit.
Lényegében ez egy többplatformos alkalmazás egy „natív” héjon belül.
A felület a többplatformos alkalmazáshoz hasonlóan okostelefonos böngészőt használ, de a reszponzivitást és nagy teljesítményt igénylő elemeket anyanyelven fejlesztik.
Most, hogy röviden megértettük az egyes fejlesztések jellemzőit, elemezzük, melyik típust válasszuk, figyelembe véve az induló igényeit.
Natív fejlődés
1 Teljesítmény és sebesség
Az alkalmazást egy adott platformra fejlesztették ki, amelyen a lehető legproduktívabban fog működni. Ez a szolgáltatás hatékonyan használja az okostelefon akkumulátorát és memóriáját. A kód gyorsabban fut, és az új funkciók gyorsan és egyszerűen integrálhatók.
A gesztusok, a többérintéses és a földrajzi helykövetés könnyebben megvalósítható.
2 Felhasználói élmény
Ha az ügyfél hozzászokott az Android felülethez, akkor kényelmetlenül érzi magát az IOS operációs rendszer használata során. A natív alkalmazás tervezése magabiztosságot és intuitív megértést ad a felhasználóknak a megjelenésről és a funkcionalitásról.
3 Nincs korlátozás
Az alkalmazás teljes hozzáféréssel rendelkezik az okostelefon szolgáltatásaihoz és funkcióihoz (adatbázisok, földrajzi helymeghatározás, kamera).
4 Könnyű tesztelés
Az alkalmazások teljesítménye könnyen nyomon követhető. Ha egy alkalmazás a vártnál több memóriát vagy több CPU-erőforrást fogyaszt, ez azonnal látható lesz a tesztelés során.
5 Elérhetőség
A felhasználók letölthetik az alkalmazást a „natív” üzletekből: App Store, Google Play
6 Alkalmazkodóképesség
Nagyszámú Android-eszköz van a piacon, és hatékonyabb, ha natív fejlesztéssel mindegyikhez igazítjuk az elrendezések kialakítását.
Hibák
1 Fejlődési sebesség
Ha az iOS-t és az Androidot is le szeretné fedni az alkalmazással, akkor ez tovább tart. A folyamat két különálló alkalmazás fejlesztését foglalja magában.
2 Fejlesztési költségek
Az egyes platformok külön fejlesztéséhez több személyzetre van szükség, ami több költséget jelent.
3 Szolgáltatás és támogatás
Ha egy alkalmazással dolgozik, folyamatosan keresnie és javítania kell a hibákat, frissítéseket kell végrehajtania - két platform esetében ez kétszer annyi időt és erőforrást igényel.
1 Fejlesztési sebesség és költségcsökkentés
A natív fejlesztéssel ellentétben egy alkalmazást csak egyszer fejlesztenek minden platformra. Ez csökkenti a költségeket és csökkenti a létrehozási időt. Ezzel a módszerrel olcsóbb az alkalmazás elkészítése.
2 Szolgáltatás és támogatás
A többplatformos alkalmazások fejlesztési ciklusa egyszerűbb. Ha valamit javítani vagy frissíteni kell, akkor ez minden platformon egyszerre megtörténik.
Hibák
1 Fejlesztési sebesség és költségcsökkentés
Annak ellenére, hogy a fejlesztési ideológia szerint ezt a pontot pozitívumként jegyzik meg, a gyakorlat azt mutatja, hogy a két operációs rendszerre történő megvalósítás sok hibát okoz. Ez megnöveli a hibák kijavításához szükséges időt. A felhasználói felület másként jelenik meg, és az alkalmazkodási idő is nő.
2 Gyenge teljesítmény
A legszembetűnőbb problémák az animációkkal, kattintással és görgetéssel jelentkeznek – az alkalmazás lefagyhat. A felhasználói felületet HTML-ben fejlesztették ki, de hónapokat kell töltenie, hogy elérje a natív platform teljesítményét.
3 Felhasználói élmény
Olyan felületet kell kifejleszteni, amely az iOS és az Android felhasználók számára is intuitív lenne.
Ellenkező esetben az iOS Human Interface Guide szerint készült alkalmazás kényelmetlen lesz az Android felhasználók számára. És végül több időt fog fordítani a felhasználói élmény javítására.
4 Felhívás a „bennszülöttekhez”
A natív szabványos megoldások még mindig nincsenek megoldva a platformok közötti fejlesztésben. Ezért a natív fejlesztőket gyakran bevonják a funkcionalitás megoldására.
Ha több platform nyer:
- Mobil játékterület
- Amikor gyorsan piacra kell lépnie, hogy tesztelje üzleti ötletét, vagy ha van egy webhelye, amelyet minimális költséggel szeretne alkalmazássá alakítani.
Ha a projekt célja a hosszú távú fejlesztés, zavartalan működés és gyors reagálás szükséges - használjon natív fejlesztést!
Következtetés: a platformok közötti fejlesztés szinte minden előnye mítosz a gyakorlatban, és nem a költségek csökkenéséhez, hanem a költségek növekedéséhez vezet.
Ebben a cikkben 6, 2016-ban népszerű platformok közötti fejlesztési megoldást fogunk összehasonlítani, és megpróbáljuk megtalálni a legjobb megoldást.
A többplatformos keretrendszerek PhoneGap, Xamarin, Unity, Qt és Appcelerator Titanium, Telerik Platform jelenleg a mobileszközök platformok közötti fejlesztési piacának 80%-át foglalja el.
Az alábbi táblázat az egyes keretek főbb jellemzőit mutatja be:
| PhoneGap | Xamarin | Egység | Qt | Appcelerator Titanium | Telerik AppBuilder | |
| Nyelvek | JavaScript, HTML5, CSS3 és natív nyelvek (Java, Objective-C, C#) | C#, Xaml | C#, UnityScript, Boo | C++ QML | JavaScript, Python, Ruby, PHP | .Net, JavaScript, HTML5, Java, PHP |
| Támogatott platformok | Android, iOS, Windows Phone, Blackberry, WebOS, Symbian, Bada, Ubuntu, Firefox OS. | iOS, Android, Windows Phone és Windows 8/RT, Tizen | Android, iOS, Windows Phone, Tizen, PS 4, Xbox One | Android, iOS, WinRT, Windows, Symbian, Linux, QNX | iOS, Android, BlackBerry, Windows, Tizen, Denso | iOS, Android, BlackBerry, Windows, Windows Phone |
| Árak | PhoneGap árak Fizetett verzió: 9,99 dollártól Ingyenes verzió: elérhető Adobe Creative Cloud-tagság: Elérhető |
Árak Xamarin Xamarin Studio közösség: Ingyenes Visual Studio közösség: Ingyenes Visual Studio Professional: Elérhető Visual Studio Enterprise: Elérhető |
Árak Egység Személyes kiadás: ingyenes Professzionális kiadás: havi 75 dollártól |
Árak Qt Van egy ingyenes verzió. A fizetős verziók 79 dollártól kezdődnek. |
Árak Appcelerator Indie: 39 dollár havonta Ingyenes próbaidőszak van Ár havi 39 dollártól |
|
| Nyílt forráskódú | + | - | - | + | + | - |
| UI | Web | Bennszülött | UI Canvas | Bennszülött | Bennszülött | Web |
PhoneGap
A PhoneGap lehetővé teszi mobil alkalmazások létrehozását szabványos webes technológiák (HTML5, JavaScript és CSS3) használatával. Ennek eredményeként ez a keretrendszer népszerűségének gyors növekedéséhez vezetett, anélkül, hogy fejlődne olyan programozási nyelveken, mint a Java for Android, Objective-C iOS és C#. A PhoneGap Build lehetővé teszi iOS, Android és Windows Phone egyidejű buildek készítését, anélkül, hogy SDK-eszközöket kellene telepíteni (persze van ebben némi ravaszság - fejlesztéskor még mindig jobb helyben építeni, legalább Androidon , mielőtt elküldi tesztelésre). De ami még ennél is fontosabb, ez a szolgáltatás lehetővé teszi az iOS felhőben való felépítését anélkül, hogy Mac gépet kellene használnia.
A PhoneGap telepítése hihetetlen erőfeszítést igényel, ezért azt tanácsolom, hogy szabadítson fel fél napot... Csak viccelek. Az XCode telepítése körülbelül 3 percig tartott – az archívum letöltéséből, a kicsomagolásból és a telepítésből állt. Ez minden.
A PhoneGap lehetőséget biztosít a mobileszköz natív funkcióinak használatára a következőkhöz:
- gyorsulásmérő,
- kamera,
- iránytű,
- kapcsolatok,
- fájl tárolása,
- földrajzi helymeghatározás,
- adatbázis
- események, értesítések,
- média stb.
Előnyök:
- A PhoneGap egy egyszerű API-val rendelkezik, amely megkönnyíti a fejlesztés megkezdését azok számára, akik találkoztak HTML-lel, CSS-sel és JavaScripttel.
- Lehetőség bármilyen meglévő JavaScript-könyvtár használatára (JQuery, Prototype, Sencha Touch)
- Támogatja az összes mobil platformot
- A felhasználói felület a beépített böngésző segítségével történik. Ez megnehezíti a visszajelzést, mint egy natív alkalmazás.
- A meglévő bővítmények gyakran elavultnak bizonyulnak, ezért néha meg kell írnia a sajátját.
Xamarin
A Xamarin a második keresztplatformos keretrendszer a listánkon. A Xamarin lehetővé teszi egyetlen alkalmazáslogika létrehozását C# és .NET használatával. Funkcionálisan a Xamarin platform számos alplatformot képvisel. Ezek az alplatformok nagy szerepet játszanak – rajtuk keresztül az alkalmazások a kéréseket az eszközök alkalmazási felületeire irányíthatják. A vizuális felület definiált, a logika C#-ban kötött, és mindez Androidon, iOS-en és Windows Phone-on is működni fog. Videó a Xamarin alkalmazás fejlesztéséről.
Előnyök:
- Nagy és növekvő közösség.
- A fejlesztők a TestCloud segítségével automatikusan tesztelhetik az alkalmazásokat.
- Ha már ismeri a C#-ot és a .NET-et, akkor nem kell sok időt töltenie több új keretrendszer megtanulásával.
- A már megírt kódot újra felhasználhatja.
- A különböző rendszereken futó alkalmazások nagyon hasonlóak lesznek.
- Az iOS dinamikus elrendezése végtelenül egyszerűbb, mint a kényszerek manuális használata.
- A CustomRenderersnek köszönhetően a szabványos vezérlők egyszerűen kiegészíthetők tetszőleges tulajdonságokkal (például a gombok színátmenetes kitöltése néhány percet vesz igénybe, bár a dobozból ez nem működik).
Hibák:
- Egyes interfészmintákat nehéz monodroidon, monotouch esetén pedig nagyon nehéz megvalósítani, mivel ennek vagy annak a funkciónak az alapértelmezett megoldása platformmankókra támaszkodik, amelyek egyszerűen nem működnek a Xamarinban.
- Problémák vannak a mono, monotouch és monodroid platformokkal. Az alkalmazásnak meg kell felelnie bizonyos stabilitási követelményeknek.
- Az Android-oldalak nem helyezhetők el meglévő tevékenység/töredék részeként.
- Nem minden vezérlő van végrehajtva.
Telerik AppBuilder
Az AppBuilder használatának egyik fő oka a teljes értékű online IDE. Lehetővé teszi mashupok létrehozását, tesztelését és akár közzétételét bármilyen számítógépről vagy mobileszközről anélkül, hogy le kellene töltenie. További előnyt jelent a Windows vagy Linux rendszeren futó iOS-alkalmazások létrehozásának lehetősége.
Előnyök:
- A Telerik Visual Studio és Sublime Text bővítményeket biztosít az AppBuilder számára.
- Az AppBuilder gyors módot kínál a Cordova bővítmények importálására.
- Teljes értékű online IDE.
- Könnyen használható és tanulható
Hibák:
- Kis közösség
Egység
A 2D-s és 3D-s alkalmazások és játékok fejlesztésére szolgáló többplatformos Unity a 3D-s tartalmak bemutatásának egyik legjobb eszköze. A Unity segítségével létrehozott alkalmazások Windows, OS X, Linux, Android, Apple iOS, Windows Phone, BlackBerry operációs rendszereken, valamint Wii, PlayStation 3 és Xbox 360 játékkonzolokon működnek. Videó mobiljáték fejlesztésével Unity-n . Előnyök:
- Remek lehetőség mobiljátékok létrehozására számos eszközön
- A 3D motor kiváló minőségű eredményeket produkál bonyolult konfigurációk nélkül
- Sok jó ingyenes plugin létezik
- A Unity lehetővé teszi a fejlesztő számára, hogy saját árnyékolókat készítsen, és módosítsa a Unity által a játék megjelenítési módját.
Hibák:
- UI és nehezen használható kezdőknek
- A forráskód nem érhető el
- A Unity fordítók egyes mobileszközökön nincsenek ARM processzorokhoz optimalizálva.
Előnyök:
- A Qt számos jó eszközzel segíti a fejlesztést, például: IDE QT Creator, Qt Designer és kódprofilozás.
- Olyan könyvtárakat tartalmaz, amelyek intuitív API-kat tartalmaznak olyan elemekhez, mint a hálózatok, animációk és egyebek.
Hibák:
- A Qt nehéz a kezdőknek
Appcelerator Titanium
A Titanium egy teljesen nyitott platform webalkalmazások fejlesztésére, üzembe helyezésére, terjesztésére és végső soron futtatására. Az Appcelerator Titanium lehetővé teszi mobilalkalmazások létrehozását JavaScript, HTML és CSS nyelven. Bármely jelenleg népszerű operációs rendszerrel létrehozhat modern, és ami a legfontosabb, natív alkalmazásokat: Windows, GNU/Linux vagy MacOS X.
Az ezzel az SDK-val létrehozott alkalmazások valóban natívak lesznek. Az Android navigációs vezérlője ismerősnek és másnak tűnik, mint az iOS rendszeren. Sőt, nemcsak a megjelenés, hanem maga az alkalmazáskód is natív lesz. Ez egyébként nem akadályozza meg abban, hogy klasszikus WebView-t hozzon létre és töltse fel a kívánt webtartalommal.
Előnyök:
- A JavaScript megkönnyíti az alkalmazások fejlesztését platformnyelvek használata nélkül.
- Az Appcelerator lehetővé teszi, hogy valós időben végezzen elemzést
- A natív API használata jobb teljesítményt biztosít a nem túl nagy alkalmazások számára.
Hibák:
- A könyvtár betöltése miatt késések vannak az alkalmazás indításakor
- Nehéz összetett alkalmazásokat létrehozni, mert a JavaScript használata negatív hatással van az alkalmazások teljesítményére.
React Native
Mi az a React Native? Ez egy JS-keretrendszer, amely JS-n és Reacton alapul – egy JS-könyvtár a felhasználói felület létrehozásához (nézeti szint). A technológia nagyon ígéretes, de fiatal, így néhol még nyers a platform. Az androidos verzió később jelent meg, így egyelőre több komponens található az iOS alkalmazásokhoz. Érdemes megfontolni azt is, hogy az alkalmazás telepítésekor az összes JS a felhasználó eszközére kerül, így nem szabad megtartani az üzleti logikát a prezentáció szintjén. Elmondhatjuk, hogy a React Native most már használható a webalkalmazások mobilverzióinak gyors prototípusára. Sőt, ha a webalkalmazás már ReactJS-ben van írva, akkor az átviteli sebesség jelentősen megnő. Példa a React Native használatával történő fejlesztésre.
Előnyök:
- Egységes munkafolyamat és eszközök: mindegy, hogy Android vagy iOS verzióval dolgozik, továbbra is ugyanazokat az eszközöket használja.
- Emiatt - a fejlődés sebessége és könnyűsége.
- Egy örökölt alkalmazás összekapcsolása a JS API-val és a hibrid alkalmazásokkal: Tegyük fel, hogy már van egy kész iOS-alkalmazása, és szeretne átváltani a React Native alkalmazásra. Ezután becsomagolhatja a natív összetevőket, hogy azok elérhetőek legyenek a React Native alkalmazásban. Így fokozatosan áttérhet a Reactra, és az eredmény egy hibrid alkalmazás lesz – ennek fele natív, fele React, valamint néhány örökölt összetevő a JS API-ban.
Ma azt javasoljuk, hogy találja ki, miben különbözik a tervezőben létrehozott alkalmazás attól, amelyet a stúdióban fejlesztenek Önnek.
A natív alkalmazásokat egy adott platform paramétereihez és tulajdonságaihoz tervezték(mobil operációs rendszer, a hozzá tartozó ökoszisztéma és magának a mobileszköznek a műszaki jellemzői), és használja a hardverplatform minden olyan képességét, amely az alkalmazással való működéshez szükséges - a kamerától és a GPS-modultól a gyorsulásmérőig, kézmozdulatvezérlésig és egyéb hardverekig - Egy adott okostelefon vagy táblagép támogatott tulajdonságai. Ezenkívül a stúdióban fejlesztett natív alkalmazás késztermékként beszerezhető, és elhelyezhető egy mobil alkalmazásboltban (például Google Play vagy Apple App Store).
A natív alkalmazás az egyes eszközök értesítési rendszerét is használja, támogatja a Push értesítéseket és offline módban is működhet.
Mit alkot a legtöbb online tervező?
Megjelent, de inkább nevezhetjük próbaeszközök listájának (hogy lássuk, hogyan fog kinézni az alkalmazás „a valóságban”), semmint teljes értékű megoldásnak azok számára, akik a semmiből szeretnének egy alkalmazást létrehozni.Az online tervező nem natív, hanem webes alkalmazást készít, amely nem a klasszikus értelemben vett szoftvertermék, lényegében egy speciális weboldal, amely úgy néz ki és úgy működik, mint egy natív alkalmazás, de valójában nem az. Általános szabály, hogy működéséhez telepített és konfigurált böngészőre van szükség egy internet-hozzáféréssel rendelkező mobileszközön. Maga a webalkalmazás HTML5 felhasználásával készült. Ez részben magyarázza a webes alkalmazások növekvő népszerűségét (és azt a tényt, hogy a Samsung új Tizen mobil operációs rendszere és egyes Android-változatai webalkalmazásokat használnak ezzel a technológiával).
Egy ilyen webes alkalmazás nem minden projekthez alkalmas (különösen, ha a blogokat tartalmazó média- és hírprojektek megelégedhetnek a HTML5 képességeivel, akkor egy ilyen megoldás nem alkalmas online áruházakhoz és nagy terhelésű oldalakhoz).
Ezen túlmenően, egyes üzletekben nem lehet közzétenni egy webalkalmazást a mobilszoftverek terjesztésére, ezért nehezebb a fizetési modult és néhány egyéb funkciót megvalósítani, amelyekkel a natív alkalmazások rendelkeznek. A natív alkalmazásokkal ellentétben a webes alkalmazások sem használják ki az okostelefonok összes képességét, mert... nem férnek hozzá teljes mértékben a hardverplatformhoz és annak összetevőihez.
Vannak hibrid alkalmazások is (a tervező is segít ezek elkészítésében). A hibrid alkalmazások részben natív funkcionalitást, részben a webalkalmazások képességeit használják. A natív alkalmazásokból átvették azt a lehetőséget, hogy online terjesztési platformokon publikáljanak, és támogassák az okostelefonok hardveréhez való hozzáférést. A webes alkalmazásokból HTML-támogatással rendelkeznek, és a böngészőben működnek.
A cégek gyakran bedőlnek a hibrid alkalmazások vonzerejének és elérhetőségének, mind az ár, mind a fejlesztési sebesség tekintetében (lebilincselő az is, hogy a tervezőben egy ilyen alkalmazást egyszerre több platformra is fel lehet építeni).
Ennek azonban megvannak a maga hátrányai is, amelyek általában észrevehetők az alkalmazástervezés során: előfordulhat, hogy az egyik platform natív „szolgáltatásai” nem működnek megfelelően a másikon, és fordítva. Ennek eredményeként kiderül, hogy még egy hibrid alkalmazás sem nélkülözi a webalkalmazások hátrányait.
Mit érdemes választani?
Mindegyik alkalmazástípusnak megvannak a maga előnyei és hátrányai, itt csak a legjelentősebbek:Hozzáférés az eszköz képességeihez: A natív alkalmazások teljes hozzáféréssel rendelkeznek a hardverplatformhoz, de a webes alkalmazások nem rendelkeznek ilyen képességekkel. Tehát ha a kamera, a földrajzi helymeghatározás és a vezeték nélküli adatátvitel lehetőségeit szeretné használni, akkor egy natív, nem pedig adaptív alkalmazás megfelelő az Ön számára.
Internet hozzáférés nélkül működik: A natív alkalmazást választja, ha fontos, hogy mindenféle internetkapcsolat nélkül működjön. A webes alkalmazások internetkapcsolatra és a böngésző gyorsítótárazására támaszkodnak.
Információkeresés és maga az alkalmazás: A webalkalmazások jobban tudnak tartalomban keresni, de ha egy alkalmazás tartalmában internet-hozzáférés nélkül kíván keresni, akkor hibrid vagy natív alkalmazást kell készítenie.
Működési sebesség: A natív alkalmazások működnek a leggyorsabban. 2012-ben Mark Zuckerberg azt mondta, hogy a közösségi hálózatának legnagyobb hibája az volt, hogy egy webes alkalmazást indított el, nem pedig egy natív megoldást (addig a Facebook hibrid alkalmazást használt, ahol a tartalom nagy része csak akkor volt elérhető, ha csatlakozott az internethez, és HTML alapján c 2012-ben natívra cserélték). Minden a válasz sebességén múlik.
Telepítési folyamat: Míg a natív és hibrid alkalmazásokat telepíteni kell az eszközére, és engedélyt kell adni a szoftver- és hardverplatform egyes összetevőihez való hozzáféréshez, a webalkalmazások lényegében úgy „telepíthetők”, hogy egyszerűen hozzáadnak egy könyvjelzőt a mobilböngészőhöz.
Alkalmazáskezelés és karbantartás: Minden frissítés után egy natív alkalmazást újra fel kell tenni az alkalmazásboltba, míg egy webes alkalmazásban lényegében frissül az oldal és a tartalom, egyfajta mobiloldal formájában „csomagolják”.
Egy adott platformhoz kötés: Mivel a különböző böngészők a HTML5 különböző verzióit támogathatják, függetlenül a telepített hardverplatformtól vagy mobil operációs rendszertől, a webalkalmazások vagy a hibrid alkalmazások jelentik a választást azok számára, akik le szeretnék választani magukat a platformról. Ha az egyes platformok külön fejlesztése nem ijeszti meg, akkor fogadhat egy natív alkalmazásra.
A tartalommal való munka, az alkalmazásbolthoz való hozzáadásának eljárása és a további fizetések: A natív és hibrid alkalmazások speciális jóváhagyási folyamaton mennek keresztül, miután hozzáadták őket az alkalmazásbolthoz. Ezenkívül bizonyos korlátozások vonatkozhatnak rájuk az App Store és a Google Play szabályai és belső szabályzatai miatt (főleg, ha „felnőtt” tartalomról, szerencsejátékról, alkoholról vagy hasonló témákról beszélünk).
Ezenkívül az App Store-hoz hozzáadott alkalmazások részeként fizetős előfizetéseket értékesítő natív alkalmazásoknak meg kell osztaniuk a jogdíjat az Apple-lel. Ennek megfelelően az árképzést és a költségvetést a natív alkalmazások esetében ezen levonások összegének figyelembevételével kell módosítani.
Fejlesztési költség: Egyrészt a webalkalmazások, hibrid megoldások fejlesztése jóval olcsóbb (ráadásul az ilyen alkalmazások elemi verziói is elkészíthetők a tervezőben ingyen vagy jelentős kedvezménnyel). Másrészt egy webalkalmazás vagy hibrid alkalmazás létrehozásához is többé-kevésbé megfelelő fejlesztői képességekre van szükség, és a hardverplatform felhasználási lehetőségeinek számos korlátozása megkérdőjelezi a „megtakarítás” megvalósíthatóságát.
Felhasználói felület:És az egyik legfontosabb érv a webes vagy hibrid megoldások helyett a natív fejlesztés mellett a felhasználói felület egységessége az alkalmazásban és a mobil operációs rendszerben. A vizuális komponensek, a grafika és a webalkalmazás felülete is a lehető legközelebb állhat azokhoz, amelyek alapértelmezés szerint benne vannak magában az operációs rendszerben, de a legteljesebb megfelelőség érdekében mégis érdemes natív megoldást használni.
Natív alkalmazást szeretne rendelni? Nyújtsa be jelentkezését e-mailünkre „Alkalmazásfejlesztés” tárggyal - és 24 órán belül felvesszük Önnel a kapcsolatot, és minden részletet tisztázunk a további megbeszélés érdekében.
A vita arról, hogy mi a jobb és jövedelmezőbb - a natív vagy a platformok közötti fejlesztés - már évek óta nem csitul; Ez a probléma különösen akkor akut, amikor mobilalkalmazás fejlesztésére van szükség. Egyrészt nagyon csábítónak tűnik az az ötlet, hogy egy alkalmazást minden platformra fejlesztenek, másrészt azonban nem biztos, hogy egy ilyen megközelítésnek van a legjobb hatása a felhasználói élményre, megjelenésre, funkcionalitásra és teljesítményre. Összeállítottunk egy rövid áttekintést, amely segít megérteni a két megközelítés közötti alapvető különbséget, és eldönteni, melyiket válassza az alkalmazásához.
A tied, kedves...
Először is beszéljünk a natív fejlődésről. Itt minden egyszerű: minden platformhoz létezik anyanyelve: Android esetén ez a Java, iOS esetén - Objective-C vagy Swift, Windows Phone esetén - C# és így tovább. Minden anyanyelvnek megvan a maga technológiái és keretrendszere.
Előnyök az anyanyelvek használata abban rejlik, hogy a bennük fejlesztett alkalmazás gyorsabban fog működni, képes lesz használni a platform összes képességét és funkcióját, a felület pedig áttekinthető és kényelmes lesz a platform bármely felhasználója számára. Ezenkívül a natív alkalmazások fejlesztése gyakran egyszerűbb, mint a többplatformos alkalmazások.
Fő hátránya Ez a megközelítés az, hogy minden platformhoz külön alkalmazást kell létrehozni, bár a legtöbb funkció ugyanaz lesz. Ráadásul több alkalmazás fejlesztése, amint azt a logika megmondja, hosszabb és drágább lesz. Pontosan így született meg az ötlet egy alkalmazás megírására, amely aztán több platformon is elindulna. Ezt a megközelítést ún
Platformok közötti fejlesztés
A többplatformos alkalmazás fejlesztésének két fő módja van: „kézi” írással C++ kód és wrapperek különböző platformokhoz, vagy használja az egyiket speciálisan kifejlesztett technológiák.
Fejlesztés „kézzel”
Az első megközelítés lényege az C++ kód bárhol elindítható. Az Android erre az NDK-t, a Windows Phone Managed C-t használja, a többi platformnak is megvan a maga módja a kód feldolgozására és futtatására. A másik dolog az, hogy egy ilyen kód korlátozott lesz a képességeiben. Például Androidban nem fog tudni hozzáférni a képernyőhöz, vagy akár önállóan sem indul el. E korlátozások megkerüléséhez először egy fő logikával rendelkező könyvtárat írnak C++ nyelven, majd egy natív nyelvű wrappert, amely futtatja a könyvtárat és biztosítja annak interakcióját az eszközzel. Érdemes azonban megjegyezni, hogy ez a megközelítés csak korlátozott számú alkalmazásra alkalmas - ahol valóban sok logika van a klienseken, amit érdemes külön könyvtárba helyezni.
Technológiák
A második megközelítés lényege az egyik platformon átívelő fejlesztési technológia alkalmazása, amiből ma már nagyon sok van. Íme a legnépszerűbbek:
React Native az utóbbi időben különösen népszerű: még az olyan piaci óriások is, mint az Uber vagy a Sberbank, aktívan kísérleteznek vele. Nem annyira a platformok közötti alkalmazásokról beszélünk, hanem a „Tanulj egyszer - írj bárhol” elvről, vagyis arról, hogy ugyanazt a technológiát lehet használni különböző platformokra vonatkozó alkalmazások létrehozásához, biztosítva a kód újrafelhasználásának magas százalékát.
Egy másik lehetőség többplatformos alkalmazás írásához a használata HTML5 + JavaScript. Egyébként pontosan így írják az Atom szövegszerkesztőt, a Visual Studio Code-ot és a Slack-et (igen, még az asztali verzió is lényegében egy böngésző, amely úgy van megalkotva, mint egy normál alkalmazás).
Érdekes tény: az Amperka cég nemrégiben kiadott egy szokatlan Espruino mikrokontrollert. Fő jellemzője aza mikrokontrolleren futó firmware. Tiszta C-ben van írva, egyszer betöltődik egy külön helyre a mikrokontroller flash memóriájában, és felelős az egyéni JavaScript kód végrehajtásáért. Így most már programozhat mikrokontrollereket JS-ben. JS-n, Karl!!!
Ez a gondolat abszurdnak tűnik, de ha jobban belegondolunk, igazolható is lehet. A dolgok internete koncepciójának fejlődésével és a jövőben a különféle IoT-eszközök számának növekedésével a külvilággal való interakciót biztosítani tudó programozók iránti kereslet felfutására számíthatunk. A JavaScriptbe való belépés gátja pedig sokkal alacsonyabb, mint a C-ben vagy az Assemblerben, ezzel nem lehet vitatkozni!
Ez nem ilyen egyszerű
A cross-platform fejlesztés előnye, hogy egy alkalmazást vagy annak bármely komponensét egyszer megírhatod, például C++ segítségével, és futtathatod különböző platformokon, eszközökön. Logikus, hogy ez kevesebb költséget igényel. Úgy tűnik - írj és örülj! Ennek a megközelítésnek azonban számos hátránya is van.
És mindegyiknek egy oka van:minden platform más.
Tekintsük azokat a fő kellemetlenségeket, amelyekkel szembe kell néznie, amikor a platformok közötti fejlesztés útját választja.
Negatív felhasználói élmény
Mindegyik platformnak megvannak a saját szabványai: szabványos gesztusok és vezérlők, elemek elrendezése, ikonok megjelenése... Például elég egy pillantás a képernyőre, hogy megértsd, iOS vagy Android. Miután kifejlesztett egy alkalmazást, amely minden platformon ugyanúgy fog kinézni, szembesül azzal a ténnyel, hogy a felhasználó nem fogja tudni használni a szokásos vezérlési módszereket, és nem fogja látni a szokásos kialakítást, ezért alkalmazását kevésbé fogja kényelmesen használni, mint a bennszülött.
Ez például gyakran érinti a PlayStationről PC-re portolt játékokat: sok közülük nem támogatja az egeret, és nem teszi lehetővé a játékos számára kényelmes billentyűkombinációk testreszabását, így kevésbé használhatók, mint a kifejezetten PC-re fejlesztett játékok. És bár az olyan alkalmazásokat, mint a Mortal Combat vagy a Final Fantasy vezérelheti a nosztalgia, az új játékok fejlesztőinek kétszer is meg kell gondolniuk, mielőtt megfosztják a felhasználókat az ismerős vezérlőktől.
Egy másik példa a Matlab, amely Mac-en nem felső menüt használ, hanem az ablakon belüli menüt, ami jellemző a Windowsra, és ellentétes az iOS összes irányelvével. Monopolistaként a MatLab ezt megengedheti magának, de ha olyan alkalmazást fejlesztünk, amely felveszi a versenyt másokkal, érdemes elgondolkodni azon, hogy a felhasználók inkább a számukra jól ismert natív felületet preferálják-e.
Még valami - minden platform különbözik a megjelenésben: betűtípusok, gombok mérete és alakja, a naptár megjelenése, jelölőnégyzetek, választógombok... Még ha csak azt szeretné, hogy az alkalmazás natívnak tűnjön, stílust kell fejlesztenie lapokat minden platformhoz, ami növeli az időkeretet és a fejlesztés költségeit.
Korlátozások a funkcionalitás fejlesztése során
A többplatformos fejlesztés a felhasználó kényelmetlensége mellett számos problémát is felvet a fejlesztő számára. A helyzet az, hogy a felhasználó számára teljesen egyformának tűnő műveletek teljesen eltérő módon valósíthatók meg különböző platformokon. Nézzünk példákat.
Az olyan ismerős művelet, mint a drag and drop, alapvetően különbözik Mac és más platformokon. Míg Windowson vagy Linuxon ezt a műveletet maga az alkalmazás hajtja végre, Macen maga az operációs rendszer lép működésbe, ami azt jelenti, hogy a fejlesztőnek külön „fájlmegnyitási” eseményt kell létrehoznia ahhoz, hogy ez a művelet Mac gépen megfelelően működjön. Ez azt jelenti, hogy meg kell birkóznia a fejlesztési munkaerőköltségek növekedésével, vagy azzal, hogy az ezen a platformon a felhasználók számára ismert drag and drop egyszerűen nem fog működni.
Egy másik példa egy adott dokumentum megnyitása. Ez a művelet minden platformon elindítja az alkalmazást, és átadja neki, hogy milyen dokumentumot kell megnyitni Mac-en, egy speciális „fájl megnyitása” eseményt használunk. És ismét a munkaerőköltségek növekedésével kell szembenéznünk, és így a fejlesztés költségeivel is.
A platformközi alkalmazások lelassulnak: mítosz vagy valóság?
A többplatformos fejlesztés előnyeiről és hátrányairól szóló szinte minden vitában látni fogjuk azt az érvet, hogy a többplatformos alkalmazások lényegesen lassabbak, mint natív társaik. Ez igaz és hamis is. Például a C++ nyelven írt és Androidon az NDK használatával futtatott kód még gyorsabban fut, mint a natív alkalmazások. Másrészt, ha például a PhoneGap-et használja, az alkalmazás úgy kezd el működni, mint „A ház, amelyet Jack épített”: a PhoneGap a JS-t hívja, ami Java-nak hívja, ami egy Java gépen fut, amely már fut egy valós gépen. telefon. Természetesen már nem sebességről beszélünk.
Tehát mit érdemes választani?
Egyesek azt gondolhatják, hogy a célunk az, hogy mindenkit meggyőzzünk arról, hogy hagyják abba a többplatformos alkalmazások fejlesztését. Egyáltalán nem: azt javasoljuk, hogy mérlegelje, melyik megközelítés lesz az Ön számára optimális, és ne hajszolja a többplatformos megoldások látszólagos olcsóságát. Nincs egyetlen recept minden alkalomra, minden egyes alkalmazást külön kell értékelni. Tekintsünk két pólust.
A népszerű 2048 kirakós játék például jobban kifejlesztett többplatformos alkalmazásként. A webes technológiákra fejlesztve mindenhol futni fog: ugyanazt a PhoneGap-et használhatja mobilplatformokon, Electron - Windows, Linux és Mac rendszerre, valamint webhelyek, VKontakte és Facebook alkalmazások esetén még erőfeszítést sem kell tennie : az alkalmazás közvetlenül elindul. Mindössze annyit kell tennie, hogy különböző csomagolók segítségével összeállítja a programot, és minden platformhoz létrehoz egy ikont. Kész, az alkalmazás megkülönböztethetetlen a natívtól!
A skála másik végén áll például a Sketch grafikus szerkesztő, amely irigylésre méltó népszerűségre tett szert az UX és UI tervezők körében (mi a Noveonál is használjuk!). Jelenleg csak OS X-re létezik, és olyan gyakran felteszik a kérdést, hogy mikor jelenik meg más platformokra, hogy még a GYIK-be is bekerült.
„Elérhető a Sketch Windows vagy Linux rendszeren?
Az OS X-hez kizárólagos technológiák és keretrendszerek miatt, amelyekre a Sketch épült, sajnálatos módon nem fogjuk fontolóra venni a Sketch támogatását egyik platformon sem.”
(Vannak Windows vagy Linux verziók?
Tekintettel arra, hogy a Sketch-et az OS X-re jellemző technológiákra és keretrendszerekre fejlesztették ki, sajnos nem fontolgatjuk a portolást egyik platformra sem.)
A legtöbb alkalmazás természetesen valahol e szélsőségek között van, így az egyik megközelítés kiválasztása alapos elemzést igényel. Próbáld meg megbecsülni: a felhasználók hány százalékát riasztja el például a gombok szokatlan megjelenése vagy az OS X felső menüjének használatának hiánya? Ezek azok a felhasználók, akik megtérülnek az alkalmazásodban? Sok olyan funkcióval rendelkezik az alkalmazás, amely jelentős módosításokat igényelne egy vagy több platformon?
Természetesen csak az A/B tesztelés tud pontos eredményt adni, de már ennek átgondolása is sokat segít a fejlesztési szemlélet kiválasztásában.
Foglaljuk össze
Mind a natív, mind a többplatformos fejlesztésnek megvannak a maga előnyei és hátrányai. A natív alkalmazások fő előnye a sebesség, valamint az egyes platformok összes funkciójának és szolgáltatásának kihasználása. Legfőbb hátrányuk, hogy ugyanazt a funkciót többször kell kifejleszteni.
Számos keretrendszer és technológia létezik a platformok közötti fejlesztéshez. A legnépszerűbbek közé tartozik az Ionic, a Unity 3D, a Xamarin, a React Native, valamint a HTML + JavaScript használata.
A platformok közötti fejlesztés fő hátrányai a negatív felhasználói élmény és a funkcionalitás fejlesztésének nehézségei. Az alkalmazások minden platformhoz való testreszabására tett kísérletek megnövekedett munkaerőköltségekhez vezetnek, így bizonyos esetekben egy többplatformos alkalmazás drágábbnak bizonyulhat, mint számos natív alkalmazás, bár képességei és képességei tekintetében alacsonyabbak lesznek azoknál. felhasználói interakció. Ezenkívül a többplatformos alkalmazások gyakran lassabban futnak, mint a natív alkalmazások.
Annak megértéséhez, hogy melyik megközelítést válassza, értékelje alkalmazása összetettségét és egyediségét. Kifizetődőbb az egyszerű megoldások fejlesztése többplatformos technológiákkal, de minél összetettebb a funkcionalitás, annál jövedelmezőbb a natív fejlesztés.
Természetesen lehetetlen egy cikkben elemezni a natív és a platformok közötti fejlesztés összes finomságát és árnyalatát. Célunk az volt, hogy megértsük a kérdésben rejlő alapvető fogalmakat és összetettségeket. Oszd meg véleményedet és tapasztalataidat kommentben!
Ha hibát talál, jelöljön ki egy szövegrészt, és kattintson rá Ctrl+Enter.
A mobilalkalmazások piaca több mint tíz éves, de még mindig gyorsan fejlődik. A cégek iránti kereslet folyamatosan növekszik, és még mindig jelentősen meghaladja a kínálatot, ami a fejlesztési költségek folyamatos növekedéséhez vezet. Az egyik megoldás ennek a folyamatnak a költségeinek csökkentésére a többplatformos fejlesztés, amikor ugyanazt a kódot használják minden platformon.
Legutóbb a platformok közötti mobilfejlesztéssel foglalkoztunk, és azóta sok minden megváltozott. Itt az ideje, hogy ismét a módszerekről, eszközökről beszéljünk.
Először nézzük újra a terminológiát.
Rokonok
Ha a fejlesztők egy alkalmazás írása során az adott platformhoz elfogadott programozási nyelvet használják, legyen az Objective-C és Swift iOS-hez, vagy egy ilyen alkalmazást natívnak neveznek (az angol anyanyelvből - natív, természetes).
A natív alkalmazások előnyei:
- sebesség és interfész válasz. Az alkalmazás azonnal reagál a kattintásokra, gyakorlatilag nincs késés az animációban, a görgetésben, az adatok fogadásában és kiadásában;
- világos és egyszerű hozzáférés a készülék funkcióihoz és érzékelőihez. A fejlesztő számára nem jelent problémát a földrajzi helymeghatározás, a push értesítések, a fotók és videók készítése a kamerán, hangon, gyorsulásmérőn és egyéb szenzorokon keresztül;
- az okostelefon funkcióival való elmélyült munka képessége. Az előző bekezdéshez hasonlóan itt is olyan dolgok valósulnak meg, mint az animációk, összetett interfészek létrehozása és a neurális hálózatok közvetlenül az eszközökön történő működtetése, talán nem egyszerűen, de kiszámíthatóan;
- . A natív alkalmazások általában „platform” felületelemekkel működnek: a menük, a navigáció, az űrlapok és minden egyéb tervezési elem az operációs rendszerből származik, így a felhasználó számára ismerős és érthető.
Csak egy hátránya van - a magas fejlesztési és támogatási költségek. Minden platformhoz saját kódot kell írnia. A mobilalkalmazások piacának növekedésével a fejlesztők nemcsak drágává, de nagyon drágává váltak.
És nem rokonok
A többplatformos alkalmazások egyszerre több platformra is készülnek, a natív nyelvtől eltérő nyelven. Hogyan működhet egy ilyen kód különböző eszközökön? Itt is két megközelítés létezik.
Az első az, hogy az alkalmazás közzétételre való előkészítésének szakaszában transzpiler segítségével natívvá alakítják egy adott platformon. Valójában egy többplatformos programozási nyelvet „lefordítanak” egy másikra.
A második az, hogy a kapott kódhoz egy bizonyos wrapper kerül hozzáadásra, amely az eszközön már működik, és menet közben lefordítja a hívásokat a nem natív kódról a natív rendszerfunkciókra.
Feltételezhető, hogy ennek a kódnak a nagy része átvihető platformok között - nyilvánvaló, hogy például a vásárlás logikája, az áruk kosárba mentése, a taxi útvonalának kiszámítása, az üzenet írása a messengerben nem változik attól függően, hogy a kliens Android vagy iOS rendszerű. Már csak a UI-t és a UX-t kell finomítani a platformokhoz, de most bizonyos keretek között még ez is kombinálható – például Androidon és iOS-en is aktívan használják a hamburger menüt. Így már az is, hogy a kezelőfelületen olyan korrekciókat végezzünk, hogy az alkalmazás megfeleljen a kívánt platform szellemének és betűjének, a fejlesztéshez szükséges gyorsaság és minőség kérdése.
Előnyök:
- költség és a fejlesztés sebessége. Mivel sokkal kevesebb kódot kell írni, a munka költsége csökken;
- a vállalat belső erőforrásainak felhasználásának képessége. Amint azt később látni fogjuk, a többplatformos mobilalkalmazás-fejlesztést gyakran a meglévő programozói is elvégezhetik.
Hibák:
- nem natív felület, vagy legalábbis az egyes platformok interfészeivel külön-külön kell dolgozni. Minden rendszernek megvannak a maga követelményei az elemek tervezésére vonatkozóan, és néha kölcsönösen kizárják egymást. Ezt a fejlesztés során figyelembe kell venni;
- problémák az összetett funkciók megvalósításában, vagy az egyszerű eljárásoknál is előforduló problémák magukban a fejlesztői keretrendszerek hibái miatt. A többplatformos környezet csak a rendszerhívásokra és interfészekre irányuló kéréseket fordítja le olyan formátumba, amelyet a rendszer megért, és ezért ebben a szakaszban magában a keretrendszerben előfordulhatnak megértési nehézségek és hibák;
- a munka sebessége. Mivel a többplatformos környezet a kód feletti „szuperstruktúra” (nem mindig, de bizonyos helyzetekben), megvannak a maga késései és szünetei a felhasználói műveletek feldolgozásában és az eredmények megjelenítésében. Ez néhány éve különösen a maihoz képest kisebb teljesítményű okostelefonokon volt szembetűnő, de most, a mobilkészülékek teljesítményének növekedésével ez már elhanyagolható.
Mint látható, ez a két módszer gyakorlatilag egymás tükörképe - a natív fejlesztés előnyei, a platformok közötti fejlesztés hátrányai, és fordítva.
Népszerű többplatformos fejlesztői platformok és eszközök
Ahogy fentebb írtuk, két megközelítés létezik: a kód natívvá alakítása az összeállítási szakaszban, vagy egy bizonyos burkoló hozzáadása, amely lefordítja a rendszerre irányuló és onnan érkező hívásokat.
A Cordova és a PWA két olyan eszköz, amelyek pontosan a wrapper ideológiájában működnek.
Cordova és HTML5
A keresztplatformos programozás egyik legnépszerűbb területe, amelyet gyakran PhoneGap-nek hívnak. Valójában létrejön egy mobil weboldal, amely egy kis platformkódba van „csomagolva”, amely a rendszerből az alkalmazásba és vissza továbbítja a hívásokat.
Az összes hátrány és előny itt világosabban kifejezésre jut, mint bárhol máshol. Használhatja a webfejlesztőket (alaptechnológiaként HTML, CSS és JavaScript), és viszonylag kevés pénzért egy hónap vagy akár néhány hét alatt elkészítheti az alkalmazás első verzióját. Igen, lassú lesz a működése, és nem biztos, hogy teljesen pontos földrajzi helymeghatározással rendelkezik, de minden eszközön működni fog, és lehetővé teszi legalább a vásárlói igények mobileszközökön történő tesztelését.
Rengeteg keretrendszert hoztak létre ehhez a megközelítéshez, de ezek lényegében ugyanazt teszik. A különbség köztük az, hogy a Cordova (PhoneGap) nem állít be korlátozásokat és sablonokat a HTML5 projekt logikájára és felhasználói felületére vonatkozóan, a keretrendszerek pedig saját, mobil platformokat imitáló, kész UI elemekkel és saját fejlesztési logikával működnek. Példa erre a megközelítésre: Ionic Framework – wrapper; Framework7, Mobile Angular UI, Sencha Touch, Kendo UI - interfész keretrendszerek.
PWA
A Google divatos technológiája ugyanazok a webalkalmazások, de bizonyos technológiák (elsősorban az ún. Service Worker – háttérben futó szkriptek, és a Web App Manifest – a webalkalmazás mobil számára érthető formában történő leírása) használatával. rendszer ) natívként működhetnek a PhoneGap burkoló nélkül. Telepíthetők a kezdőképernyőre, megkerülve az alkalmazásboltot, offline módban dolgozhatnak, push értesítésekkel és natív funkciókkal dolgozhatnak.
A probléma az, hogy még most sem minden platform támogatja ezeket a „bizonyos technológiákat”. Ez elsősorban az Apple-t érinti, amely láthatóan nagyon nem szereti, ha az App Store-t megkerülve terjesztheti az alkalmazásokat.
Figyelembe véve a HTML5-megoldások összes hiányosságát, sok cég készített olyan eszközöket, amelyek lehetővé teszik a kód írását egyetlen, nem anyanyelvi nyelven, majd ezt lefordítják natív nyelvre. Ez két legyet megöl egy csapásra: csak egy kódbázis van, és az alkalmazások a lehető legközelebb állnak a natívhoz.
Xamarin
Microsoft platform. A vállalati fejlesztés szabványos programozási nyelve a C#, a többplatformos fejlesztői környezet pedig a Visual Studio. A kimenet natív iOS, Android és Windows alkalmazások. Igaz, viszonylag nagy méretű.
React Native
Platform from - Az alkalmazások JavaScript-ben és CSS-szerű stílusokat használnak. A felületről kiderül, hogy natív, és a kódot a platformon értelmezik, ami megadja a szükséges rugalmasságot.
Viszonylag fiatal platformként a React Native még mindig nyilvánvalóan (bár nem vészesen) szenved a fejlesztői eszközök és a dokumentáció hiányától.
Csapkod
Természetesen egy olyan óriás, mint a Google, nem hagyhatta figyelmen kívül az Android és iOS alkalmazások platformok közötti fejlesztésének témáját. A Flutter, bár jelenleg még csak béta, más megközelítést alkalmaz, mint a React Native és a Xamarin. Nem alakítja át a forráskódot natív kóddá, amit a platform hajt végre, hanem egy ablakot rajzol az okostelefon képernyőjére, és maga jeleníti meg az összes elemet. A használt nyelv a „védett” Dart, amelyet a Google a JavaScript továbbfejlesztett változataként hozott létre.
Ennek vannak előnyei (például külsőleg azonos interfészek) és hátrányai is (például az interfész újrarajzolásához bizonyos memória és CPU idő szükséges).
A platform gyorsan fejlődik, és a Google rengeteg erőfeszítést és pénzt fektet bele. De a Flutterhez képest még a React Native is nagyon megalapozott és lenyűgöző ökoszisztémának tűnik.
Mit válasszunk
Valószínűleg már forog a fejed, de még mindig fogalmad sincs, mit válassz. Mutassunk egy egyszerű kérdéslistát segítségül:
- Működnie kellene valahogy bármilyen eszközön? Válasszon HTML mint alap;
- Van elég pénzed, nem sietsz, és a legjobb minőségű alkalmazást szeretnéd? Közvetlen út van hozzá őshonos fejlődés;
- Van „beépített” webfejlesztője, vagy egyszerűen csak szeretne gyorsan és egyszerűen kipróbálni egy mobilalkalmazást működés közben? Itt tudunk ajánlani Cordova/HTML vagy PWA;
- Van saját CRM rendszere és egy C# fejlesztője, aki támogatja? Vedd el Xamarin;
- „ki akarod próbálni”, de mindent széppé és divatossá kell tenned? Nézz szét React Native vagy Flutter.
A másik oldalról is lehet menni. Tekintse meg, hogy milyen funkciókra lesz szüksége az alkalmazásban, és lépjen tovább:
- egy egyszerű névjegykártya alkalmazás? Vesz React Native vagy HTML5és minimális áron kap két platformot;
- Van egy nagy forgalmú webhelye, és tesztelnie kell jelenlétét a mobil térben? HTML5;
- komplex alkalmazások a kívánt eszközfunkciókhoz való hozzáféréssel? Natív fejlesztés, Xamarin, React Native.
A platformok közötti fejlesztés nem csodaszer
A kiválasztásnál a hozzárendelt feladatokból és a meglévő erőforrásokból kell kiindulni. A platformok közötti fejlesztés jó és érthető irány, de megvannak a maga előnyei és hátrányai, amelyeket a projekt elindítása előtt szem előtt kell tartani. Egy kész, többplatformos alkalmazás nyilvánvalóan jobb, mint egy elkészítetlen natív alkalmazás. Gyorsan és olcsón fejlesztheti, feltöltheti az áruházba, és egyszerűen ellenőrizheti a felhasználók keresletét - keresi-e valaki az alkalmazását, telepíti-e, milyen funkciókat használ. Egy ilyen kísérlet eredményei alapján el lehet dönteni a mobil irány sorsát az Ön cégében és az abba történő befektetéseket.
Még mindig vannak kétségei és kérdései a többplatformos alkalmazásokkal kapcsolatban? Olvassa el, hogyan hoztunk létre egy alkalmazást a város egyik sportintézményének gyors előfizetéséhez, és próbálja ki az alkalmazást mindenféle szolgáltatás fizetésére - a lakhatástól és a kommunális szolgáltatásoktól az online áruházak rendeléséig. Még jobb, ha iratkozzon fel egy ingyenes konzultációra a hozzávetőleges költségvetés megjelölésével és az ötlet rövid leírásával, vagy vegye fel a kapcsolatot Katya menedzserünkkel telefonon