Hirdetés
- Fotók, videók mobillal
- A piac legerősebb kameráját ígéri a Xiaomi 17 Ultra
- Samsung Galaxy S10e - esszenciális
- Poco F7 – bajnokesélyes
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Apple iPhone 17 - alap
- Az 5 legnagyobb bénázás a mobilpiacon idén
- Szívós, szép és kitartó az új OnePlus óra
- Magisk
- Milyen robotporszívót vegyek karácsonyra? (2025)
Új hozzászólás Aktív témák
-
Karma
félisten
válasz
[KgP].Robot
#4300
üzenetére
Ha megvan az APK, akkor meg tudod nézni a tanúsítvány ujjlenyomatát.
Ebből a válaszból idézve:
keytool -list -printcert -jarfile valami.apkkiírja az aláíró tanúsítvány adatait az APK-ból; másrészről akeytool -list -keystore valami.keystorekilistázza a keystore fájlban lévő összes tanúsítványt. A fingerprint alapján meg tudod találni a megfelelőt. -
Karma
félisten
válasz
[KgP].Robot
#4296
üzenetére
Az eredeti kulcs kell a frissítés publikálásához. Ha elveszne, akkor törölheted az alkalmazást és feltöltheted új azonosítóval maximum... Természetesen az Android Studioval is használható a régi kulcs.
-
Karma
félisten
Nem lenne semmivel se jobb úgy csinálni, sőt megkockáztatom, hogy katasztrofális lenne. Szerintem a mostani megközelítésed teljesen valid. Esetleg a háttérfrissítést is likvidálhatnád az activityből egy service-be.
Tutorialt nem tudok, de ha elágazás van előtted, akkor mindig menj abba az irányba, amivel közelíted a SOLID elveket – jelen esetben különösen a single responsibility legyen fókuszban. Az Activitynek bőven elég felelősség, hogy a fragmenteknek fészket rakjon.
-
Karma
félisten
Van egy pár megoldása a problémának, mint ahogy a Play Store-ban lévő alkalmazásokban láttad. Van, amelyik hanyagolja a layoutolást, helyette SurfaceView-n végez saját renderelést; van amelyik a RecyclerView-hoz ír saját LayoutManagert (a gyáriak nem elegek).
A probléma csak az, hogy az összes nagyságrendekkel bonyolultabb, mint hogy bárki meg akarná publikusan osztani, ingyen, amikor hónapokon át dolgoznak rajta. Na meg nem is biztos, hogy jogilag megtehetik.
-
Karma
félisten
Ez nem válasz arra az egyébként teljesen jogos kérdésre, hogy ezzel a borzalommal mit akarsz elérni. Már onnantól vérzik a téma, hogy kézzel indítgatsz Threadeket. Androidon erre csak nagyon speciális esetekben van szükség – és bármi amit az activitybe írnál, biztosan nem ilyen.
-
Karma
félisten
válasz
xridergabo
#3987
üzenetére
Ezt a buttonAddOnClick metódusodat mintha nem hívná semmi.
-
Karma
félisten
- Másik processz akkor tud csatlakozni a service-hez, ha ahhoz megadsz egy intent-filtert a manifestben. A package név önmagában nem elég. (Lehet vannak más feltételek is, még sose csináltam.)
- Hálózat és más oprendszer teljes mértékben kilőve, nem erre szolgál az IPC. Ha ilyet akarsz, használj rendes hálózatkezelést.
- A Service életciklusa nem azon múlik, hogy mihez kapcsolódik, hanem hogy hogyan indította el magát.Egész pontosan mit szeretnél elérni?
-
Karma
félisten
(és bucsupeti: ) Az AppCompatActivity bizony a v4 FragmentActivityből származik, úgyhogy ezzel nincs semmi probléma.
domel: Azzal hamarabb van baj, hogy a FragmentTransactionnek is van v4 support verziója, és nem ez van importálva a forrásfájl elején. Sajnos ezt elég hülyén oldották meg, oda kell figyelni, hogy minden Fragmenttel kapcsolatos osztály a support.v4-ből jöjjön.
Másrészt a container ID, amire a replace tranzakciót hívod, egy ViewGroupnak kell lennie (tipikusan FrameLayout), a TextView nem nyerő erre.
Harmadrészt választanod kell, az Activity vagy közvetlenül beágyaz egy Fragmentet a layoutban, vagy pedig tranzakciókat használ. A kettő egyszerre nem megy - ezt próbáltad most, ami ha lefordult volna, akkor is szétrobbanna. Szerintem a beágyazást kell hanyagolnod, tehát az activity_main.xml-ből vedd ki azt a <fragment> taget, tegyél be helyette egy FrameLayoutot, és futtass arra tranzakciót. Ez azért előnyösebb változat, mert layoutba ágyazásnál nem tudsz paramétereket átadni a Fragmentnek.
-
-
Karma
félisten
Jesszus!
A lehető legrosszabb megközelítés ez, ha valóban ezt ajánlják bármely fórumon, azt a helyet messze kerülni kell.Először is, ha UI szálon indítasz hálózati kérést, az felrobban NetworkOnMainThreadExceptionnel. Valószínűleg ez történik a telefonodon is. Miért nem nézed meg a hibaüzenetet, amit kiír a logba?
Másodszor, ha a fájlban az újsoroknak jelentősége van, akkor ez a fajta soronként beolvasás el fogja szúrni. Ezt mondjuk a kódrészetben látható komment is írja. Az esetek döntő többségében teljesen felesleges és primitív megoldás readLine()-t használni, amikor a streamet közvetlenül is fel lehet dolgozni.
Harmadrészt az URLConnection helyett vannak magasabb szintű könyvtárak, amikkel a szerverkommunikációt értelmes keretek közé lehet szorítani. Nekem a favoritom a Retrofit.
De ha ez még nagy falat lenne, javaslom a hivatalos dokumentációt.
-
Karma
félisten
válasz
SirRasor
#3851
üzenetére
A csomagot most nem tudom megnézni, de egy Service indításakor a START_STICKY konstans segítségével jelezheted, hogy folyamatosan akarod futtatni, függetlenül a hívó kliensektől.
-
Karma
félisten
válasz
SirRasor
#3827
üzenetére
Dehogy vették. Elég alapvető API-ról van szó az Android kezdetei óta. Most nézem a projekted, mindjárt kiderítem, miért sír az IDE. Mármint kideríteném, ha lenne benne Handler. Ez most (az egyébként teljesen inkorrekt) szálas verzió.
Egyébként simán megtalálta nekem mind a
Handlert, mind apostDelayed(Runnable, long)metódusát. Biztos, hogy azandroid.os.Handlert importáltad be? -
Karma
félisten
válasz
SirRasor
#3814
üzenetére
Természetesen natív Android fejlesztéshez Android Studiót. A Xamarin és a VS más történet (bár egyébként ha jól végzed a dolgod, a különböző felbontások és eszközök támogatása miatt ott is ugyanúgy belefutsz a többféle resource-ok kezelésébe).
Más komoly eszköz nincs, de nincs is rá szükség.
-
Karma
félisten
válasz
[KgP].Robot
#3760
üzenetére
A szükséges szerveroldalt is neked kell előállítani hozzá? Szabad kezed van, vagy van technológiai megkötés? Netalán lehet felhőmegoldásokat használni rá? Mert a real-time követéshez például a Firebase egy elég fain megoldási lehetőség lenne.
-
Karma
félisten
válasz
[KgP].Robot
#3756
üzenetére
A képbetöltés az a probléma, amit nem szabad elkezdeni magadtól megírni, amikor rengeteg kulcsrakész lib van hozzá: Picasso, Fresco,
UniversalImageLoader; csak hogy hármat felsoroljak. Ezek mind megoldják helyetted az átméretezést, háttérszálak helyes kezelését, cache-elést!, stb.Szerk.: Az UIL-t kihúztam, mert már nem támogatja a fejlesztője. Javaslom a Picassót, pofonegyszerű használni.
vlevi: Ez az állításod a mezei ListView-ra is igaz.
-
Karma
félisten
Nem vagyok jogász, de azért tanultam a kérdésről anno valamennyit.
Nem akarlak elkeseríteni nagyon, de az ötlet önmagában semmit nem ér, bármennyire jónak is gondolod. Nem is tudod sehova rakni, maximum papírra vetni, másoknak elmondani, vagy véghezvinni.
Levédetni nevet, megjelenést lehet (ld. védjegy); illetve ha már megvalósítottad, akkor lehet szabadalmaztatni az implementációt.
Egy fejlesztési munka nem csak programozói munkából áll. Kell legalább egy designer is. A (min.) három ember között a kommunikációt meg kell szervezni. Adózásilag is rendben kell lennie a dolgoknak. Szóval nem egy embert kell keresned, hanem inkább egy csapatot, aki látott már ilyet a valóságban. (De persze vannak rocksztárok is.)
Pénzben pedig nyugodtan kezdheted betárazni a százezreket. Minél nagyobb a projekt, minél több mozgó alkatrész van benne (főleg szerveroldalon bonyolodhat el), annál többet. sztanozs összefoglalója tökéletes, és hangsúlyoznám én is, hogy ezek a napidíjak.
-
Karma
félisten
válasz
sztanozs
#3731
üzenetére
Ez szerintem egy remek ötlet. Rádobva egy Mosquitto-t (OpenWRT-re van csomag) kész is a bróker

-
Karma
félisten
Ez a szerver egyébként szintén egy Android alkalmazás, vagy valami rendes szerver?
1) A bróker olyan szerver, aminek a feladata az, hogy üzeneteket továbbítson, egy-egy vagy egy-több kliense között. Más szóval pontosan arra jó, amire neked kell: egy "topik", amire feliratkozik minden telefon, a bróker pedig szétküldi mindenkinek.
Van rá jópár protokoll és lib. Például ha Node szervered van, a Socket.io-val websocket alapon elég egyszerű. Meg ott van az MQTT protokoll (és például a Paho, mint implementáció), amit a mostanában trendi IOT világhoz találtak ki - ennek megvan az az előnye, hogy a QoS segítségével különböző kézbesítési szinteket állíthatsz be, és még csak gondolkodnod se kell rajta.
2) A dedikálás nem egy technikai dolog ebben az esetben, inkább filozófiai. Ha van egy szervered, aki elkülönül a kliensektől, bizonyos értelemben dedikált funkcióval bír.
3) Az androidos megoldáshoz szerintem a hivatalos doksi elég beszédes: Service Discovery. De nem muszáj ágyúval verébre lőni, azt is játszhatod, hogy fix IP-t adsz a szervernek és a kliensek ehhez csatlakoznak.
-
Karma
félisten
Szerintem teljesen rossz irányba indultál el, mikor azt gondoltad, hogy az UDP felhasználásával, a lehető legnaívabb megközelítéssel, majd siker lesz a vége a véres küzdelemnek.
Ez most P2P hálózat akar lenni, amiben mindenki küldhet broadcast üzenetet, bármikor? Muszáj ezt így? Nem lehetne dedikálni egy brókert a hálózaton, amin keresztül mindenki kommunikálhat? Ha egy hálózaton van mindenki, service discovery-vel megtalálhatják a szervert, és akkor már használhatsz TCP-t, vagy neadjisten magasabb szintű protokollokat.
-
Karma
félisten
válasz
catalisat
#3723
üzenetére
Például a "Facebook chat heads" egy remek keresőszó, ha már hasonló dolgot akarsz csinálni. Itt meg az első találat, amiben látszik, hogy a WindowManager lesz a barátod az ügyben.
-
Karma
félisten
válasz
Nestor16
#3720
üzenetére
Ha folyamatosan akarsz scannelmi, akkor a broadcastreceivered indítsa újra a scannelést (ott hívd meg a atartScant újra). Ha a háttérben is akarod meríteni a telefont, akkor ezt a logikát egy Service-be tedd bele. (Az Intent nem komponens.)
sztanozs: Valóban; gyakori, komoly és kritikusan fontos probléma. De még olyat nem láttam eddig, hogy négy különböző aszinkron eszköz egymásra lapátolva még palacsintának is sok.
-
Karma
félisten
válasz
[KgP].Robot
#3717
üzenetére
Dzsesszus! Mi akar ez lenni?
A hiba elég egyértelmű, egy AsyncTask doInBackground metódusában (ami elég beszédes, hogy háttérszálon fut), piszkálsz egy UI elemet. Ez nyilván tilos és az exception ezt is mondja neked.
Viszont mielőtt beírsz még valamit, hogy a UI szálra térjen vissza a lekérdezés, inkább töröld ki az egészet a francba. Ha csak késleltetni akarsz valamit UI szálon, oldd meg egy darab Runnable + Handler.postDelayeddel, mint ahogy egyébként ennek a halálpiramisnak a közepén tetted. Nincs szükség se AsyncTaskra, se runOnUiThreadre, se ennyi sorra.
...Most látom csak, hogy a piramis után ezt az egészet pont ugyanúgy, postDelayeddel indítod el. Na, csak ez kell, az AsyncTaskot égesd el.
Nestor16: Mit jelent az, hogy "nem akar összejönni"? Ez a kiinduló kód elég korrekt.
-
Karma
félisten
válasz
WonderCSabo
#3700
üzenetére
4.4 után is működik ez? Mert ott azért eléggé megborultak a szabályok...
-
Karma
félisten
válasz
[KgP].Robot
#3694
üzenetére
-
Karma
félisten
válasz
[KgP].Robot
#3692
üzenetére
Egy nagyon súlyos hiba biztosan volt: idetettél egy kilométer forrást a Programkód formázás használata nélkül. Mondjuk ekkora mennyiséget még formázással együtt se dobj be kérlek a jövőben.
-
Karma
félisten
válasz
DrojDtroll
#3687
üzenetére
A hivatalos dokumentációban meg tudod nézni, hogy egyes API-k melyik verzióban jöttek be. A support libraryk ezt eléggé felborítják, rengeteg dolog visszavihető 2.3-ig (de miért tennél ilyet?).
-
Karma
félisten
válasz
DrojDtroll
#3683
üzenetére
Egyáltalán nem értek egyet az előző következtetéssel, a RenderScript-alapú megoldás elég hatékony.
Persze, egyszeri firka-alkalmazásnál eljátszható, hogy a képet különböző blur paraméterekkel legyártod, de egy valós alkalmazásnál (ahol például az alkalmazásodat felkészítetted mindenféle felbontásra és DPI-re) nem járja, hogy ilyen kombinációkkal hízlalod az APK-t gigászi méretekre.
Sok nagyméretű kép betöltögetése emellett memóriában is elég megterhelő, és egyáltalán nem gyors. Persze mindig az esethez mérlegelni kell, hogy mennyi fér bele. Ki kellene mérni és az alapján dönteni.
-
Karma
félisten
Kevéssé lepődtem meg, amikor olvastam a kérdésed. Mivel a konkrét forráskód ismerete nélkül nem lehet megoldani a helyzetet, pár ötletem van:
1) Az Android Studio által nyújtott eszközöket nézted már?
2) Használsz Bitmapeket? Mindenképpen hívj rajtuk .recycle()-t, miután végeztél a használatukkal, különben nem szabadul fel a terület.
3) Leállítasz, elengedsz mindent amikor elhagysz egy Activityt?
4) Használsz nem statikus osztályokat? Ezekkel pofon egyszerűen lehet leakelni Viewkat és kontextusokat, ugyanis a tartalmazó objektumra erős referenciát birtokolnak. Ha egy ilyen classt használsz listenernek valami külső osztálynál (például location figyelés), az egész pereputty nem tud felszabadulni. -
Karma
félisten
"Esetemben garantálva van, a felhasználó mindenképp visszatér a főképernyőre (nincs választása
)."Tán valami kiosk jellegű alkalmazás? Akkor se garantálja senki, különösen nem az Android, hogy ugyanazt az Activity példányt hozza vissza. Főleg ha közben történik egy újrakonfiguráció mondjuk elforgatás miatt (pl. kamera).
Az onResume meghívódik első induláskor és újrainduláskor is, remek hely az ilyen UI cuccok indítására.
-
Karma
félisten
Igen. Senki se garantálja, hogy valaha ide visszatér a felhasználó, a háttérszálak meg csak a processz kilövésekor állnak le.
Alapvetően sokkal jobban jársz, ha azokat a dolgokat, amik valódi háttérfolyamatok és nincs UI vonzata (pl. location), kiszervezed egy bound/hybrid service-be. A UI-osokat meg onPause-ban állítsd meg.
-
Karma
félisten
A legutolsó projektemben, ahol fényképet kellett készíteni, az alábbi kódot használtam (kicsit kipontozva a specifikus részeket):
Intent takePictureIntent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
File photoFile = new File(...);
if (takePictureIntent.resolveActivity(getPackageManager()) != null) {
takePictureIntent.putExtra(MediaStore.EXTRA_OUTPUT, Uri.fromFile(photoFile));
startActivityForResult(takePictureIntent, REQUEST_IMAGE_CAPTURE);
} else {
... // hibakezeles ha nincs kamera >_<
}...aztán onActivityResultban megjött a sikeres jelzés, én meg frissítettem a RecyclerView adapterét, és megjelent szépen a kép.
Mit csinál a kódod a fájllal közvetlenül visszatérés után?
-
Karma
félisten
Személy szerint nem erőltetném ezeket a proximity megoldásokat, inkább bevonnék egy Dropboxot vagy Google Drive-ot köztes tárolónak. Androidon a Google fiók elég gyakori, főleg Play Store-os alkalmazás esetén

Nem tudok róla sajnos, hogy a Google adna olyan egyszerű megoldást a szinkronizálásra, mint az iOS-en az iCloud Sync, Windowson meg a roaming settings... De szívesen venném, ha kijavítana valaki.
-
Karma
félisten
"Akkor a custom View osztályban lesz egy mHandler = new Handler(); rész. Ha jól értem, ez rácsatlakozik az UI thread által létrehozott looper-re."
Igen és igen.
Hogyan tudom ezt az egészet megállítani? Kiadok egy mHandler.removeCallbacks() utasítást?
Igen. Ha megnézed a metódus szignatúráját, láthatod, hogy meg kell adni azt a Runnable példányt, aminek az ütemezését vissza akarod vonni.
"1. De mi lesz ebben a runnable? Vagy egy runnable-vel meg tudom csinálni a fenti sort?"
Ha kicsit konkretizáltad volna, hogy mit csinál a View-d és miért kell hozzá két ütem, nem kellene ennyire a levegőbe beszélnünk. Mindenesetre az biztos, hogy a késleltetett kódrészlete(ke)t ki kell raknod tagváltozó(k)ba, mert így tudsz a konkrét Runnable példányokra hivatkozni - melyek egyébként tipikusan lambdák vagy anoním osztályok.
Például (kicsit pszeudokód lesz, mert most nincs előttem IDE):
private Handler mHandler = new Handler();
private Runnable mDelayedStep = new Runnable() {
public void run() {
Log.w(TAG, "BOOM!");
}
};
public boolean onTouch(View v, MotionEvent event) {
mHandler.removeCallbacks(mDelayedStep);
mHandler.postDelayed(mDelayedStep, 5000);
return true;
}És ezzel írtál is egy mini játékot, amiben akkor robban a bomba, ha a felhasználó öt másodpercig nem nyúl a telefonhoz
Amíg simogatja, elodázza a végzetét.Retrolambdával egyébként egy kicsit tömörebb:
private Runnable mDelayedStep = () -> Log.w(TAG, "BOOM!");2. Azonnal megáll a végrehajtás, vagy a következő "tick" még lefut?
Azonnal hat, tehát nem fog lefutni, amit kivettél.
3. Ha leállítom, akkor rögtön indíthatok egy ugyanilyen ütemet, ugyanezekkel a példányokkal?
Persze. Sőt, ha az lenne az igény, egy Runnable-t többször is beütemezhetsz, mert a message queue-ba többször is bekerülhet ugyanaz a példány. Fontos megjegyezni, hogy a removeCallbacks az összes hozzá tartozó üzenetet kiveszi.
-
Karma
félisten
Töröltem az utolsó hozzászólásokat, mert se a poltikai helyzet méltatása, se az adórendszer kijátszása nem a fórumra, de különösen nem egy szakmai topikba való téma.
-
Karma
félisten
válasz
Ricardo128
#3568
üzenetére
Íme, egyenesen a hivatalos oldal. Itt mindent megtalálsz.
-
Karma
félisten
válasz
Arcanus
#3547
üzenetére
Csak akkor az, ha a tényleges transzformációra fekete dobozként tekintesz. Én is így csináltam.
Szerintem fókuszálj a Recorder közepére alapvetően, a matekot meg valahol máshol nézd meg hozzá ha nagyon érdekel (jelek és rendszerek egyetemi jegyzet, stb), ne a forrást fejtsd vissza

-
Karma
félisten
válasz
Arcanus
#3543
üzenetére
Complex.java, FFT.java (ezeket így szedtem össze az internetről), Recorder.java (ezt pedig évekkel ezelőtt írtam).
Az utóbbiban van benne a lényegi logika. A 44-63. sor közötti részt eldobhatod, vagy adaptálhatod az igényedhez - az én feladatom az volt, hogy azt detektáljam, ha a 20KHz-es tartományban van sípolás. A lényeg, hogy az FFT eredményeképpen egy olyan Complex tömböt kapsz, amiben az egyes számok egy-egy frekvenciatartományt jelölnek, neked pedig ezen számok abszolút értékére lesz szükséged.
Garancia nincs.
-
Karma
félisten
válasz
bucsupeti
#3539
üzenetére
Egyszerű: felejtsd el, hogy olyat akarsz csináln, hogy valami szinkron módon fusson le a task végén. Azért async task. (Haha.) Legalább egy callback mintára szükséged lesz, vagy abuzálhatod az onPostExecute-ot.
A ProgressDialoghoz javaslok egy ProgressDialogFragmentet (sok implementációja előfordul a neten, megírni is könnyű), onPreExecute-ban fellövöd, a notifyProgressel frissítgeted, onPostExecute-ban pedig leveszed.
-
Karma
félisten
válasz
bucsupeti
#3528
üzenetére
Appot nem, de ha a Tesseractot integrálod, a hatás kb. ilyen lesz.
Mondjuk a telefonon offline OCR-ezni elég... érdekes megoldás, sokat javítana a vérnyomásodon már rövid távon is, ha vagy egy felhő-alapú megoldásra fizetnél be, vagy legalább szerveroldalon futtatnád a Tesseractot. Az utóbbi egyébként nagyságrendekkel könnyebb, mint Androidon a libeket forgácsolni.
-
Karma
félisten
Igen, pontosan ezt kellene csinálnod. Elvileg a Netbeans által futtatott WildFly is elérhető a helyi hálózaton, ha tudod melyik porton figyel a connectora. Aztán már csak egy webapp kell, ami az interfészt nyújtja - Spring Boot, RESTEasy, Restlet, nyers JAX-RS, van egy pár lehetőség.
-
Karma
félisten
Olyat nem fogsz csinálni. Bár technikailag meg lehet hackelni a Postgre JDBC drivert, hogy 17-es vagy annál nagyobb API levelen Androidon is menjen; alapjaiban hibás a gondolat.
Tegyél elé egy web service-t, amit hívogathat a kliensed (bármely nyelven meg lehet írni kvázi seperc alatt), és végezze az a nyers adatbázisműveleteket.
-
Karma
félisten
Így mindjárt érthető

Szerintem alapvetően a pullon nem lehet változtatni, hiszen a többi komponens leáll. El lehet viszont fedni, ha Ottót használsz, azon belül pedig a @Produce annotációt: a beállítások kezelését vidd ki egy started Service-be, az meg szórja ki a beállításokat a buszon keresztül.
-
Karma
félisten
Számomra se teljesen világos, hogy ezzel milyen valódi problémát készülsz megoldani (mert most is csak kifejtetted az implementációt, nem a szándékot mögötte); mindenesetre SharedPreferencesben tárolhatnál egy timestampet, amit az onResume-ban összevethetsz egy tagváltozóval - ha a prefben újabb van, akkor változott az adat => újratöltés.
-
Karma
félisten
válasz
Freeman007
#3501
üzenetére
Erre sajnos nincs lehetőség, a rendszer nem küld külön Intentet ebben a pillanatban a hívás állapotot figyelő alkalmazásoknak. Hogy a gyártók mit csinálnak a saját RIL-jükkel, az más - és sajnos irreleváns - kérdés.
-
Karma
félisten
válasz
WonderCSabo
#3489
üzenetére
Release módban én is így csinálom, de a debug keystore másfajta állat.
-
-
Karma
félisten
válasz
PumpkinSeed
#3483
üzenetére
Szerintem mindenképp nézz rá az általam előbb linkelt MapsForge-ra. Erre a feladatra teljesen jó lesz, az OSM adatbázist kell hozzá előfeldolgozni kicsit.
-
Karma
félisten
válasz
PumpkinSeed
#3481
üzenetére
Biztos jó a link? Ez az OpenStreetMap webes változatára mutat.
A hibákkal a térképadatbázisra gondolsz, vagy magára a megjelenítésre? Utóbbira én csak ezt használtam, ennek barátságos a licence és csak közepesen vállalhatatlan minőségű. Jót, ingyenesen eddig még nem láttam.
-
Karma
félisten
Nem elfogadták, hanem a kérdező egyszemélyben fogadta el a választ. Nem mindegy, mert egyáltalán nem biztos, hogy helyes is. Amellett, hogy 2010-ben készült, alapvetően elég súlyos hiba egy Contextre(*) static változóval hivatkozni, mert ezzel keresztülhúzod az életciklusát.
(*): Az Application egy kivétel ez alól, mert processzenként csak egy jön létre biztosan.
Ha a Service-ed példányával akarsz közvetlenül kommunikálni, akkor a Binder erre a megoldás, amit egyébként szintén pár sorral le lehet tudni. Még csak nem is agysebészet, kell egy Binder subclass, az onBind metódus a Service oldalon; egy ServiceConnection és a bindService/unbindService hívás az Activity oldalon.
Ha nem közvetlenül akarsz vele beszélni, akkor pedig ott vannak az Intentek és a BroadcastReceiverek - a Service is simán regisztrálhat egyet amikor életben van -; vagy Ottót ill. EventBust is használhatsz. Mondjuk csak ehhez a feladathoz overkill egy külső libet behozni.
vlevi: Egy kicsit összekeverted a dolgokat. Nem ezek a service-ek típusai.
1) Vannak a bound service-ek, amik ahogy írtad, a bindService hatására élednek, és leállnak amikor lecsatlakozott az utolsó kliens.
2) Vannak a started service-ek, amik egy startService(Intent) hatására indulnak; eldönthetik, hogy leállnak-e, futnak tovább, vagy úgy futnak tovább, hogy ha bármi miatt lehalnának, a rendszer akkor is indítsa vissza őket (sticky). Ettől független dolog az, hogy csak az alkalmazásodon belül, vagy kívülről is hívható-e (exported flag).
3) Vannak még hibrid service-ek, amik olyan startedek, amikre bindolni is lehet. Ez a billentyűzet történet szerintem ebbe a kategóriába kellene, hogy essen.
Az IntentService egy speciális started service ősosztály, ami arra szolgál, hogy egyszerűen tudj a háttérben végrehajtandó feladatokat sorban átadni neki, és majd leáll, amikor mindennel végzett. De ettől még nem lesz külön kategória.
-
Karma
félisten
válasz
#39560925
#3404
üzenetére
Szóltam neki, az appContextModule valószínűleg kimaradt és kiegészíti vele a guide-ot. "Jogos kritika", idézem. Hamarosan...
A második felére én is tudok reagálni: szerintem nem sérül az OOP ettől (hiszen az objektumod a külvilágtól várja a dependenciái érkezését), mondjuk igazából a public helyett a package private bőven elég a Daggernek is.
Ez az ára annak, hogy egyszerűbb az egész injektor, mint mondjuk a Springé. Például a ButterKnife is csak public vagy package private mezőkkel hajlandó foglalkozni, hogy spóroljon a reflexióval a generált kódban.
-
Karma
félisten
válasz
#39560925
#3400
üzenetére
Ez a guide (amit egyébként az öcsém írt, szóval ha van bármi kérdés, gyorsan tudom delegálni) az onCreate metódusban injektál mezőkbe. Ez a megközelítés szerintem Fragmentekkel ugyanúgy működhet.
-
Karma
félisten
válasz
aprokaroka87
#3380
üzenetére
A kérdésedet inkább a Tasker topikban tedd fel, kérlek.
-
Karma
félisten
válasz
automATIc
#3362
üzenetére
Kérlek legközelebb használd a Programkód formázást, vagy ilyen hosszú kódot inkább Pastebinre vagy más, hasonló szolgáltatásra másolj be. Az előbbit átformáztam, hogy mi is olvashassuk.
Egyébként van egy pár probléma a kóddal:
1) A showClick metódusodban az az if utáni pontosvessző nem kell oda, így most le se kéne fordulnia.
2) A fájlokat nem zárod be abban az esetben, ha valami hiba történne... Nézz utána a try-catch-finally-nek, és a finally blokkban zárd le a streameket.
3) Nem sok értelme van soronként felolvasni egy fájlt azért, hogy utána soronként beleformázd egy stringbe.Egyébként az eredeti kérdésedre egyszerű a válasz: a readMessage-et a másik Activitydbe kéne írni, nem ide

-
Karma
félisten
válasz
automATIc
#3360
üzenetére
Egy kicsit pontosítanod kell, mit csináltál eddig.
Például hogy érted azt, hogy "lementem a beírt karaktereket"?Ahhoz, hogy a másik Activityhez eljusson a szöveg, vagy az indításához használt Intentbe kell beírnod, mint egy String extrát; vagy pedig ki kell mentened valahova, és az új Activityben visszaolvasnod.
Mivel egy todo appnak csak akkor van értelme, ha a listát nem felejti el, triviálisan adja magát a második megközelítés. Mondjuk valószínűleg elég nagy falat az adattárolás, de valami adatbázisra lesz szükséged. Az új Activity meg megkapja azt az ID-t, ami alapján eléri az újonnan lementett bejegyzést.
-
Karma
félisten
Egynek a DreamFactory jutott eszembe, ez egy PHP-alapú szerver, ami próbálja általánosítani a backend feladatait. De csak arra keresve, hogy "Postgresql REST API", vannak még érdekes találatok: PostGrest például.
Ha meg saját fejlesztés kellene, a Spring Boottal, Spring Data JPA-val elég gyorsan ki lehet pörgetni egy jól működő backendet, biztonsággal meg alkalmazásszerverrel karöltve.
Viszont az általános Programozás topik, vagy választott technológia mentén valamelyik nyelvi topik jobb hely lenne a kérdésnek és/vagy a folytatásnak.
-
Karma
félisten
Az IEEE754 lebegőpontos számok már csak ilyenek, hja. A tízes számrendszerben leírható számok kettesben elég gyakran csak végtelen törtként írhatóak fel. Nem véletlenül szigorúan tilos bármilyen pénzügyi, vagy precíziót igénylő számításhoz használni.
Van helyette BigDecimal osztály, ami bár sokkal körülményesebb (immutable, és metódusokat kell hívni az operátorok helyett), mégis tökéletes pontosságot ad, használd azt.
A floatra castolást meg pláne felejtsd el, hacsak nem valami androidos API-nak kell floatot átadni.
---
Az SDK verziós kérdésre: a double működésében nem számít. A target SDK-t célszerű a legújabbon tartani, hogy az új telefonokon ne legyen gond (figyelmeztet is az IDE, ha le vagy maradva). A minimum pedig az, aminél régebbire fel se települhet az alkalmazásod.
Gyakorlatilag azokat az osztályokat használhatod gondtalanul, amik a min. SDK-ban már elérhetőek voltak. Ha nagyon muszáj, újabb rendszereken, verzióellenőrzésekkel körülvéve a target SDK-ból is hívhatsz dolgokat, de ezek a sorok felrobbannának régebbi telefonokon.
-
Karma
félisten
válasz
#39560925
#3342
üzenetére
Mi biztosan jobban tudjuk, mint a Google

Egyébként itt a kapcsolódó forráskód, ez biztosan nem hazudik. -
Karma
félisten
Az enumok memóriaigényéről nem tudok semmit (eredetileg az óva intésről se tudtam, én vígan használtam ha azt ítéltem a megfelelő eszköznek
).A képekkel valószínűleg szerencséd volt, vagy nem foglalnak annyit, mint gondoltad. Még mai eszközökön is jókora OOM pofonokat lehet kapni, ha mondjuk fényképeket olvas fel az ember sampling nélkül, és nem hív rájuk recycle-t.
A 16 MB-os korlát már nagyon régen volt egyébként, platformonként és eszközönként is ingadozik. Némi olvasnivalót találtam a témában SO-n: [link][link] Az utóbbiban van egy lista pár modern eszközről is, hogy hogyan alakultak a számok.
-
Karma
félisten
Mondjuk a Java enumoknak nem sok közük van a C-s formához, ahol nem volt több egy nevesített int konstansnál. Itt azért azáltal, hogy ezek singleton Java objektumok, amiknek saját metódusaik is lehetnek, sokkal vagányabb dolgokat össze lehet hozni. Például a Command GoF mintát elég triviális így megírni.
Hah, jó sokáig ültem a hozzászóláson.

-
Karma
félisten
válasz
bucsupeti
#3322
üzenetére
Még nem csináltam ilyet, de a CONNECTIVITY_ACTION broadcastet próbáltad már?
Új hozzászólás Aktív témák
- Könyvajánló
- PayPal
- OLED TV topic
- AliExpress tapasztalatok
- Milyen autót vegyek?
- Fotók, videók mobillal
- Fortnite - Battle Royale & Save the World (PC, XO, PS4, Switch, Mobil)
- A piac legerősebb kameráját ígéri a Xiaomi 17 Ultra
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- Kormányok / autós szimulátorok topikja
- További aktív témák...
- Szuper Akciós Ajánlat! Eredeti gyári Asus Rog és Rog Phone gamer kiegészítők új állapotban!
- Samsung S22+ 256 GB eladó (fekete)
- Apple iPhone 13 Pro Max 128GB, Kártyafüggetlen, 1 Év Garanciával
- Honor 90 Lite 256GB, Kártyafüggetlen, 1 Év Garanciával
- Samsung Galaxy S20 128GB, Kártyafüggetlen, 1 Év Garanciával
- Akció! ÚJ akku! Lenovo ThinkPad X1 Extreme Gen2 i7-9850H 16GB 512GB GTX1650 500nit UHD 1 év gar
- BESZÁMÍTÁS! MSI B450M R5 5600X 16GB DDR4 512GB SSD RX 9060 XT 16GB Rampage SHIVA ADATA 650W
- LG 27UL550-W - 27" IPS / 3840x2160 4K / 60Hz 5ms / HDR10 / AMD FreeSync
- Apple iPhone 13 Pro Alpine Green ProMotion 120 Hz, Pro kamerák 128 GB-100%
- Full Prémium! Gamer PC-Számítógép!Rog Maximus XII! I9 10850K / RTX 3080 Suprim / 32GB DDR4 / 2TB SSD
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
. De nem is feltétlen életszerű. A támadó első körben úgyis fájlrendszer szinten jön be.
A lehető legrosszabb megközelítés ez, ha valóban ezt ajánlják bármely fórumon, azt a helyet messze kerülni kell.

)."
Amíg simogatja, elodázza a végzetét.

, esetleg valami Dialog kevésbé intruzív. Persze a megvalósítandó feladaton múlik, melyik a nyerő, ezt pedig a hozzászólásoknál szerintem mi ketten nem láttuk teljes mivoltában.




