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
  • Eddigi hibák:

    MainAdapter.cs:
    - hiányzik a GetItem metódus
    - hiányzik a List deklarációnál a <Beach> osztály típus
    - hiányzik a <TextView> osztály a FindViewById-nél

    És még mindig van két hiba:
    Error CS0115 'MainAdapter.this[int]': no suitable method found to override BeachApp.Droid
    Error CS1503 Argument 1: cannot convert from 'BeachApp.Droid.FileLoader'
    Mutasd a teljes hozzászólást!
  • Eddig ezeket javítottam, ez most házi feladat vagy tényleg nem tesztelte senki?

    public override int Count { get { return items.Length; } } public override View GetView(int position, View convertView, ViewGroup parent) { var item = items[position]; View view = convertView; if (view == null) view = context.LayoutInflater.Inflate(Resource.Layout.BeachListRow, null); view.FindViewById<TextView>(Resource.Id.Name).Text = item.Name; view.FindViewById<TextView>(Resource.Id.City).Text = item.City; return view; }
    Mutasd a teljes hozzászólást!
  • Ez így nem működik. using-ok eleve meg sincsenek megemlítve, és tele van hibával pl:

    Error CS0534 'MainAdapter' does not implement inherited abstract member 'BaseAdapter.GetItem(int)' 
    Error CS0305 Using the generic type 'List<T>' requires 1 type arguments BeachApp.Droid 
    Error CS0115 'MainAdapter.this[int]': no suitable method found to override BeachApp.Droid 
    Error CS1503 Argument 1: cannot convert from 'BeachApp.Droid.FileLoader' to 'BeachApp.Interface.IFileLoader'
    Error CS1503 Argument 2: cannot convert from 'System.Collections.Generic.List<BeachApp.Model.Beach>' to 'System.Collections.Generic.List'

    stb.
    Mutasd a teljes hozzászólást!
  • Jó kérdés, látnom kéne az animációt :) Egyszerűbb dolgokat meg lehet csinálni forms-ban könnyen (fade, scale, translate), ha ezekre le tudod bontani, akkor menni fog. Ha nem, akkor meg marad a custom rendereres dolog, amibe rendszeresen belefut az ember ha Forms-ozik.
    Mutasd a teljes hozzászólást!
  • Én samsung reklámot még nem nagyon láttam, az apple-nek is leginkább a bújtatott reklámjait látom (Pl. appleblog az indexen).

    Na most, ha a melódhoz kell az app, és amúgy van benne 30 emberév fejlesztés, hidd el, hogy nem fogod letörölni. A 625. naptár appot esetleg igen. Amúgy, az ilyen általános dolgokat, ha ésszel tervezted az UI-t, akkor aránylag könnyű megváltoztatni.

    Ráadásul, ha jól tudom a xamarin forms pont azt az utat járja, hogy a natív UI fölé tesz egy saját réteget, ami ugyan egy rakás technológiai problémával jár, de cserébe tényleg androidos vagy IOS-es vezérlőid lesznek.

    Alapvetően két megoldás van arra, hogy általános UI-t fejlessz különféle platformokra.

    Az egyik, hogy te csinálsz mindent, és az adott UI-t csak emulálod, azaz a textboxot, comboboxot, radio buttont, stb te rajzolod, te kezeled, csak húzol rá egy, az adott platformra hasonlító UI-t. Ezt az utat járja Pl. a javában a swing, a C++-ban a GTK, Qt.
    Ennek az előnye az, hogy garantáltan nem lesz olyan problémád, hogy az egyik event itt máskor indul el mint amott, vagy hogy elcsúszik az UI, vagy nem kell azzal szenvedni, hogy platformonként más elrendezést csinálj.

    A másik út, ha a natív vezérlőket csomagolod be. Ilyen Pl. a C++-ban a wxWidgets, ilyen a javában az AWT vagy az SWT. Amennyire én tudom, a xamarin forms is ezen az úton jár. Ez az út rögösebb, de tényleg natív UI-t kapsz.
    Mutasd a teljes hozzászólást!
  • Több Samsung reklámot látok, mint Apple-t.
    Emellett a fura érvelésed számomra, aki android és ios felhasználó is vagyok, eléggé félremegy. Utálom azokat az appokat, melyek nem a natív UI elrendezésben, elemekkel van megvalósítva. Hozzá vagyok szokva, hogy a vissza ios-en bal felül van, androidon meg gomb van rá. Aki ezzel szembemegy, annak az appját azonnal törlöm.
    Mutasd a teljes hozzászólást!
  • Helló,

    Engem az érdekelne, hogy szépen animálódó felületet hogyan lehet összehozni közös nevezővel.  

    pl.: Én nem rég csináltam olyat UWP-ben, hogy adott kb 9 menüpont az appban, azokat leraktam egymás mellé mintha egy újságpapírt nyitottam volna szét és mikor átmegy az user az egyik menüpontból a másikba, akkor eltávolodik a felület megkeresi a menüpontot és ráközelít. Ezt én közös nevezővel nem tudom hogyan csinálnám meg. Szerinted hogyan lehetne?
    Mutasd a teljes hozzászólást!
  • A Xamarin Forms el akarja rejteni a 3 platform UI sajátosságait, és egy legnagyobb közös nevezőt ad, amivel elvileg egységesen tudnál dolgozni. Az ötlet az, hogy XAML-ben megírod a UI-t, és az majd szépen fut mindhárom platformon. Ez elviekben ugyan jól hangozhat, és kisebb, egyszerűbb projekteknél oké, de a gyakorlatban tud sok fejfájást okozni, hiszen mindhárom platformnak megvan a saját UI logikája (vesd össze az Android és az iOS képernyők közötti navigációt, activity-k, fragmentek vs viewcontrollerek).
    Mutasd a teljes hozzászólást!
  • Elnézést, kimaradt a link a cikkből, itt megtalálható a file.
    Mutasd a teljes hozzászólást!
  • igen, minden tetszőlegesen stilizálható, pozícionálható, stb. A következő részben van erről némi infó, nemsokára megjelenik :)
    Mutasd a teljes hozzászólást!
  • A játékok ma általában két részből állnak. Az alsó szint a játékmotor, ez felel az olyan dolgokért mint egy-egy sprite, animáció megjelenítése, hang, ütközésvizsgálat, esetleg fizika, GUI. Ami felette van, az a "script" ami tulajdonképp maga a játék. Ez lehet FPS vagy stratégia, vagy repülésszimulátor, vagy 2D-s platformer, vagy logikai játék, vagy ezek kombinációja, mint Pl. a Trine.

    A motor általában C++-ban van, de ez sem feltétlenül mindig igaz, lásd Pl. LibGDX. És persze régen minden más volt. A Commodore64-es időkben mindent assemblyben írtunk és közvetlenül kezeltük a hardvert, és ez a korai DOS-os időkben is így volt. C-ben csak "scripteltek" az emberek. Ja, és akkor még nem volt alattad OpenGL, meg DirectX, meg OS szintű hangkezelés: szépen megírtad a drivert magadnak a különböző grafikus és hangkártyákhoz.

    Amúgy szerintem pont az egyszerű dinamikus scriptnyelvek az okai annak, hogy a legtöbb játék mostanság gyönyörű, de bődületesen ostoba. A legszebb példája ennek a Skyrim. Fantasztikusan néz ki, tényleg úgy érzed, hogy benne vagy a világban, de ez sajnos csak addig tart, amíg az első karakterrel el nem kezdesz kommunikálni.

    Ami az üzleti appokat illeti, egy malomban őrlünk, én pont azt mondom, hogy ott nagyrészt ugyanaz lehet a kód. Max. a megjelenítés stílusa, illetve a képernyők elrendezése kell hogy eltérjen.
    Mutasd a teljes hozzászólást!
  • Ehhez annyit tennék hozzá, hogy a Unity 3D is C++ a Mono, amit használ a C# hoz csak egy script réteg. Szóval a megírt kód csak script és ezt "buildeli" a rendszer az adott platformra fordított JIT-el és ez kommunikál a C++ engine-el. Ezt a CryEngine is átvette és ott is a C# lett a scriptelés egyik nyelve (a Lua mellett). Izlés dolga, de a scripteléshez és a futás közbeni módosításhoz nekem egy egyszerű dinamikus típusos nyelv jobban bejön, a C# nem egészen erre lett kifejlesztve. Minden célra a megfelelő nyelv, ahogy azt már kitárgyaltuk.

    Lehet, hogy az üzleti appoknál szokatlan ez a cross-platform fejlesztés. A játékoknál ez már az assembly korszakban is így működött. Minőségi előírás volt, hogy maga a program lehetőleg ugyanazt az élményt nyújtsa az egyes platformokon. Legfeljebb a contentek minőségét igazították picit komolyabbra erősebb gépen. Saját virtuális gépre és saját nyelven már akkor is cross-platform kódot írtak még c64-re is a profibbak (PC-n, vagy Amiga-n fejlesztettek), pedig akkor még olyan alap dolgok is radikálisan különböztek, hogy egy A betűt hogyan kell a képernyőre kiírni, nemhogy architektúra, vagy esetleges OS közötti eltérések, már amelyiken egyáltalán volt OS.
    Mutasd a teljes hozzászólást!
  • Az Angry Birds első része még egyedi motorral készült - ez akár lehetett platformonként külön is megvalósítva. De a második rész már Unity3D-s, ami azt jelenti hogy a platformfüggő rész kb. annyi, hogy kiválasztották hogy droidra vagy ios-re buildeljen a rendszer. A skype qt alapú, C++ ami azt jelenti, hogy a nagy része annak is multiplatform. Dulingo-t nem tudom, első körben azt hittem, hogy webes (rohadt lassú és elég primitív az UI), de aztán belenézve az apk-ba egy viszonylag kis natív libet találtam, és egy jó nagy dex libet. Sokkal-sokkal nagyobbat annál, amit az app képességei indokolának ha javában vagy mono-val csinálták volna.

    A FB natív app, de ez nem jelenti azt, hogy nem multiplatform.
    Mutasd a teljes hozzászólást!
  • "És a Skype-ot, de szerintem az Angry Birds-öt vagy a Dulingo-t sem írták meg külön minden platformra."
    Pedig de! A nagy cegek reg rajottek, koztuk a facebook is, hogy sokkal kifizetodobb nativan fejleszteni.
    Mutasd a teljes hozzászólást!
  • "Másoljuk be a beaches.json file-t az Assets könyvtárba" irod a cikkben de honnan ? Ezt le tudtam volna tölteni valahonnan csak nem láttam ?
    Mutasd a teljes hozzászólást!
  • Semmivel nem tudsz jobb programot írni android alá javában mint xamarinnal. És ha apple termékkel szennyezném a kezem, akkor valószínűleg ugyanezt találnám ott is. A xamarin ugyanolyan bytekódot csinál mint a droid a javás bytekódból a dex után, az IOS-re pedig kb. ugyanolyan natív kódot az llvm-mel mint az LLVM-es C++ fordító. Mind a kettőből eléred a natív API-t.
    Mutasd a teljes hozzászólást!
  • Totálisan egyet értek és a magam módján valami hasonlót szerettem volna kihozni a mondandómból, de ezt jól megfogalmaztad.
    Mutasd a teljes hozzászólást!
  • IPhone-t azért vesz a felhasználó mert derék reklámfogyasztó jómunkásember. Az appot pedig azért veszi, mert megtetszik neki, vagy mert kell a munkájához. És az igazán sikeres appok több platformon is ott vannak. És a Skype-ot, de szerintem az Angry Birds-öt vagy a Dulingo-t sem írták meg külön minden platformra.
    Mutasd a teljes hozzászólást!
  • Mondok egy olyan dolgot amit itt még senki sem írt. 
    Egy iPhone-t pontosan a platform specifikussaga miatt vesz egy felhasznalo! 
    Es akkor koteles vagyok ot kiszolgalni ugy, hogy a programot szeresse hasznalni ami miatt ilyen telefont, orat, vagy tabletet vett, es nem Androidosat vagy Windowsosat.

    Es ugyanez a teoria all az Androidos felhasznalokra is! Tessek jo programokat irni!
    Mutasd a teljes hozzászólást!
  • A lényeg: vannak olyan specifikus dolgok és nem is kevés, amik másképp viselkednek más rendszereken

    Persze hogy vannak. Csak az épeszű fejlesztő ezt kiszervezi egy önálló részbe és megoldja platformfüggőként. És persze ez is attól függ hogy mit akarsz. Ha az alkalmazásos 90%-a azt csinálja, hogy kitesz egy órát a taskbarra, akkor nyilván nem érdemes több platformosra csinálni. Ha az alkalmazásodban van 15 emberév üzleti logika ami közös és van egy 5 óra alatt lefejleszthető platform-specifikus rész, akkor nem fogod az egész kódot lefejleszteni 3x az egészet minden platformra, hanem ezt a részt leválasztod és megcsinálod külön (ami kb. plusz egy óra plusz ráfordítás, de nyertél vele 30 évet). És persze ez nem csak üzleti appoknál néz ki így, lásd Pl. Skype. Ott sem fejlesztették le külön javában droidra, objc-ben IOS-re, C#-ban windowsra, hanem van egy közös C++ kódbázis és egy qt-s UI.
    Mutasd a teljes hozzászólást!
  • Hol nincs ikon? Mind a három rendszeren van ikon. IOS-en és Droid-on widget is van. Windows-on live tile van. Megvalósítható az óra a live tile-n is és a widget-eken is, csak másképp.
    ---
    A lényeg: vannak olyan specifikus dolgok és nem is kevés, amik másképp viselkednek más rendszereken és erre Te annyit mondasz, hogy akkor azt nem csináljuk meg, hanem...

    Én erre annyit mondok, hogy megcsináljuk csak úgy ahogy az adott eszköz, vagy rendszer arra lehetőséget ad. Ha erre 3 külön megoldás kell, akkor azt csinálom, hogy illeszkedjen ahhoz amit az eszköz és a rendszer tud.
    ---
    Arról nem is beszélve, hogy általában más hardveres összetétele van a különböző eszközöknek. Egy Iphone átlagosan erősebb procival lesz felszerelve, mint egy winphone. Vagy épp egy asztali pc is jóval erősebb lesz mint egy telefon és sok esetben ezekre is oda kell figyelni, ha egyszerre több eszközre akarunk fejleszteni.
    Mutasd a teljes hozzászólást!
  • Az a baj, hogy kibúvókat keresel. Kell egy óra alkalmazás, ami mutatja az időt ez az alap probléma. Te platformokban gondolkodsz és mindenütt platform specifikus megoldást keresel, ezért akarsz mindent ikonokra, meg minden másra ráhárítani. Én egyszerűen megoldottam a problémát úgy, hogy maga az app mutatja az időt, vagy amit épp kell, 100%-ban ugyanazzal a forráskóddal, kinézettel mindennel minden platformon. Lássuk be ez azért általánosabb, mint olyan program, ami az ikonon forogva mutat valamit, főleg olyan platformon ahol még ikon sincs.

    Amit mutatsz egy windows-os albak

    Amit mutattam egy platformfüggetlen UI, amit arra fordítasz és azon futtatsz, amire és amin akarsz.
    Mutasd a teljes hozzászólást!
  • Widget, live tile...
    Amit mutatsz egy windows-os albak, vagy egy ablak, nem egy widget, vagy egy live tile...
    Mutasd a teljes hozzászólást!
  • Nem vagyok a babád.

    Ha nem tudja a programozó kijavítani a saját munkáját az már eleve probléma.

    Én eredetileg azt mondtam, hogy más a windows, más az ios és más a droid. Nem tartom jó dolognak 100%-ban ugyanarra törekedni a három rendszeren, mert nem megvalósítható. 

    Ez az alap történet. Előzőleg adtam egy megoldandó példát. Most megkérdezem, miért mondhatom azt, hogy nem lehetséges megoldani. Azért, mert windows-on live tile van és nem widget ami már magában másképp működik. 

    Windows-on nem tudok a live tile-ra ikonokat helyezni. Akkor sem, ha ugyanazt a funkcionalitást akarom elérni. De rengeteg olyan van amit egy windows-os telefon másképp csinál mint a másik. Próbálj meg Iphone-ról zippelt fáljt generálni és elküldeni mailban. Ez windows alatt simán megy, IOS-en nem. Ha pedig zip-re van szükség, de valamelyik rendszer nem tudja, akkor vagy nem zippelsz, vagy csak az adott eszközön nem. De ez már megint azt jelenti, hogy nem ugyanaz.
    Mutasd a teljes hozzászólást!
  • Még mindig nem érted!?
    Te szerinted a fejlesztés: karórára egy menü, telefonra 2 menü, asztalra 20 menü, xboxra 5 menü.
    Csakhogy két telefon se egyforma babám, vannak egész tablet méretűek, meg vannak egész kicsik is. Azokra mi alapján teszed ki a menüt, képernyőnként eltérően? Aztán majd ha jön a visszajelzés mi alapján javítod a programot?

    Csinálj egy olyan alkalmazást ami Iphone-on, droid-on, windows-on is fut xamarin-nal és nem csinál mást csak kirak nekem egy órát a menümbe... Csinálj egy widget-et. Nézzen ki ugyanúgy és viselkedjen ugyanúgy és a kód legalább 50%-a legyen közös minden rendszeren. Szerintem nem fogod tudni megcsinálni.

    Kész vagyok!
    Mutasd a teljes hozzászólást!
  • Én is ezt kérdem. Azt írtam, hogy mást tud más rendszerrel. Más az, ha telefonon kicsi a képernyő és csak egy listát teszek ki a méret miatt és más ha pc-n már hármat kirakok, mert kifér... Mármint ezzel más felületet adtam, mit nem lehet ezen érteni? 

    Írtál samsung telefont, nem? Engem nem érdekel, hogy Samsung, vagy LG, vagy milyen MÁRKA. Az tudod mi? :D

    Én operációs rendszerre, eszköz típusra fejlesztek. 
    pl.: Windows telefon/tablet/pc
    ios: iphone, ipad
    droid: teló/tablet

    Windows-on belül mást tud egy telefon, tablet és mást egy pc. (oké, van xbox, meg mindenféle, de azt most nem részletezem..)

    ----
    Más: 
    Csinálj egy olyan alkalmazást ami Iphone-on, droid-on, windows-on is fut xamarin-nal és nem csinál mást csak kirak nekem egy órát a menümbe... Csinálj egy widget-et. Nézzen ki ugyanúgy és viselkedjen ugyanúgy és a kód legalább 50%-a legyen közös minden rendszeren. Szerintem nem fogod tudni megcsinálni. (Nem azért, mert nem vagy jó programozó, hanem mert nem lehetséges.)
    Mutasd a teljes hozzászólást!
  • Saját magadnak mondasz ellent. Először leírod, hogy nehogy már lebutítsuk a programot azért, mert a mobil képernyője kisebb felbontású, aztán meg leírod, hogy hát a készülék típusa -és vele együtt a képernyő méret és felbontás is- lényegtelen. Akkor most mi van?
    Mutasd a teljes hozzászólást!
  • Nem nagyon értem ezt a személetet. Számomra nagyon furcsa lenne azért butítani egy program pc-s változatát, mert a telefonos változatra a képernyő mérete miatt csak annyi adat fér ki amennyi. 

    Nem a telefon márkája a lényeg, hanem az operációs rendszer ami mögötte van.
    Mutasd a teljes hozzászólást!
  • Én eddig úgy tudtam a szoftverfejlesztés a bonyolultság leegyszerűsítését és a problémák egységes megoldását jelenti, nem azt, hogy mindent túlbonyolítunk és szétbontunk aszerint, hogy épp Samsung, vagy LG telefonon fut e a program. A backend elkommunikál például az Azure-al, a frontend meg a backendel, aztán ennyi. Az, hogy a backend éppenséggel egy PHP rendszer a frontend meg mondjuk swift és a közös nevező a json az kb. huszadrangú részletkérdés. Itt semjó, ha halmozzuk a nyelveket és technológiákat, de legalább valami egységesség azért legyen és ne eszközönként legyen minden teljesen más, mert az teljesen káosz lenne.

    Ha a telefonon kifér 1 db lista, akkor asztalon is, a konzolon is, meg a karperecen is egy lista lesz, ilyen egyszerű. Megint csak nem bonyolítunk túl semmit, mert ez se fejleszteni, se megtanulni, sem pedig supportálni nem kíván senki többszörösen platformonként, készülékenként, képernyő méretenként stb. Ha igen, akkor meg fizesse az óradíjakat a fejlesztőnek. Nyilván annak is megvan a maga haszna, amit te mondasz és a megrendelőnek ezt be is tudod adni az egy jó dolog., de lehet a saját munkád nehezíted ezzel.
    Mutasd a teljes hozzászólást!
  • A skype nem igazán az. Ő egy kommunikációs program. Üzleti app Pl. az amivel a villanyóra cserélő villanyszerelők szaladgálnak - igaz, az még PDA-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