Sokan azt gondolják, hogy egy mobil alkalmazás sikere elsősorban a fejlesztés minőségén múlik. A valóság viszont az, hogy a legtöbb projekt már azelőtt elbukik, hogy az első sor kód elkészülne. Az elmúlt évek tapasztalata alapján három visszatérő hibát látunk, amelyek jelentősen növelik a sikertelenség esélyét.
Az Apple hivatalosan is bejelentette, hogy az európai fejlesztők számára elérhetővé teszik az alternatív alkalmazás áruházak és böngészőmotorok használatát, továbbá kedvezőbb appon belüli fizetési megoldásokat.
Az okosórák rengeteg hasznos adattal tudnak szolgálni egy felhasználó egészségi állapotáról, élő és korábbi adatok szintjén is. De hogy tudjuk ezt felhasználni egy alkalmazásban?
A mesterséges intelligencia terjedésével egyre érdekesebbé válik a nagy tömegek számára. Mindenki szeretné tudni, hogy hogyan és miért működik, miért képes hibázni és egyáltalán mire számíthatunk egy AI-tól a jövőben.
Az appok és weblapok, továbbá úgy általánosságban a szoftverek üzemeltetése és karbantartása egy kulcskérdés a fejlesztések elvégzése után. Miután elkészült az alkalmazásod biztosan nem szeretnéd, ha valamilyen rendszerhiba miatt az nem állna a felhasználóid rendelkezésre, ezért érdemes külön figyelmet fordítani az üzemeltetés kérdésére is. Laikusként gyakran felmerülnek olyan kérdések, hogy milyen szolgáltatót válasszunk, illetve hagyjuk-e az eredeti fejlesztőnél az üzemeltetési feladatokat vagy épp mi történik akkor, ha a fejlesztő nem tudja vállalni vállalni ezeket.
Ha valaki foglalkozik legalább kezdő szinten a React bármilyen formájával (tehát ide tartozik a React Native is), akkor biztosra vehető, hogy találkozott state kezeléssel. A vanilla JS-hez képest egy nagyon kényelmes megoldást nyújtanak a komponensek futásidejű változtatására, frissítésére.
Laikusként gyakran nehéz dolgunk van egy saját szoftver készíttetésével, mivel ahhoz, hogy el tudjuk dönteni, hogy jó terméket kapunk-e a pénzünkért vagy sem, valamennyi rálátás kell a fejlesztésre. Persze a legfontosabb, hogy a felhasználási területen magabiztosan mozogjunk, de nem ússzuk meg ennyivel.
Évről évre feltűnnek olyan triviálisnak tűnő app megoldások, melyek hatalmas sikert aratnak. Mire számíthatunk 2023-ban, mik lesznek a főbb csapásirányok amikben nagy változásokat fogunk látni?
Tapasztalataink alapján gyakran felmerül az igény, főleg webshop tulajdonosok esetén, hogy szeretnének egy mobil applikációt látogatóiknak. Ilyenkor még nem tudjuk, hogy mekkora igény lesz az alkalmazásra a jelenlegi látogatók részéről, tehát van némi kockázat ebben a beruházásban.
Sokan szomjazunk az innovációra és esetenként van is megvalósíthatónak tűnő ötletünk, mellyel tehetünk a közösségért vagy hosszútávon bevételre tehetünk szert. De mit tegyünk, mi a következő lépés? Fontos, hogy pontosan tudjuk mit szeretnénk, próbáljunk meg egy saját specifikációt készíteni, melyből a szakemberek is megérthetik az elképzelést, majd az alapján tudnak segíteni nekünk.
Nem szükséges cégvezetőnek lennünk ahhoz, hogy tapasztalhassuk mennyi problémát okozhat a rendszer hiánya és a megszokásból használt technológiák cégünk üzleti folyamataiban. Számos cég még mindig összetett Excel táblákat, elavult ütemezési módszereket használ belső folyamatainak vezetéséhez és különböző kommunikáció csatornákon áramoltatják az információt.
Egy alkalmazás meglepően magas költségeket is jelenthet, főleg ha nem egy nagy multi, hanem valamilyen kisebb vállalkozás vagy startup költségvetéséből kell megvalósítani. Szerencsére az új megközelítések pont ennek a megoldását teremtették meg. De mik is ezek?
Jó néhány évtized alatt megszokhattuk, hogy ha telepíthető szoftvereket szeretnénk, amik offline is elérhetőek, akkor azokat Javaban, C-ben, C#-ban vagy valamilyen hasonló programozási nyelven szokás írni, hiszen a tervezésüknél eleve ez volt a felhasználási cél. Ma már egyre inkább törnek felfelé a PWA-k, amelyek egyszerűbben és gyorsabban megírható alternatívát jelentenek.
Használhatunk külső könyvtárakat, illetve beépített térkép komponenst is kapunk ha Expo alapokra építkezünk az alkalmazásunkkal.
A modern webdesign már nem a monitoroknál indul. A mobile-first megközelítés a telefonokra tervez először, csak ezután jön a már megszokott asztali kinézet.
Korábban az asztali szoftverek nagyrészt Javaban vagy valamilyen C-szerű nyelven íródtak. Mára ez fordulni látszik, a JS alapú megoldások egyre erősödnek.
Az okostelefon elterjedése óta számos megoldás született arra, hogy a programozó minél könnyebben, gyorsabban tudjon fejleszteni. A piac a natív appoktól egyre inkább a cross-platform megoldások felé mozdult.
Mára a legtöbb weboldal dobta a régi Flash Playeres funkciókat, felváltotta őket a HTML5 és a Javascript használata. Ez utóbbi viszonylag gyakran kap frissítéseket, de aki nem követi, annak kevés esélye van észlelni, hiszen a böngészők nem igazán szoktak szólni róla, ha bejön egy-egy új szabvány amit implementálnak. 1997 óta nagy utat tett meg a JS, mára a legtöbb keretrendszer alapvető elvárásnak tekinti az ES6-ot. Az ECMAScript 2015 (azaz az ES6) számos új funkciót hozott a 4-6 évvel korábbi (attól függ, hogy az 5.1-et el akarjuk-e fogadni vagy sem) megoldáshoz képest.
