Köszönöm, hasznos olvasnivaló. Én sosem fogok programozni, sem tudásom, sem időm nincs hozzá, de jó egy kicsit belátni a dolgok mögé. Remélem lesz folytatás, engem érdekelne.

Volt egy idő amikor programoztam (Linux karakteres uzemmód) de végül kiderült hogy nem az én világom. Grat a cikkhez, jó lett.

Köszi, hasznos kezdeményezés!

Bízok benne lesz folytatása is..

Vén csataló vagyok a programozás világában, igaz nem a win/linux vonalon. Ettől a cikktől nem lett egyszerűbb az életem. Nekem nem elég szájba rágós.
Kicsit sok a szerzői kikacsintás, kevés a magyarázat.

Szia!
Ebből úgy érzem, hogy inkább a mikro controlleres programozásban vagy otthon, az pedig, no offense, nem igazán egyenrangú egy OOP-vel.
Nem volt célom a szájba rágás mivel nem nulla Java tudás mellé szántam a cikket ahogy ez le is van írva benne. Viszont köszönöm a kritikát és szeretnélek megkérni, hogy kifejtsd kicsit. Mi volt ami nem világos, jobban ki kellett volna fejteni? Mit értesz kikacsintás alatt?

És még italozott is közben!

Hmm, az első sör után már egész jól is néz ki a dolog.

Oh, fck. biztos reflexből sört írok sor helyett
Köszi, javítva!

Érdekes, hasznos cikk.

Köszönöm a cikket!
Mobil fejlesztésben új vagyok, a cikked hatására azonban ma este elindultam az úton (igaz, már egy éve tervezgettem). Küzdöttem is az Android Studio beállításával és pár nem szájba rágott aprósággal, de nekem kifejezetten tetszett, hogy küzdenem is kellett, sokat tanultam belőle!
Bevezető Android alkalmazásnak ez kiváló volt, viszont annyi mindent nem tudok még, hogy azt felsorolni sem tudnám. Ugye nem hetek, hanem legfeljebb napok kérdése a cikksorozat 2. részének publikálása?
Ha esetleg mégsem: szerinted hol érdemes elindulni a tanulásban? Kismillió Android tutorial van a neten, melyiket érdemes választani?

Köszi, tényleg hasznos írás. Egy ideje már akarok írni programokat Droidra, de egyelőre még nem jutottam el addig, hogy rászánjam az időt. Talán majd most . Várjuk a folytatásOKat is!

Szia!

Nem (csak) tőlem függ a folytatás publikálása.
Mondjuk annyiban biztosan, hogy még nem kezdtem el. Mindenképp megakartam várni, hogy erre milyen visszajelzések lesznek mert több irányba is lehetne elindulni. Egyértelműen jók a visszajelzések így folytatás lesz az biztos. Az irányban viszont még nem vagyok biztos. Egy szájba rágósabb inkább mutogatós mint teljes alkalamzás bemutatásán vagy pedig ezt a vonalat tovább víve egy másik irányból megközelített appon gondolkodom. Mind a két vonallal hamar kész tudok lenni tehát úgy tervezem, hogy a héten leadom a követekző cikket (majd elkezdem a 3.-részt) és utána már a korrektorokon múlik a megjelenés ideje.

Ha van fejlesztési ismereted és nem félsz az angol nyelvtől akkor magát a /developer.android.com-ot tudom ajánlánai. Minden jól és érhetően van dokumentálva. Na meg persze kel legy ötlet, valami apróság, és neki kell ülni megvalósítani. Nem kell félni a kudarctól és használni kell a Google-t. Elég nagy közösség van akrár stackoverflow-n is ha elakad az ember de nagyon sok bemutató, tutorial érhető elmás oldalakon is!

Jó cikk. Jöhet a folytatás...

Előre bocsátom, hogy én nem tanultam programozást, totál laikus vagyok. Azt gondolom, hogy nem csak Java, hanem Android szempontból is messziről indítottad ezt a kurzust. Ahhoz, hogy valaki alkalmazást fejlesszen, előbb a rendszer működését kell megismerje. Valami ilyesmire gondolok.

Egy kérdés. Te, aki ismered az Android Stúdiót, egy kezdő számára mennyire tartod hasznos előszobának az App Inventor -t (illetve, ahogy látom, már App Inventor2 is van)?

[ Szerkesztve ]

Gondolom nem ebből a cikkből fog vki megtanulni programozni, de azért érdemes lenne a végére az apk fordítást belerakni, mert nem mindenkinek lesz egyértelmű. Esetleg az apk aláírása is beleférhetne, mert úgy az igazi. Illetve, az apk telepítéshez pár szó, mondjuk az usb debug bekapcsolása.

Ebből nem lehet megtanulni programozni, nyilvánvaló. Inkább csak érdekesség a laikusok számára. Pl. az activity/fragment életciklusa kötelező tudás egy droid fejlesztőnek, de sorolhatnám még (pl. listenerek nélkül nem élet az élet).

Köszönöm a tippet, ezen fogok végigmenni. Plusz persze azon is amit írsz.

Úgy vélem ha valaki rendelkezik némi alapismeretekkel annak kevés szüksége van a rendszer működés ismertetésére hiszen lényegébenm egy Linux-ról beszélünk.
Viszont megfogadom a tanácsodat és a következő részben inkább belemgyünk az alapokba nem pedig valós használható appot kezdünk hanem inkább részekre bontva, felépítve a dolgot.

Az appinvetor pedig jó dolog annak aki nulla tudással rendelkezik és egyből a mélyvízbe akar ugrani. Ellenben szerintem ha valaki nulal tudással rendelkezik az először inkább a Java-val és a Linux-al ismerkedjen, utána pedig az Android Studio elég sokat nyújt, hogy megértse a dolgokat.

hati: Erre nem gondoltam, ha benne van az ember vannak olyan dolgok amik kézen fekvőek de másoknak idegen, következő részben erről is lesz szó!

Köszönöm mindenkinek a kritikát és bárkinek van még kérdése, meglátása az ne kíméljen így lesznek jobbak a cikkek!

[ Szerkesztve ]

Így van, főleg egy cikk alatt amit kb 5 perc végigolvasni értelmezni meg 15
Ezért is szeretném inkább több részre nyújtani és mindig valami mást, valamivel többet bemutatni. Természetesen nem programozni tanítani a célom hanem inkább a látásmódot segíteni vagy a kedvet meghozni hozzá, hogy belelássanak az emberek a motorháztető alá is. EZért se mentem bele az alapokba vannak részek amikkel napokat ellehetne pepecselni.

Az activity-t mindenképpen mutasd be. Úgy értem, hogy az életciklusát (nem csak az oncreate-et) és egy másik activity elindítását, illetve bezárását.
Nem árt kitérni a droid sajátosságára, azaz, hogy mi történik a telefon/tablet elforgatásakor, az alkalmazás háttérbe/előtérbe kerülésekor.

[ Szerkesztve ]

Nekem pont megadta a cikk a lökést ahhoz, hogy elkezdjem felfedezni az Android fejlesztés világát, így én nagyon örülök neki. Persze, az Android fejlesztés nyilván egy komplex dolog, aminek a megismerése nem kis feladat, és nyilván kismillió elhagyhatatlan tudásszelet még csak említésre sem került (ami pedig igen, azok is csak nagyon felületesen), de fura is lett volna egy 1000 oldalas könyv ismeretanyagát összefoglalni itt pár oldalon. A cikkíró adott egy látványos kezdéshez útmutatót, Somatom egy régi, de alapjaiban gondolom még megfelelő áttekintésre linket, illetve megkaptam, hogy az android.com-on pl. érdemes végigmenni.
Dolgoztam pár évet Java fejlesztőként, nyilván elboldogulok az Androiddal is, csak rá kell szánnom minden este pár órát. Persze, ha valaki még nem írt programkódot, nem látott még XML fájlt, szóval tényleg távolról indít, annak ez biztosan kevés lenne, de a cikkíró eleve elvárt bizonyos előismereteket. Szerintem nem kell feltétlenül egy első részben helyet kapjon az apk készítés, a Play áruházban publikálás, meg ilyenek. Egyelőre örüljön az ember, hogy van valami értelmes, működő produktuma.

Az általam linkelt tananyag megismerése után próbálkoztam App Inventorral apró "segédalkalmazásokat" kreálni E-Robot alá (automatizáló, mint a Tasker). Egész jól ment a dolog ahhoz képest, hogy nulláról indultam. Ajánlom még a kezdők figyelmébe az App Factory -t, amivel Tasker -ben készült projecteket lehet önálló alkalmazásként exportálni. Rengeteget lehet tanulni ezekből.
Az viszont borzasztó csalódás számomra, hogy a Google verzióról, verzióra egyre kevesebb mozgásteret hagy. Ez nem csak az én véleményem, hanem az automatizálók fejlesztői is erre panaszkodnak. Ami pedig a fejlesztőket illeti, sztem óriási hiba, hogy (tisztelet a kivételnek) nem hagynak kellő mozgásteret a felhasználóknak. Írok egy (sztem) nagyon pozitív példát: Motion Detector.
Nem az a lényeg, hogy mire való az alkalmazás. Hanem az, hogy külön aktiválható, hogy nyilvános broadcastokat küldjön és fogadjon. Külön help link van, ahol a pontos üzeneteket publikálja a fejlesztő. Az automatizálók pedig oda/vissza tudják kezelni a broadcastokat. Így egy átlag user számára is símán összekapcsolhatóak az alkalmazások, amitől egy Legová válik az Android. Sztem ez nagy sikerélmény. Jó lenne, ha minél több fejlesztő lehetőséget adna rá az alkalmazásában.

[ Szerkesztve ]

A szakdolgozat egy jól összerakott (igaz már részben nem aktuális) iromány. Akkoriban még kicsit más volt a dolog, most már sokkal nagyobb a közösség, sokkal több dolog elérhető egyéb forrásokból.

A megszorítások léynegében egy kétélű penge. Ha túl nagy a szabadság akkor sebezhetőbb vagy legalábbis van rá esély, hogy sebezhetőbb lesz az egész. Ha túl zárt akkor a felhasználó nem örül, kell egy arany középút és a Google is ezen fáradozik. Becsuk egy kaput és próbál rá valami alternatívát találni (ha lehetséges).

Sajnos ami a nagy előnye a rendszernek az az egyik hátránya is.

Köszönöm a cikket, várom a folytatás(oka)t! Érdeklődnék, mennyire lenne igény egy .NET környezetben Xamarin segítségével bemutatott sorozatra android fejlesztés terén.

Nem kellene ehhez először Java programozást tanulni?

Ja bocs, a 4. oldalon már szóba került a Java.
Csak mondjuk az elején említett " minimális programozási tudás"-nál azért többre lesz szükség szerintem.

[ Szerkesztve ]

Valóban a controllerek világában dolgozom, bár nem annyira mikro, inkább PLC és DCS.
"nem igazán egyenrangú egy OOP-vel" - szállj le a magas lóról, ha magamfajta földivel van dolgod!
Kikacsintásra példa:
"Gyors átgondolás után megállapítható, hogy bizony lineáris elrendezésre lesz szükségünk, így kezdjük is egy LinearLayout-tal a felépítést. Ideje továbbgondolni. Mikre van szükségünk? Gombokra! Naná. Viszont milyen elrendezésben? Egy LinearLayout csak egymás alá dobálná őket. Hát az bizony nem jó.
Gyors gondolkodás után megszületik a válasz: Több LinearLayout más orientációs elrendezésben! Ez már sokkal jobban hangzik. Viszont, ha kicsit belegondolunk, akkor"
Az aláhúzott részek konkrét infót nem tartalmaznak, az olvasóval próbálsz bratyizni. Ez egy vlogger stílus, nem írt szakirodalmi szöveg. Nem vagyok híve én se száraz leírásoknak, de ez nekem már a ló másik oldala.
Ráadásul a szövegben saját magaddal kerülsz ellentmondásba (lineáris jó, de mégse).

Android programozásba már belenyaltam korábban, így nem teljesen isemeretlen előttem. Az API fogalmára még emlékeztem, de az activity-re már nem. Szerintem ezek nem java, hanem android fogalmak, így ezeket nem ártene kicsit bővebben elmondani.

Bár a nyelv elég terjengős, és jól követhető, nem ártana egy-két (fél-)mondat formátumú komment a sorok mögé/közé magyarul.

public void handleClick(View view) { //TODO }
A nyelvet nem ismerőnek segítség ha, olyan változóneveket használsz, amiről ordít, hogy Te adtad. Pl. h_view1 biztos nem valamelyik alapkönyvtárból való.

Talán még nem vettem el kedved a folytatástól, mert amúgy komolyan érdekel egy olvasmányos cikk az Android programozásról, hol tart, mi a trend, mi a homályos jövő.

Nem úgy értettem a nem egyenrangút, hogy egyik jobb mint a másik hanem, hogy külön világ. Volt már szerencsém micro controllerekhez és teljesen más világ.
Jól látod a helyzetet a "bratyizás" volt a cél, hogy jobban test közelbe tudjam hozni a dolgot. Ezért is volt az ellentmondás amit pont felhoztál, próbáltam kicsit a valós fejlesztési helyzetbe hozni a dolgot. Nem a száraz ez így az meg úgy és kész a spanyol viasz.
Természetesen érthető, hogy ez a stílus nem mindenkinek jön be.
Az Activity szerintem elsőre pont jól ki lett fejtve, hogy egy apró kép legyen róla először de az vitathatatlan, hogy oldalakat lehetne róla írni. Ellenben akkor már túl száraz lenne.
A kedvem meg egyáltalán nem vetted el, ez az első ilyen jellegű cikkem és minden tanácsra nyitott vagyok, hogy a következők jobbak legyenek! A te tanácsodat is megfogadom és bővebben fogok kifejteni, kevesebbet bratyizni.
Megpróbálom eltalálni az arany középutat.

[ Szerkesztve ]

Ami engem érdekelne, hogy a többnyelvűséget lehetővé tevő lokalizáció hogyan oldható meg Android alatt?

Azt tudom, hogy hogyan kell lokalizálni egy appot, konkrétan az érdekelne, hogy a különböző Online Lokalizációs Tool-ok output xml fájljai hogyan építhetőek be a "forrásba", a kettő hogyan találkozik a fejlsztő oldalán?

Crowdin, Localise.biz, Oneskyapp stb.

Rendszeresen összefutok 2018-ban is olyan fejlesztőkkel, akik mindezek megléte mellett egy szedett vedett XLS-ben küldik el a fordítandó stringeket.

Különböző erőforrások vannak, és a rendszer az eszköztől függően választja ki az épp használandó erőforrást. Ilyenek pl. az általad említett xml fájlok, ha magyar nyelvű a telefon akkor a magyar xml-t fogja használni. Fejlesztés közben pedig az xml-ben lévő ID-k (name) alapján használhatod a stringeket.

Hasonlóan működnek egyébként a többi erőforrások, pl. a képek is. Ott a telefon pixelsűrűségétől függően választja ki az ahhoz illő felbontású képet.

Köszi,

Ezekkel tisztában vagyok.

Amivel nem, hogy a Fordító környezet online kapcsolatban van-e a megfelelő Online Lokalizációs site-al, azaz mit kell tennie az egyszeri fejlesztőnek, hogy a különböző nyelvek folyamatosan frissülő xml fájljai minden build esetében bekerüljenek a forrásfába?

Szóval mit kell ahhoz tenni, hogy ez automatikus legyen, vagy ha e nem megoldható, akkor mi mindent kell manuálisan elkövetni a többnyelvűség eléréséhez?

Folytatásért kiált...!

OK, lássuk a következő részt!
Előre hát a megkezdett úton!

"Gondolom nem ebből a cikkből fog vki megtanulni programozni"

Valóban.
Egy ilyen többrészes ismeret terjesztő mű, adhat egy lökést a programozás/ alkalmazásfejlesztés felé.
Legalább az kiderül, kell elindulni.

Szoftver fejlesztői környezet ismeret.
Programozási nyelv ismeret,
A futtató rendszer sajátosságainak ismerete.
Programozás technikai ismeret.
A biztonsági rések kiszűréséhez szükséges ismeret.

Nagyjából ezek kellenek, hogy valaki épkézláb alkalmazást tudjon összehozni.
Ez nem fér bele egy néhány részes ismertetőbe.

Én azt mondom hogy valamilyen keretrendszerrel érdemes elkezdeni a fejlesztéseket, megkönnyíti az életed.
Xamarin, Corona ilyesmi.

A többnyelvűséget a droid az alábbiak szerint oldja meg.

A stringeket a fejlesztő kirakja az alábbi fájlokba:

res/values/strings.xml
<string name="text_a">This is an English text</string>

res/values-hu/strings.xml
<string name="text_a">Ez itt egy magyar szöveg</string>

A text_a stringre meg az R.string.text_a kifejezéssel hivatkozik.

Pl. textView.setText(R.string.text_a);
nem pedig textView.setText("This is an English text");

A készülék nyelve alapján a droid automatikusan a megfelelő xml-ből veszi az értékeket.

Azaz, ha elkéred a fejlesztőtől res/values-hu/strings.xml tartalmát, akkor le tudod fordítani a szövegeket magyarra és Ő a következő fordításkor, az új xml-el tudja kiadni az appot. Neki ezzel semmi dolga nincsen.

[ Szerkesztve ]

Aki most vágna bele hobbiból mobilapp fejlesztést tanulni, annak én ajánlanám a Google új cross-platform fejlesztőkörnyezetét a Fluttert. Már most elég jól működik és minden bizonnyal ez lesz a Google következő mobil oprendszerének fejlesztőkörnyezete.

Szerintem arra utalt a kérdése, hogy ha valaki egy ilyen oldalon fordíttat akkor az automatikusan bele generálja-e valahogy az XML-t a projektbe vagy neki onnan le kell szednie és belerakni a projektbe majd buildelni.

A válasz pedig az, hogy ezek általában valamilyen GIT vagy SVN-hez kapcsolódnak így léynegében automatikusnak mondható a dolog viszont csak következő buildelésnél kerül bele (már ha updatel a fejlesztő )

Annak aki most vágna bele nulláról én pont nem ajánlanék semmi ilyesmit. Se framework se semmit. Megkönnyíti a dolgot az nem kétség de az elején inkább az ismerkedés a cél mint, hogy beleesni egy ilyenbe. Olyan mintha valaki hamarabb tanulna mondjuk Angular-t mint JavaScriptet. Persze ez csak az én véleményem.

Szerintem egy framework a learning curve-t is lerövidíti, minek írnál meg olyat 0-ról amire van kész és csak használni kell? Sokan azért nem mernek belevágni mert félnek a kudarctól. Anno Androidra egy egyszerű funkciót nehéz volt megírni, sokszor nem működött úgy ahogy kellene, senki nem akar szüttyögni. Pont a sikerélmény ami az elején fontos, az ilyenekre a különböző frameworkok tök jók mert gyorsan elkészül 1-1 kissebb projekt, ha olyan igény van akkor te is tovább tudod fejleszteni a saját funkcióiddal később amikor már az alapok jobban mennek.

Bár ez csak az én véleményem, nem szeretek felesleges köröket menni

Pont azért hoztam fel az Angulr és JS példát mert ismerek olyanokat akik Angular-ral kezdtek és utána JS környezetben megvannak lőve. Na most a legtöbb Android framework is ilyen. Ha web fejlesztesz Java-ban akkor se a Spring-el fogsz kezdeni hanem simán servletekkel aztán ha azt érted akkor mehetsz bentebb. Hatékonyabban tudsz debuggolni, fejleszteni mert tudod mi történik a háttérben hiába van elfedve. Persze ha már van tapasztaltod vagy akár profi Java-s vagy akkor más a helyzet de így elsőre értettem aki 2 ezer sort se látott még életében

Sokan azért nem mernek belevágni mert félnek a kudarctól.
Épp ez a baj. Az elején mindenkinek van kudarc. Sőt akár napi szinten is futok bele. Épp az előbb ültem 2 órát egy 50 soros Python kód felett és alig sikerült helyre pofoznom nem is tudom hanyadik nekifutásra jött össze. Szóval ezek általános dolgok, hogy valami nem sikerül, hogy valami nem működik vagy akár le se fordul. Ettől nem kell félni.

[ Szerkesztve ]

Na igen ez így teljesen jogos. De teljesen tapasztalatlan, kezdő programozónak meg nem biztos hogy androiddal kéne kezdeni. Inkább valami nagyon egyszerű console appokkal, monduk C-ben vagy Pythonban, neadjisten Pascalban, bár mindegyiknek megvan a maga szépsége. (Én most épp C/AL-ben programozgatok, nagyon "fincsi" )

Pontosan ez érdekelne. Hogy mekkora munka ezt automatizálni a fejlesztő oldaláról?

Nap mint nap fordítok xml-eket az említett Online Tool-okon keresztül, de azt látom, hogy ezek bekerülése a forrásba marhára nem akar haladni.

Ez miért lehet? Ezért érdekelne a dolgok háttere. Nem a fordítás HOGYAN-ja, hanem a kész (vagy félkész) xml fájlok forrásba történő importálásának módszere érdekelne.

És nem az itthoni is használható "apktool"-os megoldás érdekel, bízok benne a fejlesztők nem ezzel építik be a nyelvi xml fájlokat a publikus app-okba.

Leírtam. Ha kész az xml, akkor a fejlesztő felülírja a régit és készen van. Így fordították le az egyik appomat finn, spanyol, német, francia, olasz nyelvekre. Elküldtem a strings.xml-t, majd visszaküldték lefordítva. Bemásoltam a régi helyére és a következő fordításban benne volt az adott nyelv. Nekem 1 perc volt.

Nagyon hamar megvan ha egyszer kész a fordítás. Ezeken az online toolokom meg szerintem még Git is van tehát ha kész a file akkor csak egy updatet kell tolnia a fejlesztőnek és mehet a build.
Megmondom, nem foglalkoztam sose ilyen online fordítási lehetőségekkel de szerintem kifejezetten olyan end-point ami egyből az xml-be tolja olyan nincs. Nem is nagyon látok rá így hirtelen megoldást. Azt az xml-t mindenképp kézzel kell beleraknia a projektbe majd buildelni

Értem, tehát csak akarás kérdése mindez.

Hmm, szerintem ConstraintLayout packed vertical/horizontal chain egy fokkal egyszerűbb lett volna, és azt még GUI-ból is össze lehet rakni - hamár most lett 1.1.0

Nem rossz indítványozás, de elég sok a kódban a `result.getText().toString()`, kb biztos hogy lehetne még rajta redukálni, mert így csak az érti, aki írta.

Van egy tök jó videó, amit a minap láttam: https://www.youtube.com/watch?v=8bZh5LMaSmE - ez aztán megpucolja a kódot rendesen a végére aki tudja mi az az OOP vagy legalább hallott róla, annak kifejezetten ajánlom.

[ Szerkesztve ]