Sajnos rá kellett jönnöm, hogy azért messze kevés az angolom ahhoz, hogy egy számomra ennyire idegen területet megértsek. Kb. az a kategória, mint amikor franciául kezdtem tanulgatni angol tananyagból. 
De kösz, megnézem, hátha...
Minél jobban belemászok a java rejtelmeibe, annál inkább rájövök, hogy nem a Java nyelvvel van problémám, sokkal inkább az objektum-orientált programozási logika az, ami nehézségeket okoz.
[ Szerkesztve ]
A lényeg az lenne ,hogy az akadályt elkerüljök. Fekete az akadály, a fehér a szabad út. A kamerának csak egy állása van ,egyenes menet esetén előre néz, csak előre.Csak itt meg az a baj ,hogy ha mondjuk a kép nagy része fehér de belelóg az akadály ,akkor azt is meg kell különböztetni, na meg a táv kiértékelése is jó lenne az akadálytól.....Nem is olyan egyszerű...Csak ilyennel még soha nem foglaslkoztam ,így azt se tudom hol kezdjem..
Szerintetek a programozási logikát hogyna lehet fejleszteni?
Optikai úton történő távolság méréshez szerintem két kamera képe kellene... rosszul gondolom?
Attól függ. Ha OOP szemléletet akar valaki felszedni, akkor sok kódot kell olvasni. Ezután ha már megvan a megfelelő absztrakciós készség, akkor jöhetnek a design patternek. Ha viszont algoritmizáló készségre vonatkozik a kérdés, akkor sokat kell gyakorolni acm stílusú versenyfeladatok kódolásával.
1) Ha minden fehér, a többi meg fekete, akkor egyszerűen úgy kell mozgatni az eszközt, hogy a fekete test egy adott kamera szélességbe (mondjuk a középső 30%-ba) ne lógjon be. Jobb módszer, ha a látottak alapján virtuális térképet készítesz, de ez egyrészt bejárást igényel, másrészt távolságokat kell valahogy számolni)
2) Távolságot csak úgy tudsz mérni, ha
a) tudod mekkora a tárgy
b) nem fix a kamera fókusza (akkor a objektív állásából + élességből) tudsz következtetni a távolságra
c) 3D-s kamera-rendszernéll a két kamera látószöge alapján lehet számolni a távolságot
d) elmozdulsz és nézed a tárgy növekedését/csökkenését. Ha a te elmozdulásod mértékét tudod, onnan tudsz következtetni a tárgy távolságáta/méretére.
AE
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
Előjönnek azok az idők, amikor a Robotinoval szórakoztam - nem tudom valakinek mond-e ez valamit... Ott mondjuk nem kellett javaban programozni és a távolságot infra mérte ki, de akkor is szép idők voltak 
"Nem adom fel mert lehet, hogy holnap lesz az én napom"
Megint elakadtam egy kicsit: beágyazott osztályok. Ahány helyen nézem, annyiféle leírást találok. A mellékelt példák többnyire hasonlóak, de a magyarázatok...
Azt kb. felfogtam, hogy a segítségükkel olyan objektumot tudok visszaadni egy metódusból, ami hozzáférhet az adott osztály/példány privát tagjaihoz. (hmmm... mire megfogalmazom, mit akarok kérdezni, még meg is értem? ) Ezért, erre találták ki a beágyazott osztályokat?
Viszont gondot okoz a könyvem egy mondata: "... az így létrejövő objektum dinamikusan kapcsolódik a metódusban éppen érvényes aktuális példányhoz, és ez a kapcsolat a metódus elhagyása után is fennmarad."
Ezt itt nem értem. Az OK, hogy ha az adott metódus visszatérési értékként vagy egy osztály/példányváltozóban visszaad egy ilyen objektumot, az megmarad. De ez (számomra) teljesen logikus. Miért van mégis hangsúlyozva ez a kapcsolat? Valamit félreértek és egyéb jelentősége van?
-------
Ha van egy ilyen interface-em:
interface A { void x(); }
Akkor az őt implementáló osztály x metódusánál miért reklamálja az Eclipse a "public" jelzőt?
Egy belső osztályt akartam így leírni, de a
class O implements A { void x(){ ... } }
nem tetszett neki. Csak így fogadta el:
class O implements A { void public x(){ ... } }
Eztakkormostmért? 
Nézd meg, hogy tudnál külső osztályból létrehozni egy másik osztályba ágyazott osztályból egy példányt.
package javaapplication1;
class A{
class B{
}
static class C{
}
}
public class Main {
public static void main(String[] args) {
A a = new A();
A.B b = a.new B();
A.C c = new A.C();
}
}
Mint láthatod, ha nem static nested classról van szó, akkor kell egy példány először a beágyazó osztályból. Ezért b által hivatkozott objektum kapcsolódik a által hivatkozotthoz.
--------------------------------------------------
Az interface-szes problémára: Egy interface minden függvénye impliciten public elérésű. Felülírási szabály szerint pedig nem szűkítheted egy függvény elérését (ezesetben publicról defaultra).
[ Szerkesztve ]
Interface-ben hamegadsz egy metodust, az implicit abstracs és public mást nem is lehet megadni interface-en belül. Ha viszont az osztályba nem írod ki a pulblic-ot akkor csomagon belül ugyan publikus, de csomagon kívül privát és ez a viselkedés nem egyezik meg a puliblic-kal, hanem annak szűkítése, ami nem megengedett...
"Nem adom fel mert lehet, hogy holnap lesz az én napom"
Köszi mindkettőtöknek! Mondjuk az interface dolog végeredményben logikus, csak végig kellett volna gondolni, hamár a korábban olvasottakról megfeledkeztem.
Amit a beágyazott osztályról írtál, az tiszta.
Nekem az nem világos, hogy egy egyébként triviálisnak mondható dolgot miért kellett ennyire kihangsúlyozni? Na mind1, a könyvemben vannak még hasonló furcsaságok
Üdv, szeptemberben fog megjelenni az Agyhullám(Head first) Java könyv melegen ajánlott minden Java-t tanulónak beszerezni ,kezdők számára talán messze ez a legjobb könyv a témában.
Még mindig a beágyazott osztályok és a kis Java könyvem...
Írtak a könyvben valami olyat, hogy egy belső osztályt is lehet, akár külső osztály által is bővíteni. Nem statikusat is.
Itt ugye vagy én értettem félre valamit, vagy a szerző tévedéséről van szó?
Még valami eszembe jutott: ha arra vetemednék, hogy mobiltelefonra próbáljak összetákolni valami egyszerűbb java programot... Van már szabványos fejlesztőkörnyezet hozzá vagy még mindig úgy kell összevadászni valami SDK-t/JDK-t minden egyes telefonhoz? (költői túlzás, de amikor évekkel ezelőtt megfordult a fejemben valami hasonló, akkor kb. az volt a helyzet, hogy a Siemens telefonomhoz csak a siemens-es anyaggal lehetett programot készíteni)
regota van mar J2ME. Annak mennie kell a J2ME kompatibilis telokon.
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
Azt tudom, az már létezett akkor is, amikor el akartam kezdeni játszani vele. De kellett mellé a telefonhoz valami SDK is, ami úgy fest, most is szükséges. Vagy valamit félreértek, de nagyon: nokia.com-on találtam egy topic-ot, ahol jónéhányan panaszkodtak, mert a mai napig nincs linuxos SDK a nokiákhoz... mindenesetre az Eclipse követelne valami SDK-t, amit windows-on még csak-csak alá tudok tolni, de én inkább linuxon jáccanék.
hat en anno csak szimpla szoveges menus alkalmazasokkal szorakoztam, de emlekeim szerint a j2me eleg volt. Bar elofordulhat hogy rosszul emlekszem....
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
Majd még keresgélek, hátha kiderül valami érdemleges. Igazából előbb kérdeztem itt, utána kezdtem a gúgliban turkálni. A turkálás eredménye, hogy valószínűleg még most is kell SDK, csak azt nem tudom, hogy mindenhez vagy csak ahhoz, hogy az adott mobil spec. képességeit is használni lehessen. (mondjuk egy java szoftver esetében nem értem, miért kellene bármi platformfüggő dolog akár a fejlesztéshez, akár a teszeléshez)
Sokadszorra végignézve a dolgot, mégsem értettem félre és a szerző sem tévedett. Az Eclipse hibaüzenetét nem sikerült értelmeznem.
Javat szerintem ne erőltesd telefonokon. Ha ilyen irányba akarsz elmozdulni, akkor döntened kell, hogy Iphone vagy Android. Iphone-nal nincs tapasztalatom, androidra viszont elég gázos a fejlesztés. Verziónként külön sdk, gagyi programnyelv és api, nincs fix programbelépési pont csak repkednek az események, xml descriptorok, bugos emulátor (de csak hogy könnyebb legyen a fejlesztés) ... Szóval elég hulladék. Lehet, hogy mint end user, nagyon látványos tapogatni az ikonokat a telefonon, de fejleszteni rá ... 
[ Szerkesztve ]
Ne gondolj semmi komoly dologra! Csak unatkozom és kellene valami olyan játék, amivel kicsit az agyműködésemet fenntartom. Sakkozni, go-t tanulni már nincs kedvem. 
Java mobilra azért lenne jó, mert az _elméletileg_ platform független és legalább írhatnék egy olyan reversit, ami úgy működik, ahogy én szeretném. 
Ha unatkozol, tanulj Java EE-t. Mostanában jól meg lehet belőle élni, előzetes tapasztalat nélkül is. 
EE=Enterprise Edition?
Köszi a tippet, de bizonyos... khm... objektív okok miatt nem nagyon fogok megélni programozóként...
(bár tény: épp a napokban állapítottam meg, hogy mégis meg kellett volna maradnom a programozói pályán, de anno izgalmasabb dolognak tűnt a rendszergarázdálkodás )
Bár ahogy elnézem, hogy a wikipedia szerint mit takar az EE... annyira nem állna távol tőlem és legalább üzemeltetői szemmel írnám a programokat. (inkább a felhasználó anyázzon, mint az üzemeltető felkiáltással 
)
Jé, még tud valóban újat mutatni a Java: ezek a Generikusnak nevezett bigyók (alias Generics) mennyire használatosak a hétköznapi gyakorlatban? Valószínűleg szegényes a fantáziám, vagy félreértem a funkcióját, de egyelőre kicsit nehezen találok a használatára igazán életszerű példát.
Viszonylag gyakran előkerülnek. Gondolj pl a tárolókra, mint a Vector, HashMap, LinkedList, ... vagy pl TypedQuery JPA-ban. De saját generikus class-t vagy interface-t is sokszor kell írni. Ezekkel a generikusokkal megspórolható egy csomó castolás, így gyorsabb a program.
[ Szerkesztve ]
Gondolhatok rájuk, de ott még nem tartok a tutorialban...
Köszi.
(viszont egyre inkább úgy érzem, hogy totál felesleges erőlködés ez a "tanulás", mert hiányzik a háttér)
Nem tudom miért, de valami olyan érzésem van most, hogy kissé kiművelődtem generikus ügyekben, mint amikor a perl-ben megláttam az objektum orientált eszközöket: mintha a fejlesztők megerőszakolták volna a nyelvet...
Tartok tőle, hogy valami kimaradt az életemből...
public static <U> void fillBoxes(U u, List<Box<U>> boxes) {
for (Box<U> box : boxes) {
box.add(u);
}
}
A fenti kódban a <U> void fillBoxes( részt hogy kell értelmezni?
Mit keres az az U a void előtt? 
jelzi, hogy az U-t nem mint tipust kell ertelmezni, hanem az generikus.
''Gee, Brain, what do you want to do tonight?'' ''The same thing we do every night, Pinky: Try to take over the world!''
Na ezt pontosan annyira értem, mint a kódot.
Mondom: szerintem valahol, valami kimaradt (vagy a sun tutorialból vagy csak az olvasásból).
Ha jól értem, az <U> helyére szintaxis szerint akár <Krixkrax>-t is írhatnék, csak az olvashatóság, könnyebb felismerhetőség miatt ajánlott az egyetlen nagybetűs jelölés.
Mi a funkciója ezesetben a void előtti <U>-nak? Mi van, ha elhagyom?
Ezt bogarászom, de számomra nem igazán derül ki belőle.
------------------
szerk:
Újra végigolvasva: úgy értsem, hogy a metódus definíció fejében definiálom az "U" típust/osztályt a fordító számára, hogy ne keresse máshol?
[ Szerkesztve ]
Na, jólvan, kezd tisztulni... (nem félálomban kellene ilyesmivel foglalkoznom. )
Az U szerepe rendben, már csak a List<Box<U>> maradt függőben.
Ahogy a linkelt oldalon is látható, a Box egy generikus osztály és tartalmaz t névvel egy változót:
...
private T t;
...
Az add függvény ennek a t-nek adna értéket. A fillBoxes pedig átvesz egy listát, amiben Boxok vannak és minden Boxhoz hozzáadja u-t. De nyilván tudnia kel, hogy mi a típus. Ez lesz az a típus, amit U helyére írsz be.
[ Szerkesztve ]
Ez részben tiszta.
Nekem a List és az egymásbaágyazott generikus definíciók zavarnak be egy kicsit. Főleg, hogy a List-ről csak annyit tudok, hogy van, de nem láttam sehol az ő definícióját.
Ezt a metódust úgy kell értelmezni, hogy van egy U paramétere, valamint egy olyan, ami a List generikusból, azon belül kizárólag a Box generikus valamely fajtájából származik és megkötés, hogy a Box "altípusa" (nem tudom, erre mi lenne a helyes kifejezés) meg kell egyezzen az első paraméter típusával/osztályával?
"Ezt a metódust úgy kell értelmezni, hogy van egy U paramétere, valamint egy olyan, ami a List generikusból, azon belül kizárólag a Box generikus valamely fajtájából származik és megkötés, hogy a Box "altípusa" (nem tudom, erre mi lenne a helyes kifejezés) meg kell egyezzen az első paraméter típusával/osztályával?"
Igen, valamilyen Box-okat tartalmazó listát vár. Egyébként java.util.List-ként találod meg a listát, ami egy interface. Az implementációi pedig szintén a java.util csomagban találhatók.
[ Szerkesztve ]
Köszi.
Még mindig ezek a generikus témák...
Itt írnak wildcard használatról. Nem látom leírva, hogy a wildcard használat osztálydefinícióban hibás lenne, az eclipse mégis tiltakozik ellene...
Tehát a
class Xxx<T> { ... } működik, de a class Xxx<? extends Number> { ... } már nem tetszik neki. Metódus paraméterei közt elfogadja.
Megint én voltam figyelmetlen/nem értettem meg, hogy mire és hogyan használható ez a dolog?
Sziasztok!
Gondolom nagyon fogjátok unni a mostani szöveget, de laikusként már nincs több ötletem, mint a szívesség kérése. Igazából sok fogalmam nincs a Java-hoz, csak amit autodidakta módon összekapartam, és ez sajnos elég kevés.
Honlapot barkácsolok, és a táblázat egyik cellájába szeretnék megjeleníteni órát - ezt eddig össze is tudom ollózni a netről- viszont szeretném annyival megbolondítani a dolgot, hogy amennyiben a kurzort az óra fölé húzom, akkor a dátum jelenjen meg.
Egy komplett kódnak nagyon tudnék örülni ( a dátum/óra lekérdezését szerintem meg tudom oldani, csak a többi nem akar sikerülni).
[ Szerkesztve ]
Ehhez Javascript kell annak meg semmi köze a Java-hoz. Javascript topikban érdeklődj utána.
Ezt egyre kevésbé értem. A java fordítóm (Sun JDK 1.6) is tiltakozik ellene, tehát valóban nem stimmel amit elképzeltem. Ugyanakkor a neten találtam olyan példát, ami szerint működnie kéne. Persze ha azt bemásolom, akkor sem megy.
Na mind1, elfogadom, hogy ez van.
Van itt valaki, aki érti a hivatkozott hozzászólásomban vázolt "súlyos" problémámat?
Ha igen: nem lehet, hogy marhaságot akartam ráerőszakolni a java-ra?
Amikor írtam még úgy éreztem, hogy értem mit akarok. Azóta kissé elbizonytalanodtam: jelenleg értelmetlennek tűnik az elképzelés, hogy osztálydefinícióba wildcardot tegyek...
Az a baj, hogy már nem tudom eldönteni: akkor voltam belekavarodva az info áradatba, vagy most (hogy már értelmetlennek tűnik) kutyultam össze valamit. 
Amit te akarsz, azt így lehet megoldani:
class A<T extends Valami>{...}
?-t nem használhatsz osztály és metódus megadásakor (csak metódus paraméterlistáján belül).
Igen, azzal nincs gond... per.pill. az zavar, hogy nem tudom, honnan jött az eredeti, wildcard-os ötlet. Így utólag hülyeségnek tűnik.
(azt leszámítva, hogy találtam rá konkrét, lefordíthatatlan példát a neten, csak sajna töröltem a címét is, a programot is)
Asszem, megvan a bűnös:
To specify a cage capable of holding some kind of animal:
Cage<? extends Animal> someCage = ...;
Egy ilyen szerepel a sun-os tutorialban a wildcard-os lap elején. Én meg ahelyett, hogy végiggondoltam volna, mire jók ezek a generikusok, csak az általam elképzelt szintaxist néztem. Ha értékadás baloldalán, tehát változó definíció helyén állhat ilyen, akkor miért ne lehetne akár metódus vagy osztály típusát is megadni?
Végiggondolva a funkcióját, természetesen érthető(nek tűnik ), hogy ott nincs keresnivalója.
[ Szerkesztve ]
Arra tudna valaki magyarázatot adni, hogy a swing-es programokat miért írják a példákban úgy, hogy a grafikát megjelenítő objektum önálló szálként fut?
Lehet, hogy keverem az awt és a swing dolgait, de nem emlékszem rá, hogy ez kötelező lenne...
Talán, h bonyolultabb számítás, vagy lassabb erőforrás elérés esetén se legyen az h nem válaszol az ablak, meg nem látszik rajta semmi...
"Nem adom fel mert lehet, hogy holnap lesz az én napom"
Nem mondhatnám, hogy értem amit írsz...
(pontosabban azt, hogy mi köze a problémámhoz - itt most kimondottan példaprogramokról van szó)
public static void main(String[] args) {
//Schedule a job for the event-dispatching thread:
//creating and showing this application's GUI.
javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI();
}
});
}
Szinte minden példaprogram, ami swinghez kapcsolódik, így indul.
Miért nem elég csak statikusan indítani a createAndShowGUI-t?
Az, hogy belül egyik-másikhoz új szálat indít, az egy másik téma. Azt nem értem, hogy miért kell a main futásától "függetleníteni" bármit?
Azt hiszem, megvan a magyarázat.
javax.swing.SwingUtilities.invokeLater(new Runnable() { .. }
Fontos ,hogy kirajzolásokat az EDT szálon hajtsuk végre, más esetben hiba léphet fel (nomeg a grafikai műveletket meg kell próbálni függetleníteni a számításoktól, ezért kell külön szál).
Az invokeLater biztosítja, hogy a kirajzolás EDT szálon hajtódik végre. (Ugye paraméterben egy Runnable-et adsz át, a run() metódus tartalmazza a grafikai parancsokat).
Le is tudod ellenőrizni ,hogy a kirajzolás EDT-n történik-e, az isEventDispatchThread() függvény meghívásával , logikai értéket ad vissza.
Remélem hasznos volt,bár látom utánajártál.
[ Szerkesztve ]
Elvették a radírját, azt az egész élete egy nagy kompenzálás, hogy ő igenis kan és igenis 2 méteres a fallosza - by stranger28
Hogy utánajártam, az költői túlzás, de végülis igen...
Sziasztok. Kezdőknek milyen könyvet tudtok ajánlani, vagy hogyan kezdjek el tanulni? C-hez elég jól értek szóval alapok megvannak 
C vagy C++?
Előbbinek nem sok hasznát veszed, attól tartok. Ha az angol nem okoz gondot, akkor The Really Big Index
Illetve egy Nagy Gusztáv (remélem, jól emlékszem) nevű tanár írását is érdemes megkeresni. Itt a topic-ban is ajánlották. Igaz, az még 1.3-as javaról szól és nem ír pl. a swing-ről...
[ Szerkesztve ]
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
