Hirdetés
- CES 2026: a Gigabyte legfrissebb csúcs-VGA-ja mindenképp kitűnik a tömegből
- CES 2026: az üzleti mellett a gamer szegmensben is újít az MSI
- CES 2026: felfrissült CPU-hűtők és két pihekönnyű egér a be quiet! gondozásában
- CES 2026: nagyon szeretné kézikonzolokban látni a Panther Lake-et az Intel
- Aktiválható a DLSS 4.5 az új GeForce driverrel
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Vezetékes FEJhallgatók
- Kezdő fotósok digitális fényképei
- Úgy állhat le a 16 GB-os GeForce RTX 5060 Ti gyártása, hogy közben nem áll le
- Kormányok / autós szimulátorok topikja
- NVIDIA GeForce RTX 5080 / 5090 (GB203 / 202)
- Milyen videókártyát?
- HiFi műszaki szemmel - sztereó hangrendszerek
- Milyen billentyűzetet vegyek?
- Milyen asztali (teljes vagy fél-) gépet vegyek?
Új hozzászólás Aktív témák
-
Karma
félisten
Egészen pontosan mit szeretnél csinálni? A saját alkalmazásodban használni valamire a proximity sensort, vagy a telefonon valamit "automatizálni" vele, de nem feltétlen önálló alkalmazásként?
Az előbbihez a SensorManager osztály lesz a barátod, amivel fel kell iratkoznod a proximity sensor változásaira, és az onSensorChanged metódussal azt csinálsz, amit akarsz.
Az utóbbit meg a Taskerrel össze lehet kalapálni. Ennek van külön topikja.
-
Karma
félisten
válasz
WonderCSabo
#2388
üzenetére
Arról lehet tudni valamit, hogy az új, Materialhoz kapcsolódó API-k platformban jönnek, vagy compat lib/play services formájában? Mert ha csak L-en érhető el, akkor már nem is érdekel...
-
Karma
félisten
Az alacsony targetSdkVersionnek egyébként van egy olyan mellékhatása, ami azért fenéken tud harapni a jövőben: 11-es API szint felett tilos UI szálon hálózati kommunikációt végezni (NetworkOnMainThreadException dobódik), de ha a targetSdkVersion kisebb ennél, az új androidos eszközök se akadnak fenn miatta - hogy ezáltal a régi, nem frissített alkalmazások ne dőljenek össze.
-
Karma
félisten
válasz
WonderCSabo
#2365
üzenetére
Hmm. Jogos, nem jutott eszembe - én mindig szinkronban tartom a kettőt

-
Karma
félisten
válasz
WonderCSabo
#2363
üzenetére
Kiegészíteném annyiban, hogy a targetSdkVersion számít ebben az esetben. Ha az app minSdkVersionje 8 is, akkor is célszerű a legújabb targetet használni (de legalábbis a 18-ast), így már látja az Eclipse az osztályt, de warninggal aláhúzza, hogy csak 8 fölött érhető el.
-
Karma
félisten
válasz
Just_Reboot
#2360
üzenetére
Szerintem ezt az érintettektől kéne megkérdezni - különösen a CM fejlesztőktől.
-
Karma
félisten
Ha API level 9 és afölötti Androiddal dolgozol (mással nem is nagyon van ma már értelme), akkor használhatod a Normalizer osztályt a Unicode szabványnak megfelelő ékezetlebontáshoz és -nyíráshoz. Itt a mikéntje.
-
Karma
félisten
válasz
WonderCSabo
#2351
üzenetére
Azért egy kicsit meglep, hogy hogy lehet a this egy Class<Activity> példány
Nekem ott valami nagyon sántít._kovi_: Kérlek másold be az osztályod elejét (public class...), és ennek a konkrét gombkezelőnek is az elején, hogy lássuk a típusokat és a paramétereket.
Vagy másold be az egész osztályt Pastebinre, és akkor lehet, hogy a TextView-s problémádra is látunk valami megoldást. A vakvilágba nem szeretnék sorokat írogatni.
-
Karma
félisten
Mi alapján feltételezed, hogy háttérszálról hívja meg? Minimális tervezéssel (például AsyncTaskok használatával) egyébként is teljesen felesleges kézzel hívogatni a runOnUiThreadet.
Viszont annyit mindenképp meg kéne nézni, hogy a logcaten látszik-e bármi. Meg mondjuk breakpointtal megnézni, egyáltalán meghívódik-e az a sor.
És jó lenne látni valamit a kódból és a layoutból.
Lehet írni kéne egy topik összefoglalót, amiben ezek a közös kötelező körök benne vannak.
-
Karma
félisten
Ismert hiba. Szerintem nem tudsz vele mit csinálni, inkább próbáld meg átverni az ügyfelen, hogy hátrafelé a platform hibája miatt nem fog működni, csak előre.
-
Karma
félisten
válasz
kemkriszt98
#2319
üzenetére
Igen, ezért is kérdeztem: Windows és OSX/Linux között mozgatáskor bekavarhat az eltérő karakterkódolás. (Többek között ezért is fontos, hogy ne a Java kódba legyenek beégetve a magyar feliratok
).De sajnos így hirtelen nincs más ötletem. A LogCaten semmi se látszik? Debuggerrel futtatva breakpointon megáll a kód, amikor képernyőt kéne váltani?
-
Karma
félisten
válasz
kemkriszt98
#2317
üzenetére
Egy ötletem van: teljesen véletlen nem használtál ékezetes neveket az osztályaidnak, vagy bármit a manifestben?
-
Karma
félisten
válasz
kemkriszt98
#2307
üzenetére
A koordináta a szöveg alsó szélét adja meg. Vízszintesen meg az igazítástól függően bal sarok, középpont vagy jobb sarok.
A szöveg magasságát, amivel a megfelelő számításokat el tudod végezni, a Paint getTextBounds hívásával kapod meg.
-
Karma
félisten
A konfigurációs fájljában, ami a projekt gyökerében van alaphelyzetben, tudod hangolni a működését. Mondjuk fontos, hogy bárminek, ami a manifestben látszik (pl. Activity-k, Service-ek) nem szabad megváltoztatni a nevét, mert úgy az Android nem találná meg, és nyekkenés lenne a vége.
Ugyanez vonatkozik mindenre, amit reflexióval hozol létre.
-
Karma
félisten
-
Karma
félisten
válasz
h1ght3chzor
#2274
üzenetére
"Azt nem mondták, hogy nem a foga fáj!"
Mondjuk ettől még a busy wait továbbra se járja. Van szofisztikáltabb megoldás: Timer és TimerTask például, amik Androidon nem szerencsések, de desktopon elfér.
-
Karma
félisten
válasz
h1ght3chzor
#2264
üzenetére
Jézus ereje... Ezt így semmiképpen se hagyd, ezért még desktopon is felnégyelnek, teljesen jogosan. Nézd meg a telefon CPU használatát a DDMS perspektíván, szép lesz...
Ne erőltesd a végtelen ciklust, szerintem elég volt a játékból. Írj egy Runnable-t és használj Handlert! Nincs Android környezetem most kéznél, de valahogy így nézne ki:
public class FapapucsActivity extends Activity {
private Handler mHander = new Handler();
private Runnable mScheduled = new Runnable() {
public void run() {
Log.d("FapapucsActivity", "PING!");
mHandler.postDelayed(mScheduled, 60000);
}
};
public void onResume(...) {
mHandler.postDelayed(mScheduled, 60000);
}
public void onPause(...) {
mHandler.removeCallbacks(mScheduled);
}
}Az ismétlődés kulcsa, hogy a Runnable végén újra felírja önmagát.
-
Karma
félisten
válasz
h1ght3chzor
#2260
üzenetére
Heh, ez pont ugyanaz mint amit az előbb írtál.
Tégy egy lépést hátrébb és azt írd le, hogy mire lesz ez jó. -
Karma
félisten
válasz
h1ght3chzor
#2257
üzenetére
Az előbb még várakoztatni akartad a szálat...
Inkább azt írd le, hogy mit szeretnél csinálni, minthogy implementációs részleteken pörögjünk egy fél oldalon át.Egyébként ha már implementáció, a Handler postDelayed egy sokkal jobb válasz. Ha eltekintünk attól, hogy minden ami ciklikusan ismétlődik, mobilon nem jó.
-
Karma
félisten
válasz
h1ght3chzor
#2254
üzenetére

De komolyan? Nem desktopon, középiskolai programozásórán vagy, hogy időzítve várakozzál eseményekre. De ha nagyon akarod, akkor a Thread.sleep() metódus jó erre.
-
Karma
félisten
válasz
kemkriszt98
#2250
üzenetére
installLocation elem kéne a manifestbe.
-
Karma
félisten
válasz
trisztan94
#2243
üzenetére
Ez Dalvik assembly, úgyhogy annyira nem jársz messze.
A VTS-ben a projekt beállításai között van egy opció, hogy Java forrás generálása (checkbox), ezt billentsd be, majd buildeld újra az APK-t.
Így is maradhatnak benne "hülyeségek".
Vagy ahogy WonderCSabo írta

-
Karma
félisten
Ezt a leírást nézd végig és tartsd be. Az AOSP nem egy olyan dolog, amit csak úgy szétkap és tákol az ember.
-
Karma
félisten
válasz
h1ght3chzor
#2228
üzenetére
Szerintem egy class diagram és egy activity diagram bőven sok is, de leírható velük minden simán. Sequence-et nem javasolnék, mert sokkal terebélyesebb az activitynél, miközben kvázi ekvivalensek.
-
Karma
félisten
-
-
Karma
félisten
válasz
eastsider
#2196
üzenetére
Ezt most nem sikerült szerintem annyira érthetően megfogalmaznod... Szóval indítasz egy camera intentet, visszatér, elfordul az activity, aminek hatására új példány jön létre belőle és elveszik a lőtt kép?
Mert akkor vagy onSaveInstanceState/onRestoreInstanceState-et kéne használnod (és elmenteni lepusztulás előtt a kapott URI-t), vagy fragmenttel végezni a fotózást.
-
Karma
félisten
Igen, enélkül a csak-Java alkalmazásokat elég könnyen vissza lehet fejteni. Onnantól a lehetőségek elég tágak... Az ártatlan vizsgálódáson túl lehet sok gonoszságot is művelni, például átírni benne egy-két apróságot, kiiktatni valami házi védelmet, becsempészni egy kis trójait, átnevezni, és kiadni saját (vagy az eredeti) nevén.
4.1-től kezdve elvileg a fizetős alkalmazások már titkosítottak, úgyhogy ha régebbi telefonra meg alternatív csatornákon nem terjeszted a programod, akkor az már biztonságban van.
-
Karma
félisten
válasz
trisztan94
#2187
üzenetére
APK projektként kell kezdened, odáig biztos (az M10 HTC-specifikus témacsomag emlékeim szerint).
A hiba alapján nem adtál neki framework.jar-t - ha fut a GenyMotion, akkor a Remote file gombbal elvileg ki tudja szolgálni magát.
-
Karma
félisten
válasz
trisztan94
#2185
üzenetére
Ennyire integrált eszközt nem ismerek másik platformokra, mint a VTS. Némely komponense elvileg kézzel is használható, de nem is nagyon erőltettem sose...
Van még egy tool, a dex2jar, ami megy OSX-en is. Ha a jar megvan, onnan meg a JAD-dal tudsz Java forrásra áttérni; de mondjuk az XML-eket nem tudom hogyan nyerheted ki.
Javaslom a Boot Campet vagy virtualizációt

-
Karma
félisten
válasz
trisztan94
#2182
üzenetére
Ja egyébként azt el se árultad, hogy milyen AVD-t hoztál létre. Az csak egy szükséges feltétele a játékodnak, hogy legyen fenn 18-as SDK és system image, de olyan virtuális telefont kell létrehoznod, ami ezeket használja is.
-
Karma
félisten
válasz
trisztan94
#2182
üzenetére
Nem rossz próbálkozás, de nem is célravezető.
Ajánlanám, hogy tedd fel a Virtuous Ten Studio-t, amivel visszafejtheted forráskód szintig az APK-t, valamit a Genymotiont, ami egy VirtualBox alapú, sokkal gyorsabb emulátort ad, Google API támogatással.
-
Karma
félisten
válasz
bAtt001
#2179
üzenetére
android numberpicker preference
És ezzel a kereséssel találtam is komplett megoldást a problémára.
-
Karma
félisten
válasz
vazee00
#2176
üzenetére
Sok pénzért van rá céleszköz, de alapvetően könnyen visszafejthető a legtöbb házi offline megoldás (pl. az egy dolog, hogy egy hosszú kulccsal titkosítod a DB jelszót, de utána hova rakod ezt a kulcsot?).
-
-
Karma
félisten
válasz
WonderCSabo
#2146
üzenetére
Én úgy értem, hogy app indításonként egyszer kellene letiltani. Azaz a shared pref nem kell, csak egy sima boolean tagváltozó a WebViewClientben.
-
Karma
félisten
válasz
eastsider
#2137
üzenetére
Én nem látok benne semmi igénytelent, sőt ha csak megjeleníted és tárolod az értéket, akkor minden más megoldás felesleges vudu. Komolyan.
Mondjuk ennek megítélésében sokat segítene, ha elárulnád a feladatodat a kiragadott implementációs fennakadásoknál bővebben.
NumberPickerbe stringet tenni nem is tudsz szerintem, nem AdapterView.
-
Karma
félisten
válasz
eastsider
#2122
üzenetére
Az UIL anomáliát elvileg az okozza, hogy az adapter újrahasznosította a view-t még azelőtt, hogy a képkérés lefutott volna, a régi kérés pedig még mindig fut. Próbáld meg explicite leállítani az UIL-t, ha a convertView nem null.
ImageLoader.getInstance().displayImage(null, image);
A másik kérdést nem igazán értem, miről szól.
-
Karma
félisten
Vagy bele se fog, hanem rábízza magát és a képkezelést az UIL-ra, miközben egy jó konfigurációt ír hozzá a GitHub oldal alapján.
eastsider: Azt, hogy a képek okozzák-e a memóriabajt, könnyen ki tudod próbálni a favágó módszerrel. Azaz kommentezd ki azt a sort, ami az ImageViewt tartalommal tölti meg, és úgy mérj még egyet.
-
Karma
félisten
válasz
h1ght3chzor
#2090
üzenetére
A Calendaros varázslatra semmi szükség nincs, az egészet irtsd ki. Fogd meg a Date objektumot, amit a parse visszaadott, és használd a getTime() metódusát a milliszekundumok megszerzéséhez.
-
Karma
félisten
válasz
h1ght3chzor
#2088
üzenetére
Nem teszteltem és csak fejből írtam, de elvileg:
SimpleDateFormat format = new SimpleDateFormat("MM/dd/yyyy HH:mm:ss");
Date date = format.parse(endTime); -
Karma
félisten
válasz
WonderCSabo
#2078
üzenetére
Már ha az ember 14-es API felett dolgozik...
-
Karma
félisten
válasz
WonderCSabo
#2058
üzenetére
A folyamatos fájlnyitás-flush-zárás miatti teljesítménycsökkenésen kívül semmi gond nincs vele.
-
Karma
félisten
válasz
WonderCSabo
#2056
üzenetére
Jogos, igazad van. A ThreadPoolExecutorok (köztük a single thread is) pont azt az infrastruktúrát adják meg a BlockingQueue köré, amit egyébként kézzel is meg kéne írni.
Bár azért a fájlírós példánál maradva, egy kicsit körülményesíti a dolgot, hogy a fájlt valamikor nyitni és zárni is kell. Nehezebben összeilleszthető a Runnable-ökkel talán, mint alacsonyszinten építkezve.
-
Karma
félisten
válasz
WonderCSabo
#2053
üzenetére
Szerintem (és ez most tényleg csak vélemény) a kettő másra való. A BlockingQueue-val egy fajta feladatot lehet termelőkre-fogyasztókra bontani és skálázni, az Executorok meg inkább eltérő feladatok ütemezésére több szálon.
-
-
Karma
félisten
Sehogy, mert erre nem alkalmas. Valamilyen lokális megoldásra lesz szükséged... Algoritmikusan elég nehéz lenne biztosítani hogy mindenki ugyanakkor induljon...
Egy huszárvágás jellegű ötletem azért van: az eszközök NTP-vel megszerzik a pontos időt, a szerver meg olyan üzenetet küld ki, hogy "14:35:20-kor indítsátok el a lejátszást".
-
Karma
félisten
válasz
eastsider
#2010
üzenetére
Breakpointot próbáltál már rakni az onActivityCreated metódusba, hogy lásd pontosan melyik sor robban?
Az "adott elem alá tartozó joinolt tábla" szerintem nem elég egzakt megfogalmazás... Legalábbis számomra nem egyértelmű, az biztos. Két táblát összejoinolsz, és WHERE feltétellel szűröd az elem kulcsa alapján?
-
Karma
félisten
válasz
h1ght3chzor
#2006
üzenetére
Akkor az a JSON szempontjából igencsak irreleváns. Ha nem akarod parsolni ebben a programban, akkor akár magad is írhatsz egy toJSON metódust: majdnem ugyanolyan mint a toStringed, csak kapcsoszárójel van körülötte, a mezőnevek idézőjelben vannak, és vessző az elválasztó.
-
Karma
félisten
válasz
h1ght3chzor
#2004
üzenetére
Most akkor XX az valami osztály, vagy String? Az előbbi tagmondat erre, a thises történet amarra utal.
Ha osztályok, akkor használd a Gson nevű lubet, gyorsan érhetsz el vele jó eredményeket. Csak a listára kell hívnod egy Gson.toJson-t.
Ha stringek, igazából akkor is ugyanez, de nem ártana kicsit elgondolkodni az adatmodellen.
-
Karma
félisten
-
Karma
félisten
válasz
WonderCSabo
#1979
üzenetére
Eclipse alá közvetlenül is be lehet kötni a Gitet.
Én meg ezt az utat javasolnám, mint ahogy a Sub{clipse,versive}-et is előnyben részesítem a Tortoise és parancssoros megoldásoknál – hadd kezelje az IDE tisztán a refaktorokat, új fájlokat, stb.

-
Karma
félisten
válasz
h1ght3chzor
#1957
üzenetére
Nem.
-
Karma
félisten
Bár perpillanat nem supportálják, ezt a libet használtuk már pár projektben erre.
-
Karma
félisten
válasz
kemkriszt98
#1914
üzenetére
Hát a deleteAll sok mindent csinál, de a lista törlése nincs közöttük. Egyszer azért gondold végig, mi történik így ahogy leírtad

Aztán meg dobd ki az egészet és használd a clear() metódust.
-
Karma
félisten
válasz
kemkriszt98
#1909
üzenetére
Ugye az adapterhez adogatás után meghívod a notifyDataSetChanged() metódusát, UI szálon?
-
Karma
félisten
Ezt nézd meg: stackoverflow
-
Karma
félisten
válasz
h1ght3chzor
#1888
üzenetére
Egyébként ilyen lehetőség nincs. Használd a ContentProvidert ha a felhasználó bevonása nélkül akarsz működni.
-
Karma
félisten
válasz
h1ght3chzor
#1871
üzenetére
Venni egy olcsó androidos telefont, és azon kísérletezni... A szöveg elég egyértelmű, hogy kell egy Google (vagy más naptárt szolgáltató) fiók, de még ha fel is vennél G fiókot, nem fog működni.
-
Karma
félisten
válasz
h1ght3chzor
#1869
üzenetére
Sima intentnél ha több lehetőség is van, akkor majd a rendszer megkérdi a felhasználót.
Kódot most nem tudok produkálni erre, de két lehetőség van attól függően hogy mit szeretnél. Vagy most megnézed a nálad lévő eszközön hogy milyen naptár van és annak az ID-jét beégeted a kódba az 1-es ID helyett; vagy felraksz a UI-ra egy Spinnert amivel ki lehet választani a szimpatikusat.
A Cursorban minden adat benne van - mint láthatod, lekéri az ID-t, a naptár nevét, színt, stb.
-
Karma
félisten
válasz
h1ght3chzor
#1860
üzenetére
Nézd meg még egyszer a dokumentációt a kódrészlet kapcsán, a példakód végén ott van, hogy mire használja az Urit. Neked nem feltétlen van rá szükséged, csak akkor, ha ezt a konkrét eseményt újra el akarod érni keresgélés nélkül.
Ugyanis a kódrészlet a naptár ContentProviderrel beszélget. A ContentProviderek pedig minden általuk kezelt objektumot (pl. eseméyn) egy Urival azonosítanak; az insert ezt adja vissza miután megtörtént a beszúrás.
A kódodnak egyetlen problémája van így ránézésre: a calendar_id-t nem lehet csak úgy hasraütésszerűen 1-re állítani. Meg kell nézni, hogy a telefonon milyen naptárak vannak, és a szimpatikusat választani. A középső dobozban van a kód, amivel le tudod őket kérdezni.
-
Karma
félisten
válasz
WonderCSabo
#1853
üzenetére
Meg ha megnézed a támogatott országok listáját, ott is látszik.

-
Karma
félisten
válasz
h1ght3chzor
#1843
üzenetére
Tényleg így van. Próbálkozni is kár.
-
Karma
félisten
válasz
h1ght3chzor
#1833
üzenetére
1) Addig szép, hogy Bluetooth, de milyen profil? Mert például más osztályok kellenek a Serial Port Profile-hoz a BluetoothSocket/BluetoothServerSocket osztályok kellenek, és úgy viselkedik, mint egy TCP socket. De van tucatnyi más lehetőség (pár gyakori: PAN, HID, A2DP, OPP). Az egész hóbelebanchoz tartozik egy guide az Android SDK dokumentációjában, ezzel kezdhetnél.
2) Ehhez is csak a dokumentációt kéne olvasnod, íme az event létrehozás mikéntje.
3) Meglepő módon a Service osztály dokumentációja még példát is tartalmaz a magyarázat mellett.
-
Karma
félisten
válasz
h1ght3chzor
#1828
üzenetére
Nem biztos hogy jó megoldás, de egy próbát megérhet, hogy az onCreate-ben hívd meg a requestFocus metódusát annak az ET-nek, amit szeretnél fókuszálni.
-
Karma
félisten
válasz
h1ght3chzor
#1826
üzenetére
A setEnabled metódust használd inkább.
-
Karma
félisten
válasz
h1ght3chzor
#1824
üzenetére
A gombok létrehozása után azonnal (pl. onCreate(), a setContentView() után) már állíthatod.
-
Karma
félisten
válasz
XperiaP
#1798
üzenetére
Végülis ja, ez inkább valami megjelenítési dolognak tűnik, ahogy megfagy... Van valami TextWatcher ezen az EditTexten? A mérete, különösen a szélessége fix?
WonderCsabo: Használtad már a GridLayoutot? Nekem elég rossz tapasztalataim vannak vele élesben, pedig nagyon kéne egy ilyen jellegű layout...
-
Karma
félisten
válasz
XperiaP
#1795
üzenetére
Alapjáraton erre gondoltam:
StringBuilder text = new StringBuilder();
br = new BufferedReader(new FileReader(filePath));
char[] bytes = new char[131072];
int numRead = 0;
while ((numRead = br.read(bytes)) >= 0) {
text.append(new String(bytes, 0, numRead));
}
EditText tv = (EditText) findViewById(R.id.editText2);
tv.setText(text.toString());Még ezen is lehetne javítani, ha nem blokkonként csinálsz új stringet, hanem byte tömbbe olvasod az egészet, és egy konstruktorhívással letudod a dolgot. (new String(buffer, 0, buffer.length, "UTF-8"))
Viszont egyáltalán nem biztos, hogy ennyi elég, csak kozmetikázza a valódi problémát (EditText)...
-
Karma
félisten
válasz
XperiaP
#1793
üzenetére
A tv.setText() hívás durván költséges, karöltve a folyamatos memóriadarálással a string konkatenálás miatt... Használj StringBuffert az adat összegyűjtéséhez, és a setText()-et csak egyszer hívd meg. Mondjuk ekkor sincs garancia arra, hogy jól fog menni (nem biztos hogy fel van készítve ekkora tartalomra a control).
Javárj, most olvasom újra. Ha van StringBuildered, akkor minek dekódolod még egyszer kézzel?

-
Karma
félisten
válasz
kemkriszt98
#1750
üzenetére
Ez akkor azt jelenti, hogy sikerült önerőből megoldanod?
-
Karma
félisten
Ez a kérdés alapján Androidon a FileLock pont az ellen nem véd, amit te csinálsz a fájllal, azaz egy processzen belül két szál között nem csinál semmit...
Szerintem egyébként a teljes elképzelés rossz, a fájlt egyetlen objektumnak szabadna csak írnia, és akkor nem kellene lockolgatni semmit. Például egy háttérszál, akinek van egy BlockingQueue-ja, amibe mindenki más belerakhatja a kiírandó szövegeket, ő meg bedarálja ha van mit, a többi időt meg altatásban tölti.
-
Karma
félisten
Ezzel az egyszerűsített formával már nagyon közel kerültél az általam ismert legtisztább megoldáshoz (szálakat indítani igazi borzalom volt), viszont még mindig eggyel több felesleges holtjáték van benne: ez a láthatatlan View felesleges, ugyanis az Activitynek van egy onUserInteraction metódusa, ami akkor hívódik meg, ha a felhasználó piszkálja az appot.
Ezt használhatod a Handler takarításához.
-
Karma
félisten
Az első verzió biztosan nem fog működni, mert a lock objektum példányváltozó, míg a metódusod statikus. A lockot "static final"-ként deklarálva ellenben működhet.
Egyébként a két megoldás között a különbség pont az, amit kifejtettem korábban: ha a synchronized kulcsszót használod a metódus szignatúrájában, akkor vagy a this (példánymetódus esetén), vagy a class objektum (statikus esetben) lesz a lock. Mindkettő elérhető kívülről, így +1 deadlock faktor.
-
Karma
félisten
1) Bevett gyakorlat, hogy a lockhoz használt objektum egy mindentől független, kívülről nem látható, de belül se cserélhető (azaz final) tagváltozó legyen. Ezzel biztosítható, hogy csak ez az egy osztályod lockolhasson az általa védett dolgai körü
l, külső kód véletlenül sem; és hogy nem cserélheted ki másik példányra egy mellényúlással. Vesd össze, ha mondjuk egy ArrayListre lockolsz és van egy gettered a listához, más is rálockolhat és bedeadlockolhatod a programot. Vagy adatok újratöltése után új ArrayListet hozol létre.Más jelentősége tudtommal nincs.
2) Akkor eddig szerencséd volt, hogy az írás és a fájlhandle lezárása gyorsabban lement, minthogy ütközzenek... [link]
-
Karma
félisten
válasz
pittbaba
#1726
üzenetére
Azért erre egy LAMP stacket bedobni a telefonra hogy távolról konfigurálható legyen igencsak overkill... Olyan baltával faragott vaskarika, fából.
Ha a telefon úgyis internetre lát folyamatosan, én kidobnám az egészet a kukába, és leraknék egy webservice-t valahol ami megmondja egy telefonszámról hogy valid-e vagy sem. Ingyen futtathatsz ilyet Azure-ban (Mobile Service-szel még kódolnod se kell), OpenShiften, Herokun, Google App Engine-en, és még ki tudja hány másik helyen.
Az életben tartáshoz egyébként használhatod az AlarmManagert is, periodikusan ráhívva a service-edre, így az Android biztosan beindítja, ha nem futna. Szerintem megérné.
Új hozzászólás Aktív témák
- Sorozatok
- Parfüm topik
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Amazfit Active 2 NFC - jó kör
- Luck Dragon: Asszociációs játék. :)
- PlayStation 5
- iPhone topik
- NVIDIA GeForce RTX 5070 / 5070 Ti (GB205 / 203)
- Világ Ninjái és Kódfejtői, egyesüljetek!
- Xiaomi 15 Ultra - kamera, telefon
- További aktív témák...
- 179 - 180 - 189 - 190 - Lenovo LOQ (15IRX9) - Intel Core i7-13650HX, RTX 4060
- PNY XLR8 CS3140 M.2 NVMe 4.Gen 1TB SSD
- AKCIÓ! Lenovo Legion Go S 32GB/1TB kézikonzol garanciával hibátlan működéssel
- BESZÁMÍTÁS! ASUS ROG GL10DH brand számítógép - R7 3700X 32GB DDR4 512GB SSD RTX 2060S 8GB 500W W11
- Azonnali készpénzes AMD Radeon RX 7000 sorozat videokártya felvásárlás személyesen/csomagküldéssel
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest


Nekem ott valami nagyon sántít.
, onnan el tudod végezni.






