- Poco F6 5G - Turbó Rudi
- Motorola Edge 50 Neo - az egyensúly gyengesége
- Motorola Razr 60 Ultra - ez a kagyló könnyen megfő
- Netfone
- Hívószám-hamisítás
- Milyen okostelefont vegyek?
- Android alkalmazások - szoftver kibeszélő topik
- Honor 200 Pro - mobilportré
- Samsung Galaxy Watch7 - kötelező kör
- Samsung Galaxy A53 5G - kevesebbet többért
Új hozzászólás Aktív témák
-
Karma
félisten
válasz
Lortech #4999 üzenetére
Akartam írni a multicast DNS-t, aztán a munka elvitte az időmet
Szerintem ha van rá lehetőség mindenképpen ebbe az irányba kéne terelni a dolgokat, mert nem kell szerver hozzá, pontosan erre találták ki, és a gyakorlatban is sok helyen sikerrel használják (ld. Apple Bonjour).
-
Karma
félisten
-
-
Karma
félisten
válasz
alratar #4855 üzenetére
A menny += menny csak nekem tűnt fel?
Mindenesetre eddig ez elég FUBAR, szerintem lassítanod kéne egy kicsit és két dolgot mindenképp megejteni: kicsit végiggondolni hogy ki kivel van, és némi konvenciót is kéne találnod a tagváltozókban (vagy kiírni a this-t, mert így a settereid nem sokat csinálnak.
WonderCsabo: a += -re gondoltam explicite
-
-
Karma
félisten
Most decompiláltam az ArrayList.class-t a JDK7-ben (rt.jar):
public int indexOf(Object obj)
{
if(obj == null)
{
for(int i = 0; i < size; i++)
if(elementData[i] == null)
return i;
} else
{
for(int j = 0; j < size; j++)
if(obj.equals(elementData[j]))
return j;
}
return -1;
}Nem látom az összeomlást.
-
Karma
félisten
Nem tudom melyik forrást nézed, de az AbstractList indexOf teljesen korrekt módon kezeli a null elemeket a listában. Illetve nullra is tud keresni.
"Márpedig ahol objektumok vannak ott van null is
"
Ez egyáltalán nem biztos. Ha egy objektumlistáról nem lehet feltételezni, hogy benne objektumok vannak, ott azért vannak más bajok is, fejben
-
Karma
félisten
válasz
WonderCSabo #4816 üzenetére
Oké, primitív típusokkal tényleg nem működik (mondjuk belegondolhattam volna, hiszen nem is lehet típusparaméternek használni őket
); viszont objektumokkal igen, és szerintem ez a követendő minta ezesetben a kézzel írt keresőciklusok helyett.
-
Karma
félisten
válasz
caindwan #4814 üzenetére
Ha tömböd van, akkor használhatod az Arrays.asList() metódust ahhoz, hogy olcsón listát készíts belőle, és annak már lesz indexOf metódusa.
Azaz pl.:
int[] array = new int[] { 5,4,2,5,3,2,5 };
int pos = Arrays.asList(array).indexOf(3); // <-- 4
int pos2 = Arrays.asList(array).indexOf(1); // <-- -1 -
Karma
félisten
válasz
Oppenheimer #4800 üzenetére
Az elv egyébként: "if it ain't broken, don't fix it". Elsősorban Androidozok, amihez ugye Eclipse vagy előbb-utóbb az iDEA van bejáratva, de ahogy előttem is volt, rengeteg toolchain és egyéb eszköz épít rá. Ebből azért párat használok is a mindennapokban.
Szóval nekem nincs se igényem, se betöltendő űröm hozzá.
-
Karma
félisten
válasz
S0m30n3 #4798 üzenetére
NetBeanst én elvből se használok, de SQL Serverrel már kommunikáltam JDBC-n keresztül.
A Microsoft driver helyett a jTDS-t használtam, SQL Server authentikációval. A Management Studioban előtte bekapcsoltam a TCP protokollt, és így néz ki az URL:jdbc.driverClassName=net.sourceforge.jtds.jdbc.Driver
jdbc.url=jdbc:jtds:sqlserver://192.168.1.103:11433;instanceName=SECRETPROJECT;databaseName=SecretProjectDB;Legalábbis ez a helyi teszt konfiguráció, élesítés után azt hiszem hangoltunk még rajta, de azt nem tudom (és nem is akarnám) felidézni. Mindenesetre célszerű megnézni a jTDS URL-jének a lehetséges paramétereit.
Ezt a két propertyt, karöltve a felhasználóval és jelszóval átadom egy DriverManagerDataSource-nak, és vígan megy a Hibernate is meg a kézi SQL is. Leegyszerűsítve
-
Karma
félisten
válasz
Oppenheimer #4780 üzenetére
Mondjuk ez a bezárásos szöveg szerintem eléggé sablon marhaság (mármint hogy így adják elő órán). Miért zárnád be a streamet ha van még mit kiírni? Ott van a reset metódus erre.
-
Karma
félisten
válasz
WonderCSabo #4772 üzenetére
Nekünk is volt egy egész félév a nyelvről, illetve szakirányos tárgyakon még legalább három kurzus ami Javaval foglalkozott, de arról egyszer se volt szó, hogy miért viselkedik az a és d úgy, ahogy. Szerencsére van StackOverflow ahonnan gyorsan kiderült a magyarázat
-
Karma
félisten
Én már megfejtettem, annyit hadd mondjak el, hogy 1) attól, hogy valami nem szerializálódik ki, a változó létezik és egész szám, úgyhogy megjelenik a kiírásban (2x4 számjegy biztosan lesz); 2) és ez a BROTIP része: a Java szerializálás sokkal bonyolultabb, mint eddig gondoltam.
És aki ilyet kérdez vizsga beugróban, nyaljon sünt. Ez a történet nem az egyszerű szabályokról szól
-
Karma
félisten
válasz
WonderCSabo #4762 üzenetére
Én is pont ezt tippeltem privátban. Nem spoilerezek.
-
Karma
félisten
válasz
WonderCSabo #4713 üzenetére
Hát, én ilyen esetekben inkább kezelem a kivételt, végülis azt vállaltam az interfészen. Egyébként persze jogos, ha tudatos döntés eredménye és le is van kezelve ez a láthatatlan ág, akkor egy szavam nem lehet.
Csak az utóbbi három alkalommal, amikor ilyet láttam, ez inkább az "elkussoltatom a fordítót, de különben szarok a hibára" szándék állt mögötte... Sőt, háromból egy az Xtend által generált csodás Java kód volt, úgyhogy sehol egy warning (@SuppressWarnings("all")), vagy egy ellenőrzött kivétel.
-
Karma
félisten
válasz
WonderCSabo #4711 üzenetére
Ohohohó, dehogynem lehet.
Volt már szerencsém ilyenhez élőben:try {
// ...
} catch (Exception ex) {
throw new RuntimeException(ex);
} -
Karma
félisten
A naív és kevésbé szép, de legalább ronda (India style) és általános megoldás, ha List<Map<String, String>>-et vagy List<Map<String, Object>>-et gyártasz az adatból.
Dobna rajta, ha definiálnál egy osztályt az elemre, melynek olyan tagváltozói vannak, mint a belső array kulcsai. Így típusbiztos a parser kimenete.
Egyébként olyan plusz előnye is lenne, hogy használhatnál okosabb eszközöket, mint például JAXB-t vagy a Simple-t a feldolgozáshoz ahelyett, hogy lábbal hajtod a DOM parsert.
-
Karma
félisten
válasz
PandaMonium #4668 üzenetére
A Visual Studio és a WPF/Silverlight hozzá tudja szoktatni az embert a jóhoz. A kattingatós tervezés ide vagy oda, azért engem is érdekelne, van-e valami épkézláb eszköz arra, hogy el lehessen kerülni a teljesen lábbalhajtós GUI fejlesztést.
-
Karma
félisten
válasz
trisztan94 #4664 üzenetére
Google-keresés alapján ez az update site van Keplerhez.
Egyébként sose használtam. -
Karma
félisten
Valami ilyesmi, annyi különbséggel, hogy a legtöbb JSON serializer libnek kell egy paraméter nélküli konstruktor is. Illetve konfigurációtól függően lehet, hogy kell egy JAXB annotáció (@XmlRootElement az osztályon).
Meg a new String() helyett "" is bőven elég.
Vasinger!: A Google-t kérdezted már? Van StackOverflown elég részletes válasz, meg amúgy külön doclet is hozzá, lehet hívni Antból, Mavenből, kézzel...
-
Karma
félisten
Tegyél egy Consumes("application/json") annotációt a metódusra, és készíts egy olyan osztályt, aminek a mezői rápasszolnak a JSON objektumra. A framework megcsinálja a deserializálást, persze ha jól van beállítva
Például a Jerseyhez egész fejezet van.
-
Karma
félisten
válasz
Spam123 #4576 üzenetére
1) A fájlodban használj UTF-8 kódolást, mert amellett hogy jó gyakorlat, megbízhatóan működik minden platformon és mindenki ezt használja. (Aki nem, az meg valószínűleg szeretné, de külső tényezők miatt nem tudja.)
2) Amikor olvasod fel a fájlt, használd az InputStreamReader osztályt, azon belül is a kétparaméteres konstruktorok közül amelyik szimpatikus, és ott add meg az UTF-8-at. Pl.: new InputStreamReader(stream, "UTF-8"); -
Karma
félisten
válasz
Spam123 #4573 üzenetére
Vissza kell hoznod a teljes Collectiont a memóriába, hozzáadni az új elemeket, és újra kimenteni. Mondjuk ha nem léptél ki az alkalmazásból és nem engedted el az eredeti referenciát, akkor ezt a betöltést meg tudod spórolni, a teljes kimentést semmiképp.
Vagy más stratégiát kell választanod, például lokális adatbázist – ha az adataid meg az igények engedik.
-
Karma
félisten
válasz
#89874944 #4567 üzenetére
Az a baj a történettel, hogy az ImageIcon nem erre való, definíció szerint előre ismert és fix méretűek. Szerintem a tisztább megoldások egyike lenne az, hogy csinálj egy saját JLabel osztályt, ami a paintComponentben skálázva kirajzol egy képet, és ezt rakd bele a gombba.
-
Karma
félisten
válasz
Oppenheimer #4539 üzenetére
A-yup.
-
Karma
félisten
válasz
Oppenheimer #4537 üzenetére
A CardLayout például jó ilyesmire.
-
Karma
félisten
válasz
#89874944 #4497 üzenetére
Én nem tapasztaltam ilyen jelenséget a Java kódnál (amit egyébként tükörfordítottunk C#-ra, de az algoritmus szempontjából lényegtelen). Szerintem nem szabadna így viselkednie, de próbálkozhatsz pl. egy gaussian blurrel előtte. A MATLABosat nem próbáltam, egyetem óta nem nyúltam ilyesmihez
Mondjuk úgy olvastam, hogy feltételezi, hogy a kép már szürkeárnyalatúra lett konvertálva korábban – az én esetemben ez különösen fontos volt, mert a fotó tárgya sárga alapon fekete és piros betűket is tartalmazott, és nekem csak a fekete érdekes. Minden mást kidobtam a szürkeárnyalatúsítás során azzal, hogy csak az egyik színcsatorna értékét tartottam meg, a többit meg ugyanarra az értékre állítottam.
-
Karma
félisten
válasz
caindwan #4462 üzenetére
Az biztos, hogy valamilyen objektumba be kell foglalnod a háttérbe küldött metódust – a new Runnable() {} is egy anoním osztály definíciója –, ezt nem kerülheted el. Én az adott platformra jellemző magasabb szintű szerkezeteket javasolnám a nyers szálazás helyett: Androidon AsyncTask, Swingnél SwingWorker, egyébként meg ExecutorService.
-
Karma
félisten
válasz
WonderCSabo #4455 üzenetére
Ami egyébként a BigDecimal alapja is, kiegészítve a tizedespont kezeléssel.
-
Karma
félisten
válasz
kemkriszt98 #4450 üzenetére
BigDecimalt használ, mint ahogy például pénzügyi számításoknál is, ahol para a lebegőpontos ábrázolás.
-
Karma
félisten
válasz
Oppenheimer #4443 üzenetére
A ciklust nem így gondoltam. Attól szakítsd el az animátort, hogy 20 ms-enként meg kelljen hívni; ezt a konstanst töröld mindenhonnan (kivéve a sleepet, legalábbis amíg nem állsz át Timerre), és helyette az eltelt idő paraméter legyen. Azaz a timeDiffet kell átadnod és azzal számolni az elmozdulásokat.
A duplapufferelés helyes használatának utánaolvasgattam, és még annál is sokkal könnyebb, mint amit elképzeltem. Itt van egy használható példa a BufferStrategy használatára, sőt a végén a példakódban van Timer is, meg billentyűkezelés. Szóval bátran emeld át
A Java Timerek egyébként háttérszálon futnak, úgyhogy amit kitaláltál, könnyen megvalósítható a példa követésével.
A kódoddal kapcsolatban: ha az ellenségek között a különbség csak a kép és az a négy konstans ami a pályát befolyásolja, ne csinálj külön osztályokat miattuk. Egy "OscillatingEnemy" elég, ami konstruktorban kap képet és számokat. Ha más ellenségféle is kéne, akkor is használhatsz strategy mintát a viselkedés leírására subclassok helyett.
-
Karma
félisten
Filóztam egy kicsit még ezen a duplapufferelésen, arra jutottam hogy mindenképp megérné megcsinálni. Annyi az egész, hogy a játékciklus végénél tényleg rajzolsz egyet – de nem a képernyőre, hanem egy a panellal megegyező méretű Bitmapre, amit a paint metódusban egyszerűen rámásolsz a panel canvasára. Így a játék UI konkrétan semmit se tud a játék világáról; akár macskás állóképeket is rajzolhatna pont ugyanúgy, mint űrhajós lövöldözést.
És a Timerre (annak schedule metódusával) átállást szintén nagyon javaslom.
-
Karma
félisten
válasz
Oppenheimer #4439 üzenetére
Folyt.: A kódban ki az a GA? A Move most viewport (ablak) vagy világ (0-100) koordinátákban számol? Mert egyértelműen az utóbbiban kéne, és csak rajzolásnál konvertálni pixelpozíciókra. PROTIP: a játékmotor és a konkrét ablak két egymástól független dolog.
Egyébként a game loopodat kicsit rendbe kéne szedni, mert a mostani elnevezésekkel nem jön át hogy mi mit csinál. Ennek kellene történnie:
1) Kiszámolod a legutolsó periódus óta eltelt időt.
2) Ezzel az értékkel mozgatod a modell szinten (world koordinátákban) az objektumokat.
3) Kiszámolod és kezeled az ütközéseket - a ConcurrentModificationExceptionök miatt okosan kezelve a pusztulásokat - pl. naívan egy listát gyűjtesz minden meghaló entitásról, és az ütköztetés után külön ciklusban törlöd őket a világból.
4) Eltárolod az időt az első lépéshez, most.
5) Invalidálod a panelt.
6) Vársz. Várakozás helyett lehet, hogy egy jó időzítőosztályt kéne használnod amúgy.Rajzolásnál meg, ami aszinkron meghívódik, az aktuális állapotot rajzold ki. Semmi mást ne csinálj. Egyébként azt is lehetne, hogy egy másik ciklus hívogatja a rajzolást, de nem biztos hogy szükséges. Duplapufferelést is lehetne írni, nem sokból tart.
Ez így egy hótprimitív játékciklus, de egyszerű dolgokhoz elég lehet.
-
Karma
félisten
válasz
Oppenheimer #4439 üzenetére
Gyorskérdés, amíg tovább olvasom: miért nem használsz foreach ciklust manuális iterátorozás helyett?
Második: a rajzolási ciklusodból takarítsd kifelé a destroyEmeny hívást! Semmi köze hozzá, rajzolja csak ki a pillanatnyi állapotot, de semmi logika.
Harmadik: ezzel a Move implementációval biztosan pofonba szaladsz. Egyrészt a 20 ms fix idő semmilyen körülmények között nem garantálható, ezért úgy szokták megoldani ezt, hogy a Move paraméterben megkap egy legutolsó frissítés óta eltelt időt (pl. milliszekundumban), és azzal számolja a képleteket.
-
Karma
félisten
válasz
Oppenheimer #4405 üzenetére
Nem tudja. Külső libet viszont tolhatsz rá, nekem pl. ezt dobta a Google.
-
Karma
félisten
válasz
Oppenheimer #4401 üzenetére
Hát kelleni nem kell, ha a Path2D osztályt használod.
-
Karma
félisten
válasz
Peter Kiss #4390 üzenetére
Itt az aktuális tesztkódom.
És a futási eredmények érdekesen változtak, amióta átálltam Callable-re:
try-catch: 104 ms.
regex: 465 ms.
validator: 2350 ms.
numberutils: 96 ms. -
Karma
félisten
válasz
Peter Kiss #4391 üzenetére
DecimalFormat.parseObject-et használ, ami nullt ad vissza hiba esetén, vagy egy Number objektumot ha sikerült.
Egyébként megmértem, a try-catch kétszer annyi időt igényel, mint egy egyszer létrehozott Patternnel matchelni és annak függvényében Integer.parseIntet hívni. 3000000 futás esetében (kettő helyes, egy hibás) ez 1,5 vs 0.7 másodperc a Surface-emen (i5).
De beleteszem a Commons Validator és a Lang3 NumberUtilst is.
-
Karma
félisten
válasz
Peter Kiss #4380 üzenetére
Van mérési eredményed is arról, hogy ez a megoldás ténylegesen lassabb mint a felsorolt alternatíváid? Mert például az Apache Commons Langban is try-catchelnek (NumberUtils.toInt).
-
Karma
félisten
válasz
Oppenheimer #4356 üzenetére
A másodikhoz nézd meg a MigLayoutot.
-
Karma
félisten
válasz
Peter Kiss #4323 üzenetére
Mi alapján fordítanád fel a mezőket? Ha ciklussal iterálsz 0,0-ból n,m-ig, és a jobb alsó sarok tájékán kattintott a felhasználó, akkor jó darabig semmi információ nincs arról, hogy az aktuális elemet kell vagy nem felforgatni.
A rekurzív bejárás jobb lenne az adott pontból, csak rendes leállási feltétel kell neki.
-
Karma
félisten
válasz
Superhun #4300 üzenetére
Vagy bekeményíthet egy kicsit a kerék újrafeltalálása előtt.
-
Karma
félisten
Köszi, ezen a vonalon el tudok indulni remélhetőleg.
(Egy BridgePropertyPlaceholderConfigurernek kéne mindezt becsempésznem.) -
Karma
félisten
válasz
trisztan94 #4294 üzenetére
Tudtommal jó eséllyel, ha nem használsz semmit az újabb Servlet API-ból. Azért volt egy-két konfigurációs változás is...
A legegyszerűbb ha letöltesz egy hatost és megpróbálod, nem sokból tart.
Más:
Nekem is lenne egy kérdésem a közösbe.
Adott egy webalkalmazás WAR csomagban, ami egy properties fájlból konfigurálható (DB elérés, SMTP, útvonalak, stb.). Ezt jelenleg a classpathon tárolom (fájlszinten a WEB-INF/classes alá kerül a Maven által).
A kérdés egyszerű: hova és hogyan kellett volna tennem ahhoz, hogy ha új verziót adok ki a cuccból, a WAR-ban lévő propfájl ne vágja felül az ügyfél adatait? Nem én üzemeltetem és nyilvánvaló okokból nem kapom meg az ő konfigjukat, amiket a deployolt alkalmazásban módosítottak.
Gyors megoldásként gondoltam arra, hogy a fájlt kiveszem a WAR-ból, így a Tokcat redeploy nem fog a kinn lévőhöz nyúlni. De mi lett volna a helyes megoldás?
-
Karma
félisten
válasz
trisztan94 #4290 üzenetére
A setColor 0 és 1 közötti float értéket vár, nem 0 és 255 közötti egészeket.
-
Karma
félisten
válasz
trisztan94 #4280 üzenetére
Az megvan ugye, hogy az előző kódod pont ugyanez?
Persze ha a smokeX egész szám, akkor egynél kisebb számot kivonogatva mindig ugyanazt a számot kapod.
Szerk.: Tévedtem, nem ugyanaz, mert összeadás helyett szorzást írtál az előbb.
-
Karma
félisten
válasz
pakriksz #4254 üzenetére
Ja egyébként erre visszatérve: jogos észrevétel, a TeeOutputStream valószínűleg praktikusabb, mert akkor csak egyszer kell írnod valahol a forrásnál, mintha simán a fájlt hergelnéd.
Ha InputStreamet készítesz a forrásoldalon, akkor tényleg másolni kell, a streamek nem folynak át maguktól egymásba
Viszont a Commons IO-ban erre is vannak statikus metódusok (IOUtils.copy, IOUtils.copyLarge), úgyhogy nem muszáj saját IO logikát írni.
-
Karma
félisten
Az még talán nem is olyan nehéz, bár nem könnyű pontozni a full randomhoz képest az alternatív megoldásokat. Szerk.: Az egy jó ötlet, ami előttem elhangzott: csak az első kattintás után kell lerakni őket, hadd higgye azt a játékos, hogy szerencséje volt
Ott van még, és tényleg bejárási algoritmust igényel annak a kezelése, hogy ha egy nullás mezőnek minden szomszédját fel akarja fedni - hasonlóan például a Windows beépített aknakeresőjéhez. De semmi durva.
Off vonalra visszatérve: sok merész, valóságtól elrugaszkodott dolgot mondanak az iskolában. Ez a fajta folyamatábra rajzolás iskolapéldája ennek (haha, szóvicc). Egyetemen már közelítenek a dolgok, de azért az első igazi munkafeladat, éles helyzetben mindig hideg zuhanyként jön.
Nem azt mondom, hogy nincs helye a folyamatábrának. De azért egy ilyen programnak fejben is el kell férnie
Ritkán ér rá az ember két és félszer annyi munkát végezni ugyanannyi eredményért, a munkáltatók meg még kevésbé hajlandóak kifizetni.
-
Karma
félisten
válasz
trisztan94 #4214 üzenetére
Hát, nem igazán. Az a pszeudokód, legyen szöveges vagy folyamatábra, már a tényleges programozói munka része, a kész program terve. Nyomokban algoritmusokat is tartalmaz.
Az előttem szólóra rákontrázva: szerintem nemhogy a "jó" programozóvá váláshoz kell ez, hanem egyáltalán a programozáshoz. Egy programnyelvre leírni a más által fejben végigvitt dolgokat nem programozás, csak kódolás.
Az eredeti kérdésre visszatérve: Google-ben próbáltad már? Sourceforge-on? GitHubon?
Persze az így "talált" kódok licencét célszerű figyelembe venni. -
Karma
félisten
válasz
trisztan94 #4212 üzenetére
Mármint aknakereső mire? Generálásra, a játék levezetésére, vagy a megfejtésre?
Ezek közül egyikhez sincs konkrét algoritmus, vagy nem algoritmusnak hívják...
Szóval mi kéne?
-
Karma
félisten
válasz
Ragnar95 #4192 üzenetére
Azitt lévő konfig változtat valamit?
-
Karma
félisten
Elég necces a helyzet. Úgy tűnik, hogy az ügyfél arra számít, hogy hasonlóan egy butább PHP oldalhoz, a Spring alkalmazást is csak felmásolja a
villanyreszelőfejlesztő, és minden flottul megy.Ha csak egy sima JSP oldalról lenne szó, még talán járható is lenne ez a gondolatmenet - ez esetben lemásolnád FTP-vel a mostani állapotot, felturbózod, visszamásolod, és az Eclipse-nek erről nem is kell tudnia.
Ha viszont ez egy rendes alkalmazás, akkor a forráskód nélkül igencsak a pofonba szaladsz bele. Legalábbis ha a logikát is módosítani kell, nem elég a View sablonokat...
Mindenképp használd az FTP elérést és ránts le mindent ami mozdul és kapcsolódik az ügyhöz. Aztán okosabbak lehetünk.
BTW, olyan hogy "javaspring" nincs. A Spring egy nagyon sokrétű környezet, de azért nem saját dialektus. Viszont mint projekt, lehet Spring Web, Spring MVC meg még kitudja milyen lib az alapja.
-
Karma
félisten
válasz
trisztan94 #4163 üzenetére
Dehogy kell neked PHP-val beletaknyolni! Eggyel felette ott van a Java-alapú JSON tutorial, inkább azt nézegesd. És szerintem erre gondolt. Mondjuk kicsit komolyabb kisugárzásod lehet, ha az adatot nem string összeollózással, hanem valami JSON libraryvel (pl. Gson) állítod elő.
-
Karma
félisten
De egyébként muszáj Java hozzá? Ilyen alacsonyszintű mókázáshoz jobb a .NET és a WinAPI interface...
Meg ott a Windows+PrintScreen kombó is.
Na de ha az eredeti baklövéstől nem akarsz elválni, nézd meg ezt a kérdést.
-
Karma
félisten
Halk kiegészítés: nem is a bash a lényeg. Lehet olyan udev szabályokat írni, amik szkriptet futtatnak egy adott USB eszköz csatlakoztatásakor. Remek hely ez az automatizált backup indításához, ha már kreatív akarsz lenni
-
Karma
félisten
-
Karma
félisten
Amellett hogy se a GC-re, se a teljesítményre nincs hatással, még csak nem is best practice.
Legalábbis vannak ellentétes nézetek, amik szintén best practice-nek gondolják hogy a változódeklaráció a lehető legközelebbi scope-ban legyen a felhasználáshoz. Én mondjuk pont az utóbbit vallom.
Hatása elméletben sincs, mert a stream objektum ugyanakkor veszíti el a hard referenciáját mindkét esetben, ergo a GC semmi különbséget nem lát. De a gyakorlatban se, mert a JVM a metódusba belépéskor foglal le minden stack változót a scope-tól függetlenül, azaz a bytecode ugyanaz lesz.
Épp csak fordításidőben szennyezettebb a lokális névtér.
-
Karma
félisten
Érdekes lehetne megnézni, hogy a Windows Explorer hogyan viszonyul ehhez a rengeteg fájlhoz.
Itt szerintem is a Java-n túlmutató dolgok lassítanak: a fájlrendszer (a túl sok fájl egy mappában a legtöbbnek probléma), az OS cachelése (bár ez inkább az elejének a gyorsaságát magyarázza meg), a fájlok elhelyezkedése a HDD-n...
-
Karma
félisten
válasz
Superhun #4064 üzenetére
A Nokia Developeren lévő infók alapján ez úgy circa tíz éve volt menő. Egyébként egész mostanáig én se hallottam róluk, csak a facebook.jar fejlécben lévő rövidítéseknek kezdtem utánanézni.
meroly: Hát, bocs. Ezt a "szóljatok ha megvagytok" stílust lehet túl komolyan reagáltam le. Mindegy, eredetileg mit akartál volna elérni a csomaggal? Az kicsit érdekesebb, meg mondjuk az is, hogy honnan szerezted a védett JAR-t.
-
Karma
félisten
válasz
WonderCSabo #3986 üzenetére
Azért attól még nem lehetetlen, pl. full naív módban a values() által visszaadott tömbön, a name-re tesztelgetve lehet ilyet csinálni. Pontos illesztésre meg ott a valueOf.
Szerintem lehet olyan helyzet, hogy van értelme egy ilyen lépésnek.
-
Karma
félisten
válasz
kemkriszt98 #3948 üzenetére
Technikai akadálya nincs, hogy layout managerek helyett kézzel varázsolj. De azért a helyedben még nézegetném a layoutokat egy kicsit.
-
Karma
félisten
Jó hát azért ezt semmiképp se szabad!
negyedes: A Contextnek az a lényege, hogy a felhasználói felülethez vagy rendszererőforrásokhoz kapcsolódó dolgokat az Android össze tudja kötni az alkalmazásod elemeivel. Például ha a páciens adatokat egy Activity-n akarod megjeleníteni (ami egyben az alkalmazásod egyetlen felülete is), akkor ebben az Activityben hozod létre a PatientData objektumod, átadva a szülő- (tulajdonos-) Activityt.
Vagy ha több helyről is egy példányt akarsz használni, szerezhetsz application contextet hozzá. Vagy ha igazán mérnöki/tankönyvi cucc lesz, egy Service kezelheti az adatokat, amivel a UI üzenetekkel kommunikál, és ez a Service a context...
De az adatosztály semmiképp se az! Ne higgy a kifejtős válasznak se...
-
Karma
félisten
válasz
negyedes #3920 üzenetére
Az az osztály, amiben létre akarod hozni, Context leszármazott? (Application, Activity, Service stb.)
Mert vagy nem jó a konstruktor paramétere, vagy másik csomagban is van DatabaseHandler osztály, és azt importáltad be.Az Eclipse egyébként mindkettőre utaló jeleket mond a hiba azon részeiben, amit gondosan nem másoltál ide
Gondolatolvasás rulez)
-
Karma
félisten
válasz
n0rbert0 #3845 üzenetére
A Netty nevű framework kiválóan alkalmas ennek egy szebb megoldására, még ha egy kicsit nehéz is ehhez. Hasonló programot írtam vele anno, csak TCP alapon, és a bejövő üzenetek bonyolultabb feldolgozást igényeltek (keretezés, dekódolás, mezők kinyerése, CSV fájlba írás, ütemezett új fájl kezdés, stb.)
De a pipeline modellel ezt nagyon szépen le lehetett írni.
Új hozzászólás Aktív témák
Hirdetés
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
- War Thunder - MMO Combat Game
- Star Trek Online -=MMORPG=-
- Luck Dragon: Asszociációs játék. :)
- Logitech Z906
- Amlogic S905, S912 processzoros készülékek
- Milyen processzort vegyek?
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Milyen TV-t vegyek?
- Linux kezdőknek
- Nyíregyháza és környéke adok-veszek-beszélgetek
- További aktív témák...
- BESZÁMÍTÁS! 4TB Toshiba P300 SATA HDD meghajtó garanciával hibátlan működéssel
- Új Apple iPhone 16 Pro Max 256GB, Kártyafüggetlen, 3 Év Garanciával
- Bomba ár! Dell Latitude 3590 - i5-8GEN I 8GB I 256SSD I HDMI I 15,6" FHD I Cam I W11 I Garancia!
- 13-14" Új és használt laptopok , üzletitől a gamerig , kedvező áron. Garanciával !
- ÁRGARANCIA!Épített KomPhone i9 14900KF 64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest