továbbfejlesztés - címke - Oldal 5 a 5-ből

Dr. Sheldon Cooper szólánc játéka

2025. június 15.2020. április 1. Szerző: Kaczur Sándor

Dr. Sheldon Cooper karakterét nem kell bemutatni. Az Agymenők (The Big Bang Theory) című sorozat 2. évad 5. epizódjának címe A vitatkozás nagymestere (The Euclid Alternative). Nagyon találó az epizód címe magyarul. Miközben Penny reggel Sheldont munkába viszi, Sheldon az autóban kémiai elemek nevéből álló szólánc játékával különösen Penny agyára megy (pedig a játékot Penny nyeri ?):

A játék során Sheldon az alábbi kémiai elemeket mondja:

magyar nyelven: Hélium ↦ Mangán ↦ Neptúnium ↦ Magnézium ↦ Molibdén ↦ Nitrogén ↦ Nobélium ↦ Mendelévium
angol nyelven: Helium ↦ Mercury ↦ Ytterbium ↦ Molybdenum ↦ Magnesium ↦ Manganese ↦ Europium ↦ Mendelevium

Támogassuk meg ezt a játékot! Készítsünk olyan programot Java nyelven, ami segít(ene) felkészülni Sheldon szólánc játékára!

A szükséges lépések áttekintése

Gyűjtsük össze a kémiai elemek nevét magyar nyelven a Wikipédia – Kémiai elemek listája szócikkéből és rendezzük ábécé sorrendbe!
Építsük be az elemlistát a program adatmodelljébe!
Indítsuk el a lépésszámláló nulláról! Ha a lépésszámláló páros, akkor az ’A’ játékos, egyébként a ’B’ játékos lép.
Készítsük elő a játékmenet tárolására alkalmas adatszerkezetet, szöveget, listát!
Kezdetben kínáljuk fel a teljes elemlistát úgy, hogy mindig egy és csak egy legyen belőle kiválasztható!
A kiválasztást követően tároljuk el a játékmenetben az elemet, töröljük ezt az elemlistából, majd kínáljuk fel azoknak az elemeknek a listáját, amelyek kezdőbetűje megegyezik az előzőleg kiválasztott elem utolsó betűjével és növeljük meg a lépésszámlálót!
Amíg a felkínálható elemek listája nem üres, addig az előző lépést ismételjük meg!
A játék végén az nyert, aki a játékmenet utolsó elemét választotta ki. Írjuk ki a nevét és a lépésszámot!

A grafikus felületű megvalósítás képernyőképe rövid játékmenettel

Ötletek a megvalósításra és a továbbfejlesztésre

A program Java nyelven konzolos menükezeléssel, asztali alkalmazásként swing-esen többféle GUI komponens használatával és eseménykezeléssel, böngészőben futó JSP webalkalmazásként többféle űrlapmezővel, illetve HTML+CSS+JavaScript alapon is implementálható.
A kémiai elemek listája lecserélhető az angol nevekre. Ekkor figyeljünk arra, hogy a kis- és nagybetűket ne különböztessük meg az utolsó-első betű párosítása során.
Lehet a játék bármikor megszakítható, illetve a vége után újrakezdhető.
A program mérhetné a játék során az eltelt időt.
A program lehetne peer-to-peer vagy szerver-kliens elosztott és megvalósíthatna hálózatos kommunikációt.
A program mobil alkalmazásként is implementálható.

A bejegyzéshez tartozó teljes forráskódot – többféle változatban is – ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

Többféleképpen is hozzájuthatunk az adatokhoz attól függően, hogy milyen előismeretekkel rendelkezünk a különböző tanfolyamainkon:

A Java SE szoftverfejlesztő tanfolyamon dolgozhatunk szövegtömbbel, generikus kollekcióval (listával/halmazzal), konzolos és swing-es változatot is készíthetünk. Ehhez a feladathoz objektumorientált alapok mindenképpen szükségesek. Kézzel előállított szövegfájlból olvasva (mentve a Wikipédia oldaláról a táblázatot) hozzájuthatunk a kémiai elemek nevéhez, amihez kivételkezelés is szükséges.
A Java EE szoftverfejlesztő tanfolyamon megvalósítható, hogy a program kivételkezeléssel hálózati kapcsolatot épít, majd közvetlenül olvassa és/vagy menti a Wikipédia HTML tartalmából a kémiai elemek nevét szövegfájlba vagy generikus kollekcióba, amivel a feladat visszavezethető az SE szemléletű megközelítésre. Böngészőben futó JSP és/vagy Servlet technológiára építő webalkalmazásként is megvalósítható a feladat.

KSH táblázatból dolgozunk

2025. július 27.2020. január 17. Szerző: Kaczur Sándor

A Központi Statisztikai Hivatal honlapján elérhető STADAT táblákból könnyen kinyerhetjük a nekünk szükséges adatokat. A témastruktúrába sorolt online és XLS exportként is böngészhető táblázatokban megtalálhatjuk logikusan csoportosítva összesítve az adatokat régiónként (megyénként), évenként, százalékosan. Az XLS fájlformátum Java nyelven a JExcel API-val hatékonyan feldolgozható. Lássunk erre egy példát!

Feladat

A KSH 2.1.2.35. táblázatából gyűjtsük ki a 19 magyar megyére + Budapestre vonatkozóan a gazdaságilag aktívak létszámát és az első évet alapnak tekintve adjuk meg évenként a változást százalékosan!

Tervezés

A KSH témastruktúrában a táblázat elérési útja:

2. Társadalom,
2.1. Munkaerőpiac,
2.1.2. A munkaerőpiac alakulása Magyarországon (1998–2018) -> Területi adatok,
2.1.2.35. A 15–64 éves népesség gazdasági aktivitása megyénként és régiónként (1998–2018)

Online böngészhető táblázat:
https://www.ksh.hu/docs/hun/xstadat/xstadat_hosszu/mpal2_01_02_35.html.

Letölthető táblázat (XLS formátumban): https://www.ksh.hu/docs/hun/xstadat/xstadat_hosszu/xls/h2_1_2_35.xls.

A táblázat A oszlopában szerepelnek a régiók, megyék, időszakok (vegyesen, szövegként) és a D oszlopában a gazdaságilag aktívak (ezer fő, valós számként). A fejlécet nem szabad feldolgozni. 1998-tól 2018-ig 546 sorból áll az adatsor. A csoportosítás 26 régiót és megyét tartalmaz, amiből a 6 régiót (például: Közép-Dunántúl) ki kell hagyni.

A megyékre vonatkozóan 440 sort kell feldolgozni. Ebből az első sor a megye (vagy Budapest) neve, a többi (2019-ben 21 db) sorban találhatók az adatok (időszak). Olyan algoritmusban érdemes gondolkodni, ami a jövőben is működik. Ha csoportváltást alkalmazunk, akkor nem számít, hogy megyénként minden évben egy sornyival több adat lesz majd. A KSH táblázatok szerkezete nagyon ritkán változik, így bátran írható rájuk testre szabott forráskód (ezeket nem kell évente frissíteni).

Az évenkénti változást százalékosan nem tartalmazza a táblázat, ezt nekünk kell kiszámítani. A valós számok formázását érdemes egységesíteni, például a gazdaságilag aktívak létszámát 3 tizedesre, a változást 2 tizedesre kerekítve.

A belső adatábrázolást érdemes átgondolni. Hasznos, ha az időszakhoz tartozó három összetartozó adatot egyetlen Data POJO-ba fogjuk össze ( String period, double active és double change). Ezeket generikus listába szervezve ( ArrayList<Data> list) könnyen hozzájuk rendelhető a megye ( String county) és ezek együtt alkotják a Region POJO-t. A Region és Data kapcsolati fokszáma: 1:N. 2019-ben N=21 .

Részlet a megoldásból

private List<Region> readXLS() throws IOException, BiffException {

WorkbookSettings workbookSettings=new WorkbookSettings();

workbookSettings.setEncoding("Cp1252");

Workbook workbook=Workbook.getWorkbook(

new File("./files/h2_1_2_35.xls"), workbookSettings); //munkafüzet

Sheet sheet=workbook.getSheet("2.1.2.35."); //munkalap

List<String> skipRegionList=Arrays.asList(new String[] {

"Közép-Dunántúl", "Nyugat-Dunántúl", "Dél-Dunántúl",

"Észak-Magyarország", "Észak-Alföld", "Dél-Alföld"});

List<Region> list=new ArrayList<>();

int i=3; //kihagyjuk a fejlécet

while(i<sheet.getRows()) {

Cell cellA=sheet.getCell(0, i); //megyék

if(cellA.getType()==CellType.LABEL) {

String county=((LabelCell)cellA).getString().trim();

Region region=new Region(county);

i++;

Cell cellD=sheet.getCell(3, i); //gazdaságilag aktívak

while(i<sheet.getRows() && cellD.getType()!=CellType.EMPTY) {

cellA=sheet.getCell(0, i); //időszakok

String period="";

if(cellA.getType()==CellType.LABEL)

period=((LabelCell)cellA).getString().trim();

double active=0;

if(cellD.getType()==CellType.NUMBER)

active=((NumberCell)cellD).getValue();

region.addList(period, active);

i++;

if(i<sheet.getRows())

cellD=sheet.getCell(3, i);

}

if(!skipRegionList.contains(county))

list.add(region);

}

workbook.close();

return list;

}

A JExcel API használatához a Java projekthez hozzá kell adni a jxl.jar fájlt. A XLS fájl olvasható közvetlenül a webről is, de egyszerűbb helyi fájlrendszerbe mentett változatból dolgozni ( ./files/h2_1_2_35.xls). A megyék nevében található ékezetes karakterek miatt ügyelni kell a megfelelő karakterkódolásra ( Cp1252). A munkafüzet azonosítását követően hivatkozni kell a feldolgozandó munkalapra ( 2.1.2.35.). Az adatfeldolgozás során kihagyott régiókat (kivételeket) érdemes listába gyűjteni ( skipRegionList). A csoportváltást a két egymásba ágyazott ciklus valósítja meg. Ügyelni kell az adatok formátumának ellenőrzésére.

Eredmények

Például Somogy megyére az alábbi adatokat kapjuk eredményként (XLS formátumban, Excel-be betöltve, tipikus háttérszín kiemeléssel: szélsőértékek a C oszlopban, negatív értékek a D oszlopban):

További programozható feladatok

Hogyan alakult a magyar autóbuszgyártás 1960-tól évtizedenként csoportosítva (átlag, min, max, szórás)? – 4.2. Ipar (1960–)
Milyen a lakossági építkezés aránya az ezredforduló után a teljes építőipari termelés értékéhez viszonyítva évenkénti bontásban? – 4.3.1. Az országos építőipari termelés értéke kivitelezők szerint (1990–)
Milyen kapcsolat figyelhető meg a szállodák száma és a kiadható férőhelyek száma között a 2008-ban kirobbant gazdasági világválság előtt és után? – 4.5.11. A kereskedelmi szálláshelyek kapacitása, július 31. (2001–)
Melyik években volt a legmagasabb (TOP 3) a saját mobilhálózatba irányuló beszélgetések hossza az összes mobilhálózatba irányuló beszélgetések hosszához viszonyítva? – 4.7.5. A mobilhálózatokból kiinduló beszélgetések (2001–)
Hogyan alakultak az üzemanyagok éves fogyasztói átlagárai (átlag, min, max, szórás)? – 3.6.3. Egyes termékek és szolgáltatások éves fogyasztói átlagára (1996–)
Ábrázoljuk tematikus térképen: hogyan alakult régiónként a munkanélküliségi ráta a mindenkori utolsóként megadott negyedévben az előző év azonos negyedévéhez viszonyítva! – 6.2.1.11. Munkanélküliségi ráta

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A feladat a Java SE szoftverfejlesztő tanfolyam tematikájához kötődik (ha az XLS fájlt a helyi fájlrendszerből érjük el), és a Java EE szoftverfejlesztő tanfolyam tematikájához kapcsolódik (ha az XLS fájl tartalmát közvetlenül a webről olvassuk).

Hóesés szimuláció

2025. június 15.2019. december 18. Szerző: Balogh Péter

Hóesés szimulációt tervezünk és valósítunk meg Java nyelven. A téma igazi örökzöld. Elvileg minden télen aktuális. 😉 A grafikus felülethez és az eseménykezeléshez a swing gyűjteményt használjuk. Adott egy téglalap alakú terület amelyen – méretéhez igazodva – több száz hópehely mocorog. A területet önállóan programoztuk le – azaz ez alkotja a teljes GUI-t –, de lehetne egy nagyobb kép része is. Többféleképpen is beépítünk véletlenszerűséget a szimulációba. Tervezünk is, hiszen az sosem árt. 😉

Többnyire beépített komponenseket, elemeket használunk, de van saját, örökítéssel testre szabott komponensünk is:

A szimuláció a Window osztályból példányosított felületen működik, amely JFrame utód. Nem átméretezhető és látható.
A területet JPanel típusú pnTransparentWindow alkotja. Mérete 300*200 pixel. Színe a szürke egyik árnyalata. Ezen mozognak a hópelyhek.
A hópehely Snowflake típusú JPanel utód. Mérete 2*2 pixel. Színe fehér. Saját swing-es Timer biztosítja az eseménykezelését. A szimulációban 600 hópehely szerepel.

Az elkészült szimuláció

A teljes forráskódból íme a hópehely megvalósítása

public class Snowflake extends JPanel {

private Rectangle rectangle=null;

private Dimension size=new Dimension(2, 2);

private int delay=(int)(Math.random()*5+1)*50

private Timer timer=new Timer(delay, (ActionEvent e) -> {

move();

});

A hópehelynek „tudnia kell” hol van, azaz mekkora területen mozoghat, ez a rectangle. A hópehelynek van size mérete. A hópehely saját magát mozgatja a területen a timer segítségével. Az időzítés várakoztatására/késleltetésére vonatkozó delay értéke véletlenszerűen 50, 100, …, 250 milliszekundum lehet. Másképpen: a szél által össze-vissza fújt hópelyhek között lehetnek lassabban és gyorsabban mozgók is. Az eseményobjektumhoz lambda kifejezés rendeli hozzá a reakciót jelentő, mozgást megvalósító move() metódus meghívását, amely így adott időközönként bekövetkezik.

public Snowflake(JPanel pnTransparentWindow) {

rectangle=pnTransparentWindow.getBounds();

setPreferredSize(size);

int x=(int)(Math.random()*rectangle.width);

int y=(int)(Math.random()*rectangle.height);

setBounds(x, y, size.width, size.height);

setOpaque(true);

setBackground(Color.WHITE);

timer.start();

}

A hópelyhet a konstruktora hozza létre. Átveszi azt a pnTransparentWindow területet, amelyre később rákerül a Window példányosítása során. A gyengébb setSize() metódus helyett az erősebb setPreferredSize() metódus állítja be a méretet. Véletlenszerű x és y pozícióba kerül ki/fel a területre. A setBounds() örökölt metódus beállítja a pozícióját és méretét. Erre épít a fogadó oldalon az abszolút helyzet, külön elrendezésmenedzser nélkül. Végül a hópehely átlátszó, fehér és elindítja saját időzítőjét a timer.start() metódushívással.

Az időzítés/várakoztatás véletlenszerűsége után íme a második véletlenszerűség a szimulációban. A hópehely mozgása során a szél által össze-vissza fújva eltérő eséllyel/valószínűséggel mozog 8 lehetséges irányba az alábbiak szerint:

5-5% eséllyel felfelé, azon belül jobbra vagy balra (átlósan),
10-10% eséllyel jobbra vagy balra,
20-20% eséllyel lefelé, azon belül jobbra vagy balra (átlósan),
30% eséllyel lefelé, függőlegesen,
felfelé, függőlegesen nem mozog.

Az esélyek összege 100%. Másképpen kulcsszavakban: 1 = biztos esemény (teljes eseménytér, nincs más lehetőség), egymást kizáró események, geometriai valószínűség. A képen középen lévő hópehely a 8 szomszédja közül a 7 szóba jöhető közül valamelyikre adott eséllyel mozog. A geometriai valószínűséget az ábra alapján az óramutató járásával megegyezően leképeztük az 1..100 intervallumra:

public void move() {

Point location=getLocation();

int tip=(int)(Math.random()*100+1); //1-100

if(1<=tip && tip<=5)

location.translate(size.width, -size.height); //jobbra fel

else if(6<=tip && tip<=15)

location.translate(size.width, 0); //jobbra

else if(16<=tip && tip<=35)

location.translate(size.width, size.height); //jobbra le

else if(36<=tip && tip<=65)

location.translate(0, size.height); //le

else if(66<=tip && tip<=85)

location.translate(-size.width, size.height); //balra le

else if(86<=tip && tip<=95)

location.translate(-size.width, 0); //balra

else //96<=tip && tip<=100

location.translate(-size.width, -size.height); //balra fel

if(rectangle.height<location.y)

location.translate(0, -(int)location.getY());

setLocation(location);

}

A move() metódus megvalósítja a fenti tervnek megfelelően a hópehely mozgatását. Első lépésben tudni kell a jelenlegi/kiinduló location helyét (a bal felső csúcs, elkérjük). Ezután véletlenszerű esély/ tip generálódik. Az első elágazásban a hópehely translate() metódusával eltoljuk az előbb elkért pontot. Az eltolás relatív. Az utolsó elágazásban kompenzálunk, ha a hópehely alul kilépne a területről. Ekkor felül újra belép a területre. Végül beállítjuk a hópelyhet megvalósító komponenst a manipulált location helyre.

Takarékosak vagyunk: ezzel a megoldással „újrahasznosítjuk” a hópelyheket. Csak annyi van belőlük, amennyi szükséges. Nem kell őket folyamatosan megszüntetni és újra létrehozni. Nem mozognak feleslegesen. Nem mozognak olyan területen, ahol nem láthatóak.

Ötletek továbbfejlesztésre

A hópelyhek színe lehetne véletlenszerű a fehér és a középszürke között. Ezzel a nézőtől való távolságot, esetleg a kép élességét lehetne modellezni.
A szél nem feltétlenül szimmetrikus, vagy a hópelyhek mozgatását meg lehetne oldani jobbra és balra eltérő eséllyel is.
A terület lehetne más alakú, például trapéz, íves, kör, ellipszis.
Másképpen is vezérelhetnénk a szimulációt. Ahelyett, hogy most minden hópehelynek van saját időzítője, lehetne csak 5 db (lassabbak és gyorsabbak), amelyek közül véletlenszerűen kiválaszthatnánk, hogy melyik hatására mozgatjuk az adott hópelyhet. Fordítva is mehetne: az 5 db időzítőhöz előre hozzárendelhetnénk a hópelyheket. Ez így más-más felelősség, kommunikáció, üzenetküldés, vezérlés lenne az objektumok között. Hasznos tapasztalat lehet megvalósítani bármelyiket.
A terület lehetne egy nagyobb kép része. Például meghatározhatnánk egy tetszőleges átlátszóságot (színt vagy arányt) és többrétegű felületet megvalósítani képes JLayeredPane komponens elé vagy mögé is elhelyezhető lehetne a terület a grafikus felületen.
Aki kihívást keres: illessze a területet az alábbi hangulatos képre úgy, hogy a középső ablakok téglalap alakúak, a két szélső trapéz alakú vagy perspektivikus nézetű és a kör/ellipszis alakú tükörben pedig tükröződik valahonnan a hóesés látványa.
Még bátrabbaknak: a kandallóban lévő tüzet is lehet hasonlóan szimulálni. Itt már többféle fizikai paraméter is figyelembe vehető, például fényerősség, tükröződés. Egy 3D modellezett térben a sugárkövetés (Ray Tracing) algoritmus is megvalósítható. A hópelyheknél lehetne az egyszerű mozgástól eltérő más fizikát is programozni: rugalmas ütközéssel összetapadhatnának vagy rugalmatlan ütközéssel lepattanhatnának egymásról és mindez hathatna a sebességükre is.

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A Java SE szoftverfejlesztő tanfolyamunkon, a szakmai modul Objektumorientált programozás témakörét követő 29-36. óra Grafikus felhasználói felület alkalmain már tudunk egyszerűbb szimulációs programot tervezni, kódolni, tesztelni.

Denevérek a barlangban

2025. június 15.2018. július 6. Szerző: Kaczur Sándor

Évekkel ezelőtt hálózatos Java EE esettanulmányt akartunk készíteni Lengyel Borisz kollégával. Ötleteltünk: milyen technológiával és hogyan kommunikáljon egymással a szerver és a kliens(ek). A távoli metódushívás (Remote Method Invocation) mellett döntöttünk és elkészült a denevérek a barlangban projekt, amely evolúciós projektként azóta több változatot is megélt. A felhasználói felület (barlang) betölt néhány képet (denevér kliensek), amelyek a szerver segítségével mozognak.

Ismertetjük a tervezés folyamatát, a kliens és szerver funkcióit részletesen, végül ötleteket adunk a továbbfejlesztésre.

A főbb feladatokat így határoztuk meg:

az RMI kommunikációs módszer megismertetése,
az RMI szolgáltatás reprezentálása látványos grafikus/swinges klienssel,
alternatíva nyújtása a TCP protokoll közvetlenül csatlakozó socket-jére.

Elkészítettük az alábbi osztálydiagramot (persze ez nem az első változat):

A szerver és kliens funkcióit megvalósító osztályok/interfészek feladatait így határoztuk meg:

BarlangDenevérInterfész interfész:

véletlen 5 és 10 közötti a denevérek száma,
méretek a GUI-hoz.

Denevér osztály:

megvalósítja az RMI kliens funkciót,
JLabel leszármazott, külső képfájlt tölt be ( bat.jpg),
egyedi azonosítója van,
eldönti mozgásának irányát (4) és léptékét (3), mintha ultrahangot adna,
a szerver megadja neki, hogy az új helyre elmozdulhat-e,
saját magát képes mozgatni.

Pozíció interfész:

öröklődik a java.rmi.Remote interfészből,
két távolról hívható metódus fejét tartalmazza.

BarlangSzerver osztály:

megvalósítja az RMI szerver funkciót,
implementálja a Pozíció interfészt,
JFrame leszármazott,
figyel arra, hogy a denevérek ne mozogjanak ki a barlangból.

BarlangFelület osztály:

JFrame leszármazott,
GUI az RMI kliensek megjelenítéséhez.

BarlangSzerverTérkép osztály:

JPanel leszármazott,
GUI a szerveren a kliensek mozgásának követésére.

Ha futtatjuk az elkészült szerver és kliens programot, akkor ezt láthatjuk:

A fejlesztés és tesztelés közben sok-sok továbbfejlesztési ötletet/javaslatot fogalmaztunk meg:

háttérkép a barlangról,
a háttérkép megvalósíthat labirintust, koordináta-rendszert,
átlátszó illetve egyedi képfájlok a denevéreknek,
a denevérek mozgásának tetszőleges iránya (360°),
a denevérek mozgásának egyedi léptéke,
a denevérek figyeljenek egymásra (ne ütközzenek össze),
a denevérek figyeljenek a környezetükre (ne ütközzenek bele sziklákba, cseppkövekbe),
a szerver követheti a denevérek útvonalát,
a szerver archiválhat, szerializálhat, készíthet statisztikát.

A bejegyzéshez tartozó – több lépésben továbbfejlesztett – forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

A feladat a Java EE szoftverfejlesztő tanfolyam 21-24. óra: RMI alapú kommunikáció alkalmához kapcsolódik.

Kígyókocka grafikus felületen

2025. június 15.2017. augusztus 18. Szerző: Kaczur Sándor

A JavaFX grafikus felhasználói felületének és eseménykezelésének megvalósítása némileg eltér más Java GUI implementációk működésétől, például swing vagy Java3D. Főként animációk során hasznos használni. Megközelítése természetesen objektumorientált: a térbeli objektumok koordinátái, viselkedésük, transzformációkkal valósul meg, és azok is objektumok. A korábban elkészített konzolos kígyókocka programot valósítjuk meg most JavaFX GUI-val.

Ez egy két részből álló blog bejegyzés 2. része. A blog bejegyzés 1. része itt található.

A program működése

A program megvalósítása

A start() JavaFX életciklust indító eljárás felépíti a createGridUI() függvényt meghívva a felhasználói felületet (színpad/jelenet JavaFX-ben), beállítva a méreteket, címsort, és meghívja az eseménykezelésért felelős handleRotateButtons() eljárást.

@Override

public void start(Stage stage) {

StackPane root=new StackPane();

root.getChildren().add(createGridUI());

Scene scene=new Scene(root,

DRAW_AREA.getWidth()+160, DRAW_AREA.getHeight()+146);

stage.setTitle("Snake cube 2.0");

stage.setScene(scene);

stage.setResizable(false);

stage.show();

handleRotateButtons();

}

A createGridUI() függvény a grafikus felhasználói felület elemeit paraméterezi (szerepe szerint Factory metódus). Öt elemből álló rács ( GridPane osztályú grid nevű objektum) készül el, amelyre nyilakat tartalmazó nyomógombok (pl.: Button típusú btLeft objektum) kerülnek fel a négy égtájnak megfelelően, valamint rajta középen helyezkedik el a kígyókocka 3D megjelenítését megvalósító objektum. A nyilak entitásai az Unikód karaktertáblából származnak. A kígyókocka objektumot a meghívott createSnakeCube() függvény hozza létre. A Node osztályú snakeCube nevű objektum geometriai transzformációs objektumot is hozzá kell rendelni: ez most a négyirányú forgatást megvalósítani képes névtelen Rotate osztályú objektum lesz. A forgatást 5 paraméterrel célszerű beállítani (van rá megfelelő túlterhelt konstruktor), ezek rendre: szög, X, Y, Z tengely origója és a forgatás tengelye. Az objektumok tulajdonosi hierarchiája swing-es szemmel nézve szokatlannak tűnik, de szemléletben legalább azonos a Java3D és a JavaFX megvalósítás.

private GridPane createGridUI() {

String textStyle="-fx-font-size:32; -fx-text-fill: blue";

btUp.setStyle(textStyle);

btDown.setStyle(textStyle);

btLeft.setStyle(textStyle);

btRight.setStyle(textStyle);

GridPane grid=new GridPane();

grid.setHgap(10);

grid.setVgap(10);

grid.add(btUp, 1, 0);

GridPane.setHalignment(btUp, HPos.CENTER);

grid.add(btLeft, 0, 1);

grid.add(btRight, 2, 1);

grid.add(btDown, 1, 2);

GridPane.setHalignment(btDown, HPos.CENTER);

Pane drawSnakeCube=new Pane();

drawSnakeCube.setPrefSize(

DRAW_AREA.getWidth(), DRAW_AREA.getHeight());

grid.add(drawSnakeCube, 1, 1);

snakeCube=createSnakeCube();

snakeCube.getTransforms().add(

new Rotate(30, ORIGO.getX(), ORIGO.getY(), 0,

new Point3D(1, 1.5, 1.5)));

drawSnakeCube.getChildren().add(snakeCube);

return grid;

}

A createSnakeCube() függvény előállítja a színpadra/jelenetbe kikerülő kígyókockát Node osztályú objektumként. A konstans CUBE tömb egységvektor rendszerben tartalmazza a kígyót alkotó kockák középpontjait. Az első ciklus mindezt nagyítást alkalmazva skálázza. A második ciklus koordináta és pont transzformációk alkalmazásával ( moveToMidPoint: eltolás középre, rotateAroundCenter: forgatás a középpont körül) a kiinduló állapotnak megfelelő méretben és pozícióban elhelyezi a kígyó útvonalát mutató hengerobjektumokat. A konstrukciós és transzformációs műveletek esetén alkalmazkodni kell ahhoz, hogy a JavaFX koordinátarendszerben az X jobbra, az Y lefelé, a Z pedig befelé (a nézőponttól távolodva a térben) növekszik. A matematikai hátteret részletesen most nem magyarázzuk el.

private Node createSnakeCube() {

final int SCALE=100;

final Point3D Y_AXIS=new Point3D(0, 1, 0);

final int[][] CUBE=new int[][] {

{-1, 1, -1}, {0, 1, -1}, {1, 1, -1}, {1, 1, 0},

{1, 1, 1}, {0, 1, 1}, {-1, 1, 1}, {-1, 0, 1},

{-1, -1, 1}, {0, -1, 1}, {0, 0, 1}, {1, 0, 1},

{1, 0, 0}, {1, 0, -1}, {0, 0, -1}, {-1, 0, -1},

{-1, -1, -1}, {-1, -1, 0}, {-1, 0, 0}, {-1, 1, 0},

{0, 1, 0}, {0, 0, 0}, {0, -1, 0}, {0, -1, -1},

{1, -1, -1}, {1, -1, 0}, {1, -1, 1}

};

Point3D[] cube=new Point3D[CUBE.length];

for(int i=0; i<cube.length; i++)

cube[i]=new Point3D(

CUBE[i][0]*SCALE, CUBE[i][1]*SCALE, CUBE[i][2]*SCALE);

Group group=new Group();

for(int i=0; i<cube.length-1; i++) {

Point3D p1=cube[i];

Point3D p2=cube[i+1];

Point3D diff=p2.subtract(p1);

double height=diff.magnitude();

Point3D mid=p2.midpoint(p1);

Translate moveToMidpoint=new Translate(

ORIGO.getX()+mid.getX(), ORIGO.getY()+mid.getY(), mid.getZ());

Point3D axisOfRotation=diff.crossProduct(Y_AXIS);

double angle=Math.acos(diff.normalize().dotProduct(Y_AXIS));

Rotate rotateAroundCenter=

new Rotate(-Math.toDegrees(angle), axisOfRotation);

Cylinder c=new Cylinder(5, height);

c.getTransforms().addAll(moveToMidpoint, rotateAroundCenter);

group.getChildren().add(c);

}

return group;

}

A handleRotateButtons() eljárás a forgatás 4 nyíl eseménykezelésének hozzárendelést végzi el. A nyomógomb objektumok setOnAction() hozzárendelő metódusának paramétere EventHandler funkcionális interfésszel és lambda művelettel működik. A forgatás irányát hozzárendeljük a megfelelő nyomógombhoz. Ez még csak végrendelkezés a jövőre: csak definiáljuk, hogy minek kell majd történnie, ha bekövetkezik az esemény (valamelyik nyílra/nyomógombra kattint a felhasználó).

private void handleRotateButtons() {

btUp.setOnAction((event) -> { rotateSnake(Pos.TOP_CENTER); });

btDown.setOnAction((event) -> { rotateSnake(Pos.BOTTOM_CENTER); });

btLeft.setOnAction((event) -> { rotateSnake(Pos.CENTER_LEFT); });

btRight.setOnAction((event) -> { rotateSnake(Pos.CENTER_RIGHT); });

}

A rotateSnake() eljárás minden nyíl feliratú nyomógombra kattintva reagál a bekövetkezett eseményre. A rotateAxis objektum a forgatás tengelye, a paraméterként átvett direction enum-tól függ, szinkronban azzal a nyomógombbal, amelyikre kattintott a felhasználó.

Ötletek a továbbfejlesztésre

Lehetne többféle irány is, például a négy sarokba átlós vagy mélységi irányú elforgatással.
Beépülhetne többféle transzformáció is, például skálázás (kicsinyítés, nagyítás), eltolás (közelítés, távolítás).
A kígyó útvonalát mutató hengerobjektumok kirajzolásának sorrendjén lehetne változtatni, mert a megjelenítés nem tökéletes. Jelenleg néhány helyzetben lehetetlennek, Escher lehetetlen konstrukcióihoz hasonlónak tűnhet a kígyókocka. Ha a tér mélységéből a nézőpont felé közeledve rajzolnánk ki a hengerobjektumokat, akkor a 3D látvány nem sérülne.

Tanfolyamainkon JavaFX grafikus felülettel hangsúlyosan nem foglalkozunk, de egy-egy kész forráskódot közösen megbeszélünk, és össze is hasonlítjuk a swing-es változattal. Fejlesztünk játékprogramot, de inkább konzolosan, vagy swing-es ablakban, vagy webes alkalmazásként.

A grafikus felületek felépítésének megismerése fontos lépcső az objektumorientált programozás elmélyítéséhez, gyakorlásához. A grafikus felületekhez egy másik lényeges szemléletváltás is kapcsolódik, hiszen a korábbi algoritmusvezérelt megközelítést felváltja az eseményvezérelt (eseménykezelés).

Tudatosan hangsúlyozott MVC-s projektben megoldva a feladatot, a modell rétegben tárolhatnánk többféle kígyókocka megjelenítéséhez és animációjához szükséges adatszerkezetet és transzformációs objektumokat/metódusokat is és a nézet/vezérlő rétegekben biztosíthatnánk ezek közül a kijelölést/kiválasztást menüvel, ikonokkal, eszköztárral, gyorsbillentyűkkel.

A bejegyzéshez tartozó teljes forráskódot ILIAS e-learning tananyagban tesszük elérhetővé tanfolyamaink résztvevői számára.

Tanfolyamaink orientáló moduljának 9-12. óra: Mesterséges intelligencia alkalmához kapcsolódóan a kígyókocka véletlenszerű előállítása helyett stratégiával rendelkező visszalépéses algoritmust specifikálhatunk és implementálhatunk.

Ez egy két részből álló blog bejegyzés 2. része. A blog bejegyzés 1. része itt található.