Új hozzászólás Aktív témák
-
thiclyoon
aktív tag
válasz hodav1993 #4906 üzenetére
Szia!
(Amit írok az natív fejlesztésre vonatkozik: android studio, java/kotlin. Ha crossplatform-egyéb megoldásban gondolkodsz (xamarin, react, c#, ...), akkor érdemesebb lehet más tapasztalatát elolvasni.)
Én személy szerint csak oop + "event driven programming", vagyis Java tapasztalat után tudtam megtanulni az androidot, bár régebben nem használtam az udemy-t, lehet, hogy ezzel már menne tapasztalat nelkül is. Tehát udemy-n tanultam meg végül, ezt a kurzust választva. Nem bántam meg, szerintem nagyon jól elmagyarázzák, de hátha mástól is jön 1-2 tipp. Ahogy írtam, nekem volt a kurzus előtt is tapasztalatom több nyelvben is, de a leírás alapján erre nincs szükség. (Mindenesetre ha a "Java Deep Dive" fejezet után se érzed magadat magabiztosnak a java körül, akkor érdemes lehet egy programozós videosorozatot / egyebet keresni.)
Jelenleg egyre inkább nyomatják a Kotlin nyelvet is a Java mellett/helyett - én azonban most is Java-val kezdenék, és utána ismerkednék meg a Kotlinnal (egymást ki tudják egészíteni, nem idegen nyelvek). Eléggé kihalt topiknak tűnik, de ha kérdésed van, igyekszem segíteni -
thiclyoon
aktív tag
válasz hodav1993 #4908 üzenetére
Crossplatformban annyira nem vagyok otthon*, annyit tudok, hogy pl Xamarinban lehet csinálni ilyet (C# nyelv, Visual Studio környezet) - ezt én réges régen elkezdtem, de nagyon nem jött be. Azóta jött pár új dolog, a React az JavaScript-tel tudja ugyanezt, számomra a legújabb versenyző pedig a Flutter - ez Dart-tal megy, mindössze ennyit tudok róla.
Játékokhoz ajánlottnak mondanám a Unity-t és az Unreal-t, mindkettő crossplatform. Előbbit kicsit egyszerűbbnek mondják.
Talán ez átment, de egyelőre nem vagyok a crossplatform híve - inkább a natív appfejlesztés jött be eddig. Ha natívban gondolkozol, akkor azt tudnod kell, hogy iOS appok fejlesztéséhez kell egy mac (bármilyen), esetleg hackintosh. Crossplatform appokkal (amiket feljebb írtam), ez kikerülhető, ez a legnagyobb előnyük (számomra). Ezzel együtt tervezek "crossplatformul" megtanulni, Xamarin + Unity mindenképp
Ha van kérdésed jöhet ide is vagy privátba, ahogy könnyebb
* (Androidra Windows / Mac + Android Studio + Java-t, iOS-re Mac + XCode + Swift-et használok legszívesebben)
-
thiclyoon
aktív tag
válasz Ablakos #4922 üzenetére
Nálam a legfrissebb stable verzió van fent (3.6.1, bár emlékeim szerint így működött régebben is), a kezdőképernyőn "Check out project from Version Control" alatt van "git" menüpont, ott ha megadok egy url-t, már csinálja is a dolgát. Amúgy igen, az android studio a default. Ha nem erre gondoltál, akkor nem igazán értem, részletezd kicsit kérlek.
-
thiclyoon
aktív tag
válasz bandi0000 #4926 üzenetére
(Nem biztos, hogy segít, de hátha..)
Én nem olyan régen kezdtem el használni a free tier-en túl az egyik projektben, egész pontosan március az első hónap, ami végig blaze plan-ben fut (február közepén váltottunk fizetősre, februárban még nem értük el a fizetős határt, így március elején nem kellett semmit fizetni). Szerintem amint úgy gondolod, hogy kellene egy fizetős funkció, akkor érdemes upgrade-elni blaze plan-re, ugyanis bár már ekkor meg kell adni egy kártyaszámot, de nem von le semmit. Mi jelenleg a beállított budget alatt vagyunk, de eddig nem jött semmilyen levonás / számla. Ennél többet április elején tudok mondani, de ha belegondolsz, mivel a funkciók úgy vannak megadva, hogy "x $ / second", így nekem ebből az jön le, hogy minden hónap elején jön majd valami, hogy ennyit és ennyit fogyasztottál, ezért ennyit és ennyit levonunk. De ha valakinek több tapasztalata van, ossza meg hogy okosodjunk[ Szerkesztve ]
-
thiclyoon
aktív tag
válasz bandi0000 #4928 üzenetére
A kártya beállítása után kért egy budget-et tőlem, és ha annak elérem az 50-90-100%-át, akkor minden project owner-nek küld email-t (ezt még nem sikerült kipróbálni, nem vagyok még 50%-nál sem). Ezek alapján ha gáz van, akkor egy gyors leállítás - megjavítás jó lehet ilyen helyzetben, főleg a fejlesztés során nyilván.
Firestore-ban collection-ök vannak (bár igaz, ezek ~ táblák). Az adatbázis - backend rész annyira nem az én műfajom, de igen, természetesen ez is megoldható benne (és ez a jó megoldás szerintem is). A "kapcsolótábla" tartalma (helyessége) viszont tőled függ, ha te rossz id-t írsz bele az userid "oszlopba" az egyik rendelésnél, akkor nem fog szólni neked senki... legalábbis én nem tudok róla, hogy itt lehetne ilyen kényszereket létrehozni.
Alapvetően szerintem nyugodtan gondolhatsz a firestore-ra úgy, mint egy sql adatbázis, max az ilyen dolgokat, mint a kényszerek, neked kell implementálnod (-> firebase functions részben ezt elég jól el tudod intézni). Ez sem egy vészes dolog, sima nodejs-ben megy az egész.
-
thiclyoon
aktív tag
válasz Ablakos #4932 üzenetére
Az implementáció ismerete nélkül én az
onSaveInstanceState()
és azonRestoreInstanceState()
függvényeket definiálnám felül. Vannak részletek, amire érdemes figyelni, pl. hogy az előbbi függvény nem biztos, hogy minden esetben lefut, pl. back gombra nem fog futni, hiszen az user explicit vissza akart lépni. Ekkor vagy azonPause()
vagy azonBackPressed()
függvénnyel érdemes foglalkozni. Alap funkcionalitásért viszont elég az első kettő függvényben megcsinálni a dolgokat[ Szerkesztve ]
-
thiclyoon
aktív tag
válasz Ablakos #4935 üzenetére
Illik az elején, de ennél a függvénynél elméletileg még az sem okoz problémát, ha egyáltalán nem hívod meg. A default implementáció csak a view-k többségének adatát menti el.
(#4936) dunc: az adb az sdk része, ami felmegy a nagyobb rendszerekre. Így én ennyiből sajnos nem igazán értem, mit szeretnél (és hogy miért, mi lenne a cél).
-
thiclyoon
aktív tag
válasz Ablakos #4940 üzenetére
Most frissítettem 3.6.2-re:
Support for Jetpack View Binding, a compile-time safe replacement for 'findViewById()'
Illetve a frissítés utáni What's new?-ban is reklámozzák. Amúgy van létjogosultsága? ButterKnife eddig is nagyon szépen tudott ilyeneket, de Kotlin óta még arra sincs szükség.Canary-ból pedig én 4.1-re tudnék frissíteni, tehát a stable és a canary nem ugyanott tart szerintem.
[ Szerkesztve ]
-
thiclyoon
aktív tag
válasz bandi0000 #4942 üzenetére
Activity-ben ?. operátor nélkül is működik, fragment-ben szükséges a ?. operátor. Alapesetben nem lehet null, de ha pl. átmegyünk valamilyen Settings, vagy Helper osztályba, akkor egy rossz architektúra / tervezés után simán jöhetnek a null pointer hibák ilyen esetben.
Jó megoldás? Nem igazán van, illetve én nem tudok róla Nemrég láttam egy meme-t, ahol az volt a poén fő eleme, hogy mégis mi a fenének kell akár egy Toast-hoz context. Teljesen felesleges, ez az Android dizájn hibája, egyszerűen csak azt akarjuk, hogy jelenjen meg az aktuális képernyőn. Ha mégis szükséges egy context, vagy hasonló komponens (resource, activity, vagy akár teljesen más is, asynctask, stb.), akkor ezt javaslom, ez működni fog: [link] (kiegészíthető get/set-tel, egyéb dolgokkal, stb). Widget-nél tud ez is probléma lenni, de akkor kell a jó tervezés - vagy egy kis szenvedés a widget-nél -
thiclyoon
aktív tag
válasz bandi0000 #4944 üzenetére
Pont nemrég kellett használnom Bottom Navigation-t, és én is másképp emlékeztem rá
Szerintem megéri ezt az új megközelítést használni. Nekem különösen a navigation res mappa tartalma tetszik, hasonlít az iOS-hezHa jól értem, az a kérdés, hogy hogyan adjunk hozzá még egy fragment-et a bottom navbar-hoz:
0. Activity létrehozása
1. res/menu/bottom_nav_menu-ben az elemek módosítása (adjunk hozzá egy navigation_blank id-jű item-et)
2. res/navigation/mobile_navigation-ben a felső sorban "new destination" (create new, BlankFragment)
3. MainActivity-ben az AppBarConfiguration-hoz adjuk hozzá 4. elemnek az R.id.navigation_blank-et
4. res/navigation/mobile_navigation-ben a létrehozott destination id-ja legyen navigation_blank
5. futtatás után ott az elvárt kimenet -
thiclyoon
aktív tag
válasz bandi0000 #4946 üzenetére
Ahogy mondani szokták, a jelenlegi megoldás szuboptimális, de működik. Biztos van szebb, egyszerűbb megoldása is Ezekkel a kódokkal a home-ban a text-re kattinva lecseréli a notification fragment-re, majd a dashboard-ra nyomva kicseréli a dashboard-ra (ahogy várnánk). A többi feladat megoldását (pl. home-ra visszanyomásra mi történjen) az olvasóra bízom
MainActivity.kt-ba
interface MyListener {
fun clicked()
fun declicked()
}
class MainActivity : AppCompatActivity(), MyListener {
...
override fun clicked() {
val transaction: FragmentTransaction = supportFragmentManager.beginTransaction()
transaction.replace(R.id.nav_host_fragment, NotificationsFragment())
transaction.commit()
}
override fun declicked() {
val transaction: FragmentTransaction = supportFragmentManager.beginTransaction()
transaction.replace(R.id.nav_host_fragment, DashboardFragment())
transaction.commit()
}
}HomeFragment-be:
override fun onCreateView(...): View? {
...
textView.setOnClickListener {
(activity as MyListener).clicked()
}
...
}DashboardFragment-be:
override fun onCreateView(...): View? {
...
textView.setOnClickListener {
(activity as MyListener).declicked()
}
...
}És hogy lásd a változást, res/layout/fragment_notification-be:
<androidx.constraintlayout.widget.ConstraintLayout
...
android:background="#CA1414"
tools:context=".ui.notifications.NotificationsFragment">Illetve a res/layout/fragment_dashboard-ba:
<androidx.constraintlayout.widget.ConstraintLayout
...
android:background="#066EFF"
tools:context=".ui.dashboard.DashboardFragment">[ Szerkesztve ]
-
thiclyoon
aktív tag
válasz bandi0000 #4950 üzenetére
Igen, valószínűleg ez a statikus fragment-ek miatt nem működik. Végszükség esetére a fragment váltás után (még a fragment-ben) a dolgok visibility-jét átállíthatod gone-ra. De a csúnya kódok elkerülés érdekében én inkább a sima régi módszernél maradnék. Esetleg egy új activity-t is nyithatsz neki, és akkor minden tuti, még a megjelenést (mármint az animációt, gondolom emiatt is szeretnéd a fragment cserét) is testre tudod szabni
-
thiclyoon
aktív tag
válasz Ablakos #4953 üzenetére
A setStyle()-lal próbáltad átállítani
STYLE_NORMAL
-ra?[ Szerkesztve ]
-
thiclyoon
aktív tag
válasz Ablakos #4958 üzenetére
A 0.7 az egy jó 6-7 éves verzió én szeretem uptodate tartani azt is, meg a függőségeket is. Igaz, hogy egy-egy főverzió el tudja rontani a már kész alkalmazást (ilyenkor maradok a régebbi, jól működő verziónál), de általában vannak javítások, fejlesztések, amik miatt megéri. Azt nem tudom, hogy a gradle vagy az android studio miatt, de a build egy ideje egyre gyorsabb - már csak emiatt is megérheti újabbat használni / kipróbálni.
-
thiclyoon
aktív tag
válasz Ablakos #4960 üzenetére
Én se tudok konkrét dátumról, valószínűleg nincs is, és jó ideig nem is lesz szerintem rengeteg app java-t használ (még), nem akar minden fejlesztőt elveszíteni a google. Én is a kotlint javaslom - legyen a fejlesztő bármilyen szinten -, sok-sok előnye van.
(#4961) bandi0000: ha minden optional, akkor bármi lehet null
-
thiclyoon
aktív tag
válasz Ablakos #4969 üzenetére
Studio 3.6.3, valós eszközön elindítva egy projektet és utána a profile-t megnyitva ez jön elő egy pár másodperces várakozás után: [link]
3.0+ Studio és 5.0+ android kell hozzá (21-es api), lehet ez a gond? (A képen látszik is, hogy van, amihez még nagyobb api kell.)[ Szerkesztve ]
-
thiclyoon
aktív tag
válasz Ablakos #4972 üzenetére
A kód jó valószínűleg a gond az android api miatt van: "If your app targets Android 8.0 or higher, you cannot use the manifest to declare a receiver for most implicit broadcasts (broadcasts that don't target your app specifically)" [link]
Ha a kódot így szeretnéd ellenőrizni, akkor a module szintű build.gradle targetSdkVersion-jét vedd kisebbre (pl. 22), és egy ugyanilyen api-val rendelkező emulátoron teszeld. Viszont éles projekt, stb. esetén tedd is vissza a target-et, és próbáld meg kódból (manifest-ből töröld a kódodat):
val intentFilter = IntentFilter("android.intent.action.AIRPLANE_MODE")
val receiver: BroadcastReceiver = object : BroadcastReceiver() {
override fun onReceive(context: Context?, intent: Intent?) {
Toast.makeText(this@MainActivity, "changed", Toast.LENGTH_SHORT).show()
}
}
this.registerReceiver(receiver, intentFilter)[ Szerkesztve ]
-
-
thiclyoon
aktív tag
-
thiclyoon
aktív tag
válasz bandi0000 #4980 üzenetére
Ilyen esetben én a dialogot jobban preferálom. A fragmentcsere is hasznos tud lenni, de szerintem kevés esetben hasznos / szép / illik az alkalmazásba. A dialog cancel + ok gombokkal szerintem erre teljesen oké, mikor csak egy megerősítés szükséges. Komplexebb esetben, mikor például nem minden fér el szépen egy dialogban, akkor érdemes lehet átgondolni a fragment-cserét is persze, nem kell mindenáron mindent belezsúfolni egy dialogba.
-
thiclyoon
aktív tag
válasz Ablakos #4982 üzenetére
Érdemes először megnézni a fragment életciklust, itt látszik, hogy gyanús az az onSaveInstanceState() függvény például. Ez működni szokott, ha pedig valamilyen speciális helyzetben próbálod megoldani, akkor érdemes betenni ide a már elkészült kód releváns részét, akkor könnyebben tud bárki segíteni.
-
thiclyoon
aktív tag
A permission-ök sosem voltak a kedvenceim, sok boilerplate kód a kb. semmiért. Nem akartam átírni ilyen szinten a kódod, mert lehet, hogy csak összezavartalak volna vele. Ha érdekel, külső könyvtár permission-ökhöz, ami számomra bevált: [link].
Itt pedig a működő verziójú Activity: [link]. A telepítés után egyből nullpointer exception fogadott. Ezek elkerülésére tökéletes a kotlin, szintén csak ajánlani tudom. A térkép betöltése viszont kissé lassú, ez ilyen sajnos..[ Szerkesztve ]
-
thiclyoon
aktív tag
válasz Ablakos #5006 üzenetére
.xml-ben számít, hogy mit mi után hozol létre, és ha így hagyod, ahogy írtad, akkor a WebView előrébb lesz, mint a ProgressBar.
<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:app="http://schemas.android.com/apk/res-auto"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
tools:context=".MainActivity">
<TextView
android:id="@+id/tvText"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="WebView!"
android:textSize="30sp"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintTop_toTopOf="parent" />
<WebView
android:id="@+id/webView"
android:layout_width="match_parent"
android:layout_height="0dp"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintLeft_toLeftOf="parent"
app:layout_constraintRight_toRightOf="parent"
app:layout_constraintTop_toBottomOf="@+id/tvText">
</WebView>
<ProgressBar
android:id="@+id/prgBar"
android:layout_width="match_parent"
android:layout_height="wrap_content"
app:layout_constraintBottom_toBottomOf="parent"
app:layout_constraintTop_toBottomOf="@+id/tvText" />
</androidx.constraintlayout.widget.ConstraintLayout> -
thiclyoon
aktív tag
-
thiclyoon
aktív tag
válasz Ablakos #5010 üzenetére
Igazából a JetPack az csak egy official gyűjtemény, hogy milyen komponenseket érdemes használni. Szóval nem csak kotlinnal megy, de pl. az android ktx-nek szerintem nem sok értelme van java-ban. Amúgy a java és kotlin oda-vissza hívható, tehát hogy egy külső könyvtár (pl. a room, amit a jetpack perzisztenciára ajánl) miben van írva, nem számít.
-
thiclyoon
aktív tag
Másképp:
if (v.getClass().equals(Button.class)) { ... }
Talán elegánsabban meg Tag-ekkel lehet megoldani (.setTag(...), .getTag()
). Az OO egyik sarkalatos pontja, hogy "Subtyping – a form of polymorphism – is when calling code can be agnostic as to which class in the supported hierarchy it is operating on – the parent class or one of its descendants."[ Szerkesztve ]
-
thiclyoon
aktív tag
válasz Ablakos #5017 üzenetére
Főként a Sketch-t javaslom kipróbálni (fizetős, trial van, csak Mac, de nagyon jó), esetleg Adobe XD-t (ingyenes, Win / Mac-re tuti van, ez nem annyira profi). Vannak, akik a JustInMind-ot használják, én ezt valahogy nagyon nem szerettem meg. A Balsamiq-t nem használtam még, nem tűnik rossznak így elsőre.
-
thiclyoon
aktív tag
válasz lanszelot #5031 üzenetére
Én udemy-ben eddig ritkán csalódtam, bár az igaz, hogy én ott java-ban tanultam meg és később tértem át kotlin-ra.
Fizetős, magyar, aktuális kurzus: [link] Nem reklám, de szerintem ezzel nem igazán tudsz mellélőni, teljesen kezdő szint (akár az alapozó kurzussal kiegészítve). Találhatsz róla 2-3 bemutatkozós videót is. Bár igaz, az ára húzós lehet (a "Több pénzt nem akarok a semmire kidobni."-t én úgy értettem, hogy "feleslegesen kidobni"), hiszen egy udemy kurzus többszöröséről van szó. Viszont magyar, konzultálni lehet vele, stb. (Az oktatót személyesen ismerem, és meg tudom erősíteni, hogy az oktatási stílusa kiváló, android témában pedig szerintem nagyon toppon van. Olvass utána nyugodtan, pl. markmyprofessor-on rengeteg véleményt találsz róla. Két egyetemen is tanít, mellette IT vezető is egy cégben, ezzel foglalkozik gyakorlatilag azóta, amióta van android.)
Ha az ingyenesség a fő szempont, akkor viszont youtube, dokumentációk, stackoverflow (és rengeteg idő), viszont ha nem vagy gyakorlott, elég nehezen fog menni, ami elveheti a kedved. Így ha a programozás sem megy (számomra ez nem derült ki a hozzászólásodból), akkor érdemes lehet egy stabil alapot szerezni java / kotlin-ból android nélkül, és csak utána építkezni ezekre. A két nyelv amúgy teljesen hasonló.
(Youtube-on belül nem tudok konkrétabbat mondani sajnos, hiszen rengeteg videó van, elég sok 5+ órás és hasonlók, nyilvánvalóan ezeket nem néztem végig.)
Nagyon off: a programozói tool-ok iszonyat gyorsan fejlődnek és alakulnak át, teljesen természetes szerintem, hogy egy pipa máshova kerül, vagy hasonlók. Nemrég jött ki az android studio 4.0, ami egy főfrissítés volt, így az újdonságokból még több van, mint általában. Van ennél rosszabb is: swift-ben például a nyelv két változata sem kompatibilis egymással. /Nagyon off vége.
[ Szerkesztve ]
-
thiclyoon
aktív tag
válasz Ablakos #5039 üzenetére
[java vs kotlin] már csak emiatt is a kotlint pártolom, akár kezdő, akár haladó (szerintem többet ér megtanulni egy új, modern, fejlődő nyelvet, mint a kényelmesség miatt a java-nál maradni). Nekem elég lett volna csak a null-safety, szerintem már ez is hatalmas előny. A google már bő egy éve is azt kommunikálta amúgy, hogy ha új projektet kezd valaki, kotlinban kellene tegye.
Mivel a kotlin és a java egymással is tud kommunikálni, így ahol a java fut, ott kotlin is tud ([ref]), így én nem látom, miért lenne használható a java több helyen, de meggyőzhető vagyok, ha van erre valamilyen megalapozott állítás
[ Szerkesztve ]
-
thiclyoon
aktív tag
válasz bandi0000 #5057 üzenetére
Valószínűleg senkit se érdekel, és senki se foglalkozik vele, de mai napig így tanítják: függvény / function: egy programrész, melynek (többek között) van visszatérési értéke. Metódus / method: egy programrész, melynek nincsen visszatérési értéke. (Csak a különbséget emeltem ki, természetesen több tulajdonságuk van még, de ez tér el.)
Kotlinban ez érdekes kérdés, mert gyakorlatilag minden függvény/metódus igazából függvény (a fenti definíció alapján), hiszen mindegyiknek van visszatérési értéke (ha nincs jelölve explicit, akkor Unit, de ezt ki is lehet írni).
Kotlinhoz általánosságban: én nagyon szeretem a nyelvet (talán mert nagyon hasonlít a swift-hez), ha komolyabb kérdés van, beszállok a "vitákba" ha van időm de nem nyelv- vagy alkalmazási terület (jelen esetben android) specifikus részeket szerintem teljesen felesleges itt tárgyalni. Ha valaki nincs tisztába legalább az OOP alapjaival (pl. nem tudja, mi az hogy öröklés, implementálás), akkor szvsz felesleges elkezdeni az androidot mert nem sok esély van rá hogy megtanulja alkalmazni így hirtelen, egyből. Nem bántásképp, hiszen én pont így kezdtem (aztán 1-2 év múlva újra elővettem, több tudással), szóval ismerem a helyzetet
-
thiclyoon
aktív tag
Tettem fel nemrégiben többször is. A jelenlegi változatban* nekem egy dolog nem ment simán, ez pedig az in-app purchase. Kicsit szenvedős volt rájönni, hogy a reklám azért nem megy, mert nincs hozzáadva kifizetési számla - ezt is meg kellett találni, hogy hol is kell. + Az első kiadáskor sok dolgon át kell menni (tartalombesorolás, képek, leírás, stb). Illetve minden kiadás review-n megy át, ez jelenleg a vírus miatt akár egy hétig is eltarthat, viszont ha nem első kiadás, hanem csak frissítés, akkor még most is megvan 2 nap alatt az átfutás.
Úgy általában érvényes viszont hogy ha nem csak fel akarod rakni, hanem testre akarod szabni az egészet, pl korlátozni az elérhetőséget (ország, eszköz), vagy alfa / béta kiadások is kellenek, esetleg instant app, akkor ezekre mindre figyelni kell. Nem nehéz őket kezelni, csak figyelni kell rájuk.* November elején átalakul az oldal, de már most is lehet váltani. Megnéztem az új verziót, igazából csak a dizájn változott, material / flat lett az egész oldal. Szerintem szebb, könnyebben kezelhető, szóval lehet érdemes már az elejétől ezzel kezdeni, hiszen bő egy hónap múlva úgyis váltani kellene.
-
thiclyoon
aktív tag
válasz inf3rno #5167 üzenetére
Teljesen ingyenes [letöltés]
-
thiclyoon
aktív tag
-
thiclyoon
aktív tag
válasz inf3rno #5178 üzenetére
Hogyan próbálod telepíteni? Android studio-ból, kvázi valós eszközön debugolás-szerűen, vagy csinálsz egy .apk-t, és azt rakod rá, és telepíted valami fájlkezelőből? (utóbbi esetben szerintem kell aláírás, de a nevével ellentétben ez annyi, hogy csinálsz egy kulcsot, és signed apk-ként buildeled)
-
thiclyoon
aktív tag
válasz bandi0000 #5200 üzenetére
A leírás alapján nem kellene gond legyen, esetleg megpróbálhatod egy erősebb windowsos gépen emulátoron (vagy macen, talán még jobban is megy ezeken) hogy ott is csinálja-e. Én sokáig pl egy már korosodó snapi 625-tel teszteltem, viszont akkor sem tapasztaltam ilyet, komplexebb UI-jal sem. A betöltés után is akadozik a felület? Ha nem, akkor szerintem nincs gond, ha igen akkor viszont valami tényleg félremehetett. Ha gondolod átdobhatod a kódot (ha elég kis részlettel reprodukálható akkor akár ide is beteheted) hogy ránézhessünk mi a helyzet
#5201:
Nem teljesen tiszta, hogy mi a cél: ha csak segítség kell, akkor ide szerintem nyugodtan leírhatod a problémát, ami éppen szembejön. Ha viszont nincs rá időd, akkor ez egy mikro-fizetős projektnek néz ki: a .net kód bonyolultságától függően dobhatsz egy pm-et (c# nyelvvel foglalkoztam régebben, ma már nem), viszont időszűke miatt nem ígérem hogy tudok segíteni -
thiclyoon
aktív tag
válasz bandi0000 #5203 üzenetére
Több osztály is hiányzik, a build.gradle sincs meg, így nem tudom reprodukálni a dolgot. [stackoverflow: How to create a Minimal, Reproducible Example]: a lényeg hogy egy olyan kódot érdemes összerakni, ami a legkisebb akadályt gördíti a megoldáshoz vezető útra - engem pl nem zavar annyira ha nem minimális a példa, de szerintem senki se szeretne a hiányzó importokkal szöszölni stb. Nem tudom miért nem akartad az egészet feltenni, ha céges / egyéb privacy van akkor nyilván azokat a részeket vedd ki, de a kód fusson, mockolt adatok, átírt package név stb., ez elég egyszerűen kiküszöböli a fentieket. Az Android Studio ad erre egy egygombos megoldást: File - Manage IDE Settings - Export to Zip file..., vagy keresőben (shift-shift-tel előhozható) egy keresés az "export"-ra. Ez elméletileg kiszedi az ideiglenes fájlokat, outputot ilyesmiket (utána teszt hogy a kiadott zip tartalma fut-e nálad, előhozza-e a hibát). Persze ha más ennyiből megmondja a tutit, én nem állok az útba Illetve no offense, talán nem hallottad még, ezért írom le: bármilyen programozásról van szó, .docx-et nem illik ilyen célra használni, .txt vagy a kód alapértelmezett kiterjesztése (jelen esetben .kt, .xml) is jó, ezeket mindet tudja olvasni a legegyszerűbb szövegszerkesztő is
-
thiclyoon
aktív tag
válasz bandi0000 #5207 üzenetére
nem nagyon, de módosított fájl
Így már nálam jobb a helyzet, viszont eszembejutott a tesztelés közben, hogy nem is igazán tudom milyen fokú lassúság elfogadható androidon, így kicsit nehezebb volt amit még észrevettem az a .clone() használata, két okból is:
- éles kódban szinte sosem találkoztam még a használatával, valamint
- a calendar egy "nagyobb" objektum (nem performance vagy fizikai nagyság, hanem "sok dolgot tud ahhoz képest, hogy egy cellának odaadod"), így elméletileg szerintem az egyes celláknak nem kellene megkapniuk az egész calendar objektumot, nincs hozzá közük. Így a clone kivehető lenne, ami szerintem egy jó irány lehet: [link]. Ehhez nyilván már az .xml-ben és egyéb .kt fájlokban is át kell írni dolgokat, ezt valószínűleg te jobban átlátod, könnyebben meg tudod csinálni (a módosított fájlban elvileg semmi nem tört el, de erre is ugyanez igaz). A .clone kivételével nálam még jobb lett a helyzet (persze cserébe kb az egész eltört, mivel a napokat nem tudta kiírni rendesen, ezért kell ez a több fájlt érintő átírás) -
thiclyoon
aktív tag
válasz [KgP].Robot #5229 üzenetére
És a telefonban kell legyen sim kártya is (redmi note 4 tapasztalat)
-
thiclyoon
aktív tag
válasz kornyiktamas #5242 üzenetére
Mennyire perzisztensen akarod tárolni az adatokat?
- ha nem kell őket később módosítani (a felhasználó szemszögéből), akkor lehet, hogy a legegyszerűbb egy kódban megadott "adatbázis",
- ha kellhet őket módosítgatni, vagy sok adatról van szó, akkor egy lokális adatbázis lehet a társad, pl. a Room-mal meg tudod oldani szépen,
- ha pedig módosítani is kellhet őket, vagy sok adatról van szó, és még internettel más eszközről is elérhető kell legyen (tipikusan egy többfelhasználós alkalmazás), akkor pedig egy szerveroldali megoldás kell. Ezt vagy egy backendes programozó tudja megoldani (Java, .Net vagy valami hasonló nyelven), vagy ha a projekt nagysága nem indokolja, akkor a Firebase lehet a legkönnyebb megoldás.Ha a fentit el tudod dönteni, akkor a formátum is adott nagyjából: az első esetben egy kódban megadott változó lesz a megoldás, a másodikban szintén, csak a Room-mal kiegészítve, a harmadikban pedig a szerveren nosql-lel lesz kezelve, te pedig a Firebase-zel eléred. Ha az adatbázis felépítése a kérdés, akkor szintén sorrendben: valamilyen kulccsal rendelkező megközelítés; a Room esetében a könyvtár leírása fog segíteni, a Firebase-nél pedig érdemes rendesen átgondolni, mivel a túl sok lekérdezés fizetőssé fogja tenni ezt a megoldást. Egy jó felépítés sokat tud segíteni, ezen érdemes sokat gondolkozni ha idejutsz.
A többi kérdést nem igazán értem, nincs mit tagolni az adatokon, egyszerűen a query amit futtatsz az adatbázison az megadja, hogy milyen változókat tudsz kiírni. Ezeket "transzformálod" egy kiírható formátumban, és ezt meg tudod jeleníteni az appban. Külön feltöltés nem tudom, mihez kellhet - ha az adatok nem módosulnak, akkor elég egyszer, ha pedig módosulnak, akkor minek feltölteni őket többször?
Nem bonyolult, főképp ha az első, legegyszerűbb megoldás elég. Nem az a legszebb megoldás az biztos, de az egyszerűsége miatt megér(t) egy gondolatot.
-
thiclyoon
aktív tag
válasz robi212 #5268 üzenetére
[link] , [link] , [link]
"By default, the iOS allows character limit anywhere between 150 – 230 characters and Android notification tray allows anywhere between 450 – 650 characters. However, if you wish to get the best response to your push notifications, we strongly recommend a message which is not longer than 40 – 50 characters. [...] Essentially, keep the length of your push notifications short."Én már iOS oldalról vagyok (nincs aktív iOS topik itt tudtommal, sajnos), szóval ebben tudok segíteni (vagy ha van konkrét Android projekt, akkor azt tudom tesztelni, de magamtól nem írok ilyeneket már), szóval innentől minden iOS-re vonatkozik. Hivatalos leírás: [link]. Röviden ez annyit jelent, hogy by default 1-1 sornyi title-subtitle (általában csak az egyiket használjuk), és 2-4 sornyi description lehet. Az, hogy ez karakterszámban mennyi, az eszközfüggő - a két véglet, amit a többség támogat, az a régebbi iPhone SE, és a legnagyobb eszköz (most éppen azt hiszem iPhone 12 Pro Max). Ehhez nem árt, ha van nálatok konkrét eszköz, egy kb. közepes telefon (iPhone SE 2) esetén 1 sor kb. 45 karakter, és 3 sort gond nélkül kiír egyből. Tableten megint más a helyzet nyilvánvalóan.
Ez a standard működés. Kis pluszmunkával bármilyen értesítés elkészíthető (ugyanaz a komponens kell hozzá, mint egy képernyőhöz, UIViewController, a fejlesztők tudni fogják miről van szó), lásd pl. [link], itt mozgás közben is láthatjátok. De ez fontos, hogy csak akkor fog előjönni, ha az user hosszan rányom - én mint aktív iOS használó felhasználói oldalról sosem, vagy csak a legritkább esetben nyomok rájuk hosszan. UX oldalról fontos lehet (esetleg lehet erre utalást tenni a kisebb állapotban lévő értesítésben, hogy kb "nyomj hosszan, ha látni akarsz valamit", de ilyet is ritkán láttam eddig Remélem valamennyit tudtam ASAP segíteni, ha van konkrét kérdés még / amit nem válaszoltam meg, írjátok meg, hátha akár én akár más tud még valamit mondani.
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Kormányok / autós szimulátorok topikja
- Azonnali VGA-s kérdések órája
- Akciókamerák
- exHWSW - Értünk mindenhez IS
- Okos Otthon / Smart Home
- Befutottak a Samsung 990 EVO Plus SSD-k
- Milyen okostelefont vegyek?
- Ukrajnai háború
- TCL LCD és LED TV-k
- "A homoszexualitás természetellenes" 😠
- További aktív témák...
- ASUS Vivobook 15X OLED M1503 - 15,6"OLED FHD - Ryzen 5-4600H - 16GB - 512GB - Win11 - 1 év garancia
- GAMER PC: i5-12400F/13600KF - RTX 3070 GDDR6 - 1TB-4TB NVMe SSD - 16/32GB DDR4 - GAR/SZÁMLA!!!
- Dell G15 Gamer laptop 15.6", NVIDIA GeForce RTX 3060, Intel Core i7
- Dell Latitude 5500 15,6", i5 8365U, 16GB RAM, jó akku, 27% ÁFÁS
- Samsung Galaxy A51 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen