Appfejlesztés Xamarinnal II. - Strandlistázó app

Appfejlesztés Xamarinnal II. - Strandlistázó app
2016-06-07T16:32:30+02:00
2016-07-11T09:05:14+02:00
2022-10-20T08:05:37+02:00
  • Mutasd a teljes hozzászólást!
  • Ez is attól függ hogy mit csinálsz. Egy üzleti app tipikusan nem a gugli drive-val beszélget, hanem a saját backendjével.
    Mutasd a teljes hozzászólást!
  • Windows, Android, IOS. Én így bontom a programokat.

    Windows-on OneDrive-ot fogok javasolni. Droid-on Google-t, IOS-en meg ICloud. Nem tudom így érthető-e, hogy mire gondolok.

    (Ehhez viszont minden felülethez egyedileg kell az adott szolgáltatást belőni. Illetve ez egy átlagos példa, nagyon sok hasonló dolog van ami eltér az eszközökben. )

    UWP: 
    Telefonon kifér mondjuk 1 db lista, de asztali gépen kifér egymás mellé 3db lista is. Szerintem ha 3 listát jelenítek meg pc-n, akkor már más a felületem, de ha csak 1 listát, akkor az nagyon széles lista lesz ahhoz képest amit telefonon látok.
    Mutasd a teljes hozzászólást!
  • Ezt már kitárgyaltuk, hogy több, mint 20 éve senki nem használ közvetlen memória kezelő utasításokat C/C++ ban.

    urho3d/Urho3D

    C#-ban időnként viszont rá vagy szorulva: lásd Dispose pattern, és ez még bonyolultabb is a GC miatt, mintha C/C++ ban direktben használnád a megfelelő utasításokat.

    Időnként igen, de ez elég ritka, és általában elég limitált területen. A dispose akkor kell, ha szűkös erőforrást kell kezelned (Pl. adatbázis connection). Ott pedig az az elv hogy használod amíg feltétlenül kell, aztán gyorsan elengeded. És külön kódrészben van, Pl. DAL vagy azon belül is az EF.

    Ez olyankor szép, amikor egy limitált cél eszközre kell mondjuk 2D/3D térkép megjelenítést fabrikálni .NET alatt nagy felbontású textúrákkal és 200 ezer feletti polyszámmal.

    Ilyenkor használ az ember C++-t a 3D térkép megjelenítésére.
    Mutasd a teljes hozzászólást!
  • kevesebb a hibalehetőség (Pl. pointer arithmetika és általában közvetlen memóriakezelés).

    Ezt már kitárgyaltuk, hogy több, mint 20 éve senki nem használ közvetlen memória kezelő utasításokat C/C++ ban.

    C#-ban időnként viszont rá vagy szorulva: lásd Dispose pattern, és ez még bonyolultabb is a GC miatt, mintha C/C++ ban direktben használnád a megfelelő utasításokat. Ez olyankor szép, amikor egy limitált cél eszközre kell mondjuk 2D/3D térkép megjelenítést fabrikálni .NET alatt nagy felbontású textúrákkal és 200 ezer feletti polyszámmal.
    Mutasd a teljes hozzászólást!
  • Nem lehet más a felület, mert teszem azt mondjuk egy fontos segélykérő alkalmazás felületéről van szó és ha másik telefon van az ember kezében nem totojázhat azzal, hogy elkezdi kiismerni a felületet. Egységesnek kell lennie a programnak minden platformon, hiszen hogy nézne ki az a program, ami például minden egyes Android gyártó telefonján más, mert az adott gyártó más felületet használ + még a felhasználó is mindenféle skineket tesz fel, így egyik telefonon minden barna lenne a másikon minden piros és ami eddig fent volt az most lent lesz stb. Ez még egy asztali alkalmazásnál is teljesen elfogadhatatlan lenne.

    Játékoknál is hasonló a helyzet, hogy nézne ki, ha hirtelen egy Xbox navigálási és menürendszer kezdene megjelenni asztali gépen, csak azért mert xbox controllert érzékel a program? Elég idétlen megoldás lenne, általában azért ügyelnek arra hogy minden platformon egységes szemlélettel és kinézettel lehessen használni probléma nélkül és ne össze-vissza.

    Egyrészt a programot elképzelhető, hogy ugyanaz az ember is használja különböző eszközökön (lásd UWP), másrészt, ha valami probléma van egyszerűen követhetetlen lenne supportálni kismillió variációra ugyanazt.
    Mutasd a teljes hozzászólást!
  • Semmivel nincs több hibalehetőség. Egyrészt, mert a sima C++ fordító ugyanúgy hibázhat mint egy C# fordító, másrészt Pl. a gcc is úgy fordít, hogy először csinál egy köztes kódot, majd azt fordítja tovább gépi kódra vagy assemblyre. Ezért is tud a gcc compiler családként viselkedni (gcc, gcj, stb), másrészt ezért tud könnyedén fordítani ennyi platformra.

    Amúgy pedig a fordítók elég jól unit tesztelhetők, és mostanság általában elég pontos kódot fordítanak, én utoljára úgy 20 éve találtam hibát fordítóban - és az pont a Borland C fordítója volt. A hibák a legtöbbször a lefordítandó forráskódban vannak - márpedig Pl. C++-ban sokkal-sokkal könnyebb hibázni - azaz egy ugyanolyan funkcionalitást elvégző kód esetén (persze a helló világon túl) egy ugyanolyan képességű fejlesztő C++-ban valószínűleg több hibát fog véteni mint C#-ban.
    Ennek pedig egyszerű oka van: egyrészt ez utóbbiban kevesebb a hibalehetőség (Pl. pointer arithmetika és általában közvetlen memóriakezelés). És ha valaki mégis unsafe kódot csinál, az elég jól nyomonkövethető (és elég ritkán van erre szükség).
    Mutasd a teljes hozzászólást!
  • Nem tudom, de tőlem mindíg az a kérés, hogy igazodjon a felület az adott operációs rendszerhez.

    De ha belegondolsz hogy lesz egyszerűbb használni egy windows user-nek egy programot, vagy épp egy ios-esnek egy programot? Úgy, ha nem lesz neki teljesen idegen. 

    Illetve érdemes elolvasni mind a három esetben a hivatalos ajánlásokat, esetleg átnézni az eszközök működését. Oké, hogy adott esetben van windows teló, droid teló, meg ios... De nézd meg hogyan működnek ezek. Tegyél egymás mellé három készüléket és navigálj a menüpontok között. Szerintem totál más a felület, de nem csak kinézetre, logikára is.
    Mutasd a teljes hozzászólást!
  • Nincs, csak több a hibalehetőség egy olyan fejlesztő környezettel, ami igazából átfordítja a kódod natív kódra. Ha épp a natív rész jó, csak rosszul fordítja át a xamarin az gubanc.
    Mutasd a teljes hozzászólást!
  • Más API-kat használ a játék engine, viszont a koncepció ugyanaz: egy felület, egy kód => sok platform. Egyébként felhőnek ott az Azure, épp most heggesztek egy ilyen appot. Persze a fejlesztők össze-vissza csináltak mindent, van itt swift-től kezdve, javaig minden, de legalább a server oldal egységes, úgyis az a lényeg egy üzleti appnál. Ha gondolkoznak egy picit előre, akkor ugyanazt a design nem 3 féle UI-al és nyelven foltozzák össze, de így legalább háromszoros óradíjat el lehet kérni, ha a klienseken is kell változtatni. Mindennek megvan a maga előnye.
    Mutasd a teljes hozzászólást!
  • Más egy komplex offline üzleti app ahol az UI huszadrangú kérdés, és más egy alternatív weboldal, ahol zéró közeli a kliens oldali logika. A xamarint nyilván nem az utóbbihoz tervezték. Persze, ez csak a két véglet, közte még sok minden van, Pl. játékok, naptár appok, webrádiók, stb. Egy-egy feladatra több megoldás is jó lehet, van amire ez jobb, van amihez az.
    Mutasd a teljes hozzászólást!
  • Ezzel nem ertek egyet.
    Reszben csak. 

    "Sajat backenddel" persze, pl Amazon vagy valami lokalis kokany vas...teljesen mindegy. De van az a megoldas amikor iCloud kell (ingyenes). Ugye esz kimondottan Apple specifikus cucc. Massal nem megy. Megeroszakolassal sem. Okes most free lett a Firebase...de eddig mashogy mukodott.

    Viszont amit mondasz BL logic mobil appnal. Hat nem tudom. A Json parse-olast nem tekintem nagy kihivasnak ,de a perzisztens adattarolast sem. Nem tudom milyen mobil uzleti logika lehet az ami bonyolult lehet ugy igazan mobil oldalon. A tapasztalatom az, hogy a szarakodas a designnal es az animaciokkal sokkal sokkal sokkal sokkal tobb idot vesz el mint a kodolas.

    Ugy 3-4x tobb idot. Es ha a cross platform alatt ez meg bonyolultabb akkor ez az a katagoria amit bottal se szeretnek piszkalni. A UI alatt ertheted a specialis animalt terkepet, ertheted a 100+ UI elemet amit pozicionalni es/vagy animalni kell, (kaparos sorsjegy), webshop, ilyesmi. Ha a juser eri a mukodeset de ronda...nem fogja hasznalni.

    Otthon igen a management ahogy mondod tenyleg ugy van.

    De ha valami szepet es hasznalhatot kell csinalni akkor koltenek minden apro reszletre is. Tipikusan nem otthon de otthon is elofordul...hat. :)
    Mutasd a teljes hozzászólást!
  • Egy komolyabb üzleti app elsősorban a saját backenddel kommunikál. És a mögötte lévő BL az ami a nagy falat, az hogy most az UI picit másképp fog kinézni droidon mint mondjuk windows10-en kevésbé lényeges.
    Már csak azért is, mert a managementet aki végül is a révészt fizeti alapvetően három dolog érdekli:
    1. A használat közben keletkezett adatok (ezért fejlesztetik ki az appot).
    2. A fejlesztés költsége (minden manager úgy költ IT-re mint ha a fogát húznák).
    3. Az app kezelési idejének elsajátítási ideje, és gyors használat (= az end-user könnyen cserélhető legyen, és ne sok munkaideje menjen el a használatra és az elsajátításra).

    Egy felhasználóknak szánt dolog, Pl. naptár app vagy hasonló persze más tészta, de azok ritkán komplexek annyira hogy probléma legyen az UI teljesen egyedi fejlesztése. Mert amúgy xamarinnal Pl. a natív droid-os API-t is eléred, kb. csak annyi hogy nem javában hanem C#-ban írod a kódot (ami azért nagy könnyebbség).
    Mutasd a teljes hozzászólást!
  • Szia! Jatek kicsit mas. Van egy valamilyen kijelzo mereted, szamolsz ra egy relativ poziciot minden elemre, e jo esellyel van valami OpenGL-es amit hivogatsz, meg van alatta valamilyen hang kezeles. Ennyi ami kb viszonylag biztos, es minden platformon mukodik.

    Minden mas elterhet. Egy csinosabb uzleti appot, ami kezel GPS-t, vagy hasznal platform specifikus animaciokat, vagy akarmilyen platform specifikus cuccot, mar nem feltetlen erdemes cross platformmal nekiallni mert minden esetben tobbletmunkat jelent a fejlesztes es a debugolas.

    Nagyobb tobbletmunkat mintha 2-3 platformon nekiallnal nativan megoldani. 2, 3D-s jatekok eseteben nem, mert nagzonjo 3D es 2D engine-ek vannak, vagy komplett "Studio-k" ahol esetleg meg az animaciokat is kattintgatva ossze tudod rakni. Meg tudod tervezni a teljes jatek kornyezetet fizikaval egyutt. A problema ott is akkor jon elo, ha akarsz hasznalni platforspecifikus Cloudot. Akkor mar a varazsltos kozos C sharp vagy Java kod nem mukodik.
    Mutasd a teljes hozzászólást!
  • Olyan, hogy nem bugos környezet nincs.
    Mutasd a teljes hozzászólást!
  • Ha nem is vállalatirányítási, de elég komplex üzleti programokat bizony írnak tabletre - mi is egyébként. Tipikusan akkor kell ilyen, ha a csóka aki használni fogja elég bonyolult dolgot csinál, és nincs mindig netközelben (= mobil net sincs).
    Mutasd a teljes hozzászólást!
  • Üzleti programban sem épp win95 stílusú ablakok fogadnak már elég régóta. Pont az a lényeg, hogy saját stílus és a platformfüggetlenség, ami jellemzi, vagy legalábbis az igényesebbeket jellemezni kéne a programokat és ez a játékokra is igaz: Noesis  Scaleform
    Mutasd a teljes hozzászólást!
  • A játék teljesen más kategória, ott nem szeretnéd ha windows-os ablakok fogadnának téged. :D
    Mutasd a teljes hozzászólást!
  • Nagyon jó dolog a xamarin, csak az a baj, hogy bugos. Ez pedig akkor bosszantó, mikor a xamarin bugos, de az eredeti környezet nem az. Vagy amikor előjön, hogy szeretnéd ha a felhasználó tudna exportálni/importálni beállításokat. Ezt oldja meg nekem valaki közösben. (droid és windows még nem is nehéz annyira, de IOS-en teljesen más megoldást kell rá találni.)

    Ezzel arra akarok célozni, hogy a három eszköz teljesen más szemlélettel működik, mások a korlátok és nem minden esetben jó megoldás "megerőszakolni" a rendszert...
    Mutasd a teljes hozzászólást!
  •  a legprimitívebb programokat leszámítva

    Nem is kell itt vállalat irányítási rendszert megírni, csak a mobilra való legprimitívebb kis programokat, ahol az egyes mobil platformokon a UI-nak kb semmi jelentősége nem kell(ene), hogy legyen olyan szempontból, hogy annak másképp kellene kinézni 1-1 mobil platformon. Komolyabb alkalmazások esetleg  3D mobil játékok, -de ott meg a UI is saját ill. a motor platformfüggetlen része, és persze szintén tök egyforma, amivel nem hinném, hogy pl a Ubisotf plusz munkát csinálna magának az elmúlt több évtizedes tapasztalatai alapján- tehát 100%-ban szintén cross-platform és hatékony a fejlesztés és még natív is.
    Mutasd a teljes hozzászólást!
  • Az elmúlt évtizedek többplatformos tapasztalatai azt mutatják, hogy a "minden környezetben pontosan ugyanaz az UI" megoldás a legprimitívebb programokat leszámítva mindig több problémát okoz, mint amennyit megold. Még a fejlesztőnek is, aki végül nem munkát spórol, hanem plusz munkát csinál magának vele.

    Egyszerűen az UI-nak mindig legalább részben a célkörnyezethez kell igazodnia. Egyrészt praktikus, másrészt konvencionális okokból is. Előbbi alatt az értendő, hogy az UI-nak illeszkednie kell az eszköz sajátosságaihoz (méretéhez, preferált beviteli módjaihoz, számítási és grafikus teljesítményéhez, stb.). Utóbbi alatt pedig az, hogy a felhasználó elvárja, hogy egy adott eszközön működő programok szerves egységet képezzenek, szorosan működjenek együtt egymással, és főleg ugyanúgy nézzenek ki és lehessenek kezelhetők.

    Ezek az elvárások pedig csak akkor teljesíthetők, ha az UI-t célplatformonként külön-külön építi fel - vagy legalábbis megtartja annak egyedire szabási lehetőségét - a fejlesztő, és nem egy absztrakt vezérlőkészletből, hanem az egyes platformok natív vezérlőiből.

    Az üzleti logika, illetve a backend kód ettől még persze hatékonyan megosztható több platform között is.
    Mutasd a teljes hozzászólást!
  • Ez így nem több, mintha az SDK-val állnék neki a fejlesztgettyűnek C# nyelven.  
    A QT használatával a UI tök egyforma és az üzleti logika oldalon sem kell semmilyen platform specifikus kódot sem írni, ezért sokkal hatékonyabb a fejlesztés és az valóban natív.
    Mutasd a teljes hozzászólást!
  • Már most sajnálom, hogy csak 4 részes lesz a cikksorozat! :(
    Mutasd a teljes hozzászólást!
  • Így írhatsz gyorsan és egyszerűen mobilappot a három legnépszerűbb platformra.

    Azért érdekes lehet (számomra annyira nem meglepő), hogy ha már a gyorsaságról, és egyszerűségről van szó, nem a xamarin forms-ot használja.
    Ugye annak az lenne a lényege, hogy a ui-t leíró kódot (ami lehet xaml vagy c# is) egyszer kell megírni.
    Mutasd a teljes hozzászólást!
  • Ugyes! :) De hogy lehet custom style-t csinalni neki? Valami ritha csicsasat, amit a designerek szoktak megalmodni, mimeg kitepjuk a hajunkat. Egyaltalan van ra lehetoseg?
    Mutasd a teljes hozzászólást!
  • király, várós a folytatás
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd