időzítő - címke - it-tanfolyam.hu

Galéria véletlen sorrendben

2023. november 2.2023. augusztus 11. Szerző: Kiss Balázs

Adott egy mappában lévő sok-sok képfájl, többféle formátumban, kiterjesztéssel. A feladat az, hogy időzítve jelenítsük meg ezeket a képeket véletlen sorrendben saját fejlesztésű Java program segítségével. A tervezés során áttekintünk többféle lehetőséget. Bemutatjuk a megoldáshoz szükséges lépéseket és a program működését.

A program tervezése

A szükséges bemeneti adatok

Egy mappa, abszolút vagy relatív útvonal, ahol a képfájlok megtalálhatók. A mappa átvehető a program paramétereként (ha parancssorban meghívva átadjuk) vagy lehet az aktuális mappa (ahonnan a programot jar fájlként elindítjuk). A program a mappában közvetlenül megtalálható képeket olvassa be. Az ott található almappákba nem megy bele.
A képfájlok különböző kiterjesztéseit tárolni kell. Többféle is lehet, így ehhez szükséges alkalmas adatszerkezet. A listában nem szereplő kiterjesztéssel rendelkező fájlok nem kerülnek feldolgozásra.
Érdemes a képfájlokat egy lépésben betölteni a memóriába. Így a program takarékos erőforrásként bánik a tárhellyel (merevlemez, pen-drive, SSD, hálózati meghajtó). Csak egyszer dolgozza fel (olvassa végig) a mappát. Feltételezzük, hogy a képfájlok beférnek a memóriába.
A program teljes képernyős, amiből elérhető a rendelkezésre álló terület mérete, ahol megjeleníthetők a képek. A program a betöltött képfájlok méreteihez is hozzáfér. Ez a méret kétféle lehet: bájtban kifejezhető a képfájl elfoglalt tárhelye, illetve pixelben kifejezhető a képfájl dimenziója (másképpen a megjelentéséhez szükséges terület mérete a képernyőn).

Hogyan működik a program?

Egyszerre egy kép jelenik meg. Időzítő befolyásolja a képfájlok közötti váltást. Meghatározza, hogy a képfájlok meddig látszanak (másképpen: eltelt idő, késleltetés, várakoztatás). A swing GUI-hoz tartozó időzítőt kell hozzá használni.
A program alkalmazkodik a képernyő, kijelző felbontásához, képarányához. A program végtelenítve működik, Alt + F4 billentyűkombinációval lehet kilépni belőle.
A képfájlok megjelenítésük során optimálisan, dinamikusan kitöltik a rendelkezésre álló téglalap alakú területet. A túl kicsi képeket nagyítani kell. A túl nagy képeket kicsinyíteni kell. Mindezt úgy, hogy a képarányt (aspect ratio) meg kell tartani, hogy a képek ne torzuljanak el. Az alábbi három példa balról-jobbra mutatja az optimális kitöltést, illetve azt a két esetet, ami akkor történik, amikor a kép méretéhez képest a megjelenítésre használható terület túl magas vagy túl széles:
A galériába tartozó képek közötti véletlen sorrendet meg kell oldani. A program a memóriába betöltött képek sorszámai alapján valósítja meg a véletlenszerű kiválasztást. A sorszámok összekeverednek. Egymás után nem jöhet ugyanaz a kép többször. Ha a képek „elfogynak”, akkor a program végtelenített működése szerint a képek sorszámai újra összekeverednek és „lejátszásra kerülnek”.

A program megvalósítása

A mappát a java.io csomag File osztályából létrehozott folder objektum tárolja (a "./" szövegliterál jelöli az aktuális mappát). A feldolgozandó képfájlok kiterjesztéseinek listáját egy dinamikus tömbből létrehozott generikus lista oldja meg: ArrayList<String> imageFileExtensionList=new ArrayList<>(Arrays.asList("JPG", "JPEG", "PNG", "GIF")). Egy képfájl memóriabeli tárolását a java.awt.image.BufferedImage típus valósítja meg, amelyekből szintén generikus lista épül: ArrayList<BufferedImage> imageList. A grafikus felhasználói felülethez tartozó javax.swing csomagbeli Timer osztály szükséges, például 2 mp-es várakoztatás és eseménykezelés: timer=new Timer(2000, (ActionEvent) -> { showRandomImage(); }). A GUI JFrame leszármazott keretobjektum. A grafikus felhasználói felület a teljes képernyőt elfoglalja: setExtendedState(MAXIMIZED_BOTH) és setUndecorated(true). A keretre egyetlen JLabel típusú, fekete hátterű lbImage objektum kerül, az alapértelmezett határmenti elrendezésmenedzser közepére (vízszintesen és függőlegesen egyaránt). A képfájlok sorszámai (a későbbi véletlen kiválasztáshoz) az imageIndexList generikus listába/kollekcióba kerülnek. Az index változó jelöli az aktuális, memóriába betöltött képfájl sorszámát, ami kezdetben nulláról indul.

A képfájlok betöltése az alábbiak szerinti:

private void createImageList() {

File[] imageArray=folder.listFiles((File path) -> {

String extension=path.getName().toUpperCase().

substring(path.getName().lastIndexOf(".")+1);

return imageFileExtensionList.contains(extension);

});

try {

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

imageList.add(ImageIO.read(imageArray[i]));

imageIndexList.add(i);

}

Collections.shuffle(imageIndexList);

}

catch(IOException e) {

}

A fájlok kiterjesztésének szűrése a FileFilter interfész accept() metódusának megvalósításával történik. A fenti forráskódban mindez tömör, lambda kifejezéssel (művelettel) valósul meg. A fájlszűrőn az képfájl megy át, aminek a nagybetűssé alakított kiterjesztését tartalmazza az imageFileExtensionList kollekció. Az i-edik képfájl memóriába való betöltését az ImageIO osztály statikus read() függvénye oldja meg. A képfájlok sorszámainak véletlen összekeverése kezdetben megtörténik: Collections.shuffle(imageIndexList). A fájlkezelés miatt kötelező kivételkezelést most – itt a szakmai blogban – nem részletezzük.

Az időzítő eseménykezelése, a 2 másodpercenkénti képváltás így valósul meg:

private void showRandomImage() {

BufferedImage img=imageList.get(imageIndexList.get(index));

Dimension d=getScaledDimension(new Dimension(

img.getWidth(), img.getHeight()), lbImage.getSize());

ImageIcon imageIcon=new ImageIcon(img.getScaledInstance(

(int)d.getWidth(), (int)d.getHeight(), Image.SCALE_SMOOTH));

lbImage.setIcon(imageIcon);

index++;

if(index==imageIndexList.size()) {

Collections.shuffle(imageIndexList);

index=0;

}

A program alábbi metódusa felel a képarányhoz kötődő műveletekért:

private Dimension getScaledDimension(

Dimension imageSize, Dimension area) {

double widthRatio=area.getWidth()/imageSize.getWidth();

double heightRatio=area.getHeight()/imageSize.getHeight();

double ratio=Math.min(widthRatio, heightRatio);

return new Dimension((int)(imageSize.width*ratio),

(int)(imageSize.height*ratio));

}

A program tesztelése

Érdemes lehet tesztelni nem ajánlott (rossz) megoldásként azt, hogy a program az időzítőnek megfelelően, dinamikusan olvasná be a képfájlokat, amivel lényegesen kevesebb memóriát igényelne.
Van-e reális korlát arra, hogy mennyi, mekkora képek „férnek el” a memóriában?
Hogyan befolyásolja a képfájlok száma és az általuk elfoglalt tárhely a program indulását?
Mi történik, ha nincs megfelelő kiterjesztésű képfájl a mappában? És ha több 1000 kép van benne?
Hogyan jelennek meg (megjelennek-e) az animációt tartalmazó képfájlok? Például a GIF képformátum nem csak statikus egyetlen képet tartalmazhat, hanem lehet animált is.
Teljesen megvalósul-e a reszponzivitás? Ha igen, mi indokolja? Ha nem, miért nem és hogyan lehetne megoldani?

Ha átmenetileg kikapcsoljuk a teljes képernyős megjelenítést, akkor könnyen tesztelhetővé válik a megvalósuló reszponzivitás. Másképpen a program dinamikusan alkalmazkodik a rendelkezésre álló (rajzolható) terület méreteihez (szélesség és magasság):

A program továbbfejlesztési lehetőségei

A program rekurzívan bejárhatná a folder által megjegyzett útvonalból kiindulva a teljes (al)mappaszerkezetet.
A program paraméterezhető lehetne a képfájlok kiterjesztéseivel. Akár konfigurációs fájlból is beolvashatná az imageFileExtensionList adatszerkezetet, például XML, JSON formátumban is.
A program ellenőrizhetné, hogy a mappában lévő összes kép befér-e a memóriába. A program kezelhetne ehhez kötődően többféle limitet: például az első 100 db képet töltené be, és/vagy csak annyi képet tölt be, ami belefér például 64 MB-ba.
A program mutathatná folyamatindikátorral induláskor a képfájlok betöltését. Vagy betölthetné például az első 5 db-ot és háttérszálon a többit, amíg az első 5-öt „lejátssza”.
Ha például a program 10 képet tölt be mappában lévő képfájlokból, akkor ezek 0-tól 9-ig sorszámozódnak. A sorszámok összekeverve következnek. Ha az első menetben az utolsó kép sorszáma például a 7 volt, akkor a következő ismétlődő menet nem kezdődhetne 7-tel.
A programból ki lehetne lépni az Esc billentyűvel is. KeyListener interfésszel megoldható.
A program kezelhetne egyéb képfájlformátumokat is: például animált GIF, statikus WebP, animált WebP.
A program könnyen kiegészíthető prezentációk diáinak időzített/felülbírált megjelenítésére.
A program által beolvasott képfájlokból generálható PDF fájl is (rácsos sablonnal, például 6 db kép laponként). A feldolgoztt mappában lévő képfájlok könnyen feltölthetők FTP szerver adott mappájába, átméretezhetőek csoportosan, elküldhetők nyomtatási sorba is.
Érdemes megismerni a JDK-n kívüli egyéb, képfájlokat kezelő osztályok, csomagok funkcióit, például: OpenIMAJ, TwelveMonkeys ImageIO.
A swing-es felület kiegészíthető mappatallózással, egyéni fájl(típus)szűrőkkel, paraméterezhető lehet a véletlenszerű kiválasztás algoritmusa, változtatható az időzítés késleltetése.
Mivel a program teljes képernyős, így elrejthető az egérmutató.
A képek „lejátszásából” lehetne generálni animált GIF-et.

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

Letöltés szimuláció

2023. július 26.2022. június 15. Szerző: Kaczur Sándor

Letöltési folyamatot szimulálunk. A paraméterek rugalmasan beállíthatóak. Előre beállított mennyiségű adatot, párhuzamos szálakon/folyamatokon keresztül töltünk le, miközben mérjük az eltelt időt. A folyamatok állapota lehet inaktív, aktív és befejezett. Az aktív folyamatok esetében megjelenő százalék fejezi ki, hogy a folyamat hol tart a rá jutó részfeladat végrehajtásával. Összesített formában követhetjük a hiányzó és a letöltött adat mennyiségét MB-onként és százalékosan is. A folyamat szimulációjához grafikus felületű Java kliensprogram készült, egyszerű GUI komponensekkel (nyomógomb, címke, folyamatindikátor, másképpen JButton, JLabel, JProgressBar swing komponensek).

Az alábbi animáció bemutatja a letöltés szimulációját:

A konkrét paraméterek: 128 MB-nyi adatot töltünk le 256 párhuzamos szálon/folyamaton keresztül, így egy-egy részfeladat 0,5 MB-nyi adat letöltését jelenti. Minden értéket/mérőszámot egész számként ábrázolunk, akár százalékhoz tartozik, akár mértékegységként MB vagy s. A változások – és egyben a frissítés is – 5 ezredmásodpercként történnek a GUI-n.

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. A Java EE szoftverfejlesztő tanfolyamunkon, a szakmai modul 5-8. óra Szálkezelés, párhuzamosság alkalommal többféle elosztott stratégiát ismertetünk, és a 17-24. óra Socket és RMI alapú kommunikáció alkalommal pedig megvalósíthatjuk többféle protokoll szerint a hálózati kapcsolatot, letöltést/feltöltést.

Elosztott alkalmazások esetén többféleképpen is modellezhető és kialakítható a rendszer architektúrája. Elosztott lehet maga a hálózat, a számítási folyamat, az algoritmus. Elosztott objektumok kommunikálhatnak egyenrangúnak tekinthető P2P szerepkörben vagy szerver/kliens oldalon, és több dolog/elem/hardver/szoftver/komponens együttműködéseként is megvalósulhat elosztott alkalmazás. A hálózati kommunikáció folyamatát valamilyen protokoll határozza meg, amit minden komponens ismer és így meghatározott szabályrendszer szerint működik.

Hardver szinten elosztottak a többprocesszoros rendszerek. Szoftveresen elosztott például egy moduláris vállalatirányítási rendszer, illetve a mobilalkalmazások többsége. Tipikus háromrétegű webalkalmazás esetén külön szerver nyújtja az adatbázishoz kapcsolódó szolgáltatásokat, a felhasználó számítógépén található a böngészőben futó/megjelenő kliensprogram/weboldal és a kettő között a felhő rétegben lehet a funkcionálisan elosztott alkalmazáslogika (például validálás, titkosítás, tömörítés, autentikáció, autorizáció).

A vezérlést megvalósító részlet a Java forráskódból:

private void processControl() {

if(processList.isEmpty()) {

timer.stop();

return;

}

int index=(int)(Math.random()*processList.size());

int oldValue=processList.get(index).getValue();

int increase=(int)(Math.random()*3+1)*10; //5, 10, 15

increase=oldValue+increase<=MAX ? increase : MAX-oldValue;

downloadedSumPercent+=increase;

int newValue=oldValue+increase;

processList.get(index).setValue(newValue);

if(newValue==MAX)

processList.remove(index);

int openProcessCount=0, inactiveProcessCount=0;

for (JProgressBar pb : processList) {

int v=pb.getValue();

if(v==MIN)

inactiveProcessCount++;

if(MIN<v && v<MAX)

openProcessCount++;

}

lbInactiveProcessCount.setText(""+inactiveProcessCount);

lbOpenProcessCount.setText(""+openProcessCount);

lbClosedProcessCount.setText(""+

(PROCESS_COUNT-(openProcessCount+inactiveProcessCount)));

int downloadedData=

(int)((double)downloadedSumPercent/(PROCESS_COUNT*MAX)*DATA);

lbMissingData.setText(""+(DATA-downloadedData));

lbDownloadedData.setText(""+downloadedData);

pbProcess.setValue((int)((double)downloadedData/DATA*100));

elapsedTime+=5;

if(elapsedTime%1000==0)

lbElapsedTime.setText(""+elapsedTime/1000);

}

A szimuláció elvi szinten:

a folyamatok generikus listában vannak,
időzítő által meghatározottan, gyorsan és ismétlődve történnek az időzített lépések,
ha egy folyamat befejeződik, akkor kikerül a generikus listából,
ha a folyamatok generikus listája kiürült, akkor vége a szimulációnak,
ki kell választani véletlenszerűen egy folyamatot, léptetni kell véletlenszerűen, amíg be nem fejeződik,
folyamatosan nyilván kell tartani a szükséges adatokat a háttérben,
folyamatosan frissíteni kell a felhasználói felületet.

Haladóbb megközelítésben másképp is lehetne: a számítási műveletek redukálhatóak lennének, ha lenne egy – minden olyan adat karbantartásáért felelős – modellobjektum, amelynek adatai hozzá lennének rendelve a GUI komponensekhez. Aki már sejti, annak megerősítem, hogy igen, ez observer (megfigyelő) tervezési minta.

A feladat könnyen általánosítható, például:

Egy keresési feladatot oldjunk meg az állományrendszerben! Kereshetünk egy konkrét nevű fájlt, adott kiterjesztésű fájlt, joker karakterekkel paraméterezett nevű fájlt/mappát, adott méretű állományt, adott dátum előtt létrehozott fájlt… Az állományrendszer bejárása rekurzív módon történik. A gyökérben lévő mappánként külön, esetleg második szinten lévő mappánként külön indíthatók szálak, párhuzamos folyamatok. Ha egyetlen találat elegendő, akkor bármelyik szál pozitív visszajelzésére minden szál leállítható. A feladatnál nagy eséllyel nagyon különböző méretű mappákon és eltérő mélységű mappaszerkezeteken kell végighaladni, így erre érdemes lehet optimalizálni, de ez már nagyon más szintje ennek a problémának.
Active Directory szerkezetben keressünk elérhető nyomtatókat a hálózaton!
Elosztott számítási hálózatként működik/működött a SETI@home. Koncepciójának lényege, hogy egy hatalmas feladatot nem nagyon drága szuperszámítógépeken, hanem olcsó gépek ezrein, százezrein, vagy akár millióin végeztetjük el, amelyek jelentős szabad kapacitással (pl. processzoridővel, átmeneti tárhellyel) rendelkeznek és egyébként is csatlakoznak a világhálóra.
Hasonlóan elosztott működésű a torrent protokoll. A kliensek/szálak az állományokat több kisebb darabban/szeletben töltik le, természetesen párhuzamosítva. Minden csomópont megkeresi a hiányzó részhez a lehető leggyorsabb kapcsolatot, miközben saját maga is letöltésre kínálja fel a már letöltött fájldarabokat. A módszer nagyon jól beválik nagyméretű fájloknál, például videók esetében. Minél népszerűbb/keresettebb egy fájl, annál többen vesznek részt az elosztásában, ezáltal a letöltési folyamat gyorsabb, mintha mindenki egy központi szerverről töltené le ugyanazt (hiszen az informatikában minden korlátos, a sávszélesség is).
A képtömörítést végző algoritmusok is lehetnek elosztottak, ezáltal párhuzamosíthatóak. Például ha felosztjuk a képet 16*16-os méretű egymást nem átfedő részekre, akkor ezek egymástól függetlenül tömöríthetők.
A merevlemezek esetén korábban használatos defragmentáló szoftverek felhasználói felülete emlékeztet a mintafeladat ablakára.

Fontos szem előtt tartani, hogy a grafikus megjelenítés csupán a szimulációhoz tartozó – annak megértéséhez szükséges – reprezentáció, így teljesen független lehet a folyamatok valós működésétől.

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

Tankocka – Párkereső: csomag, osztály, interfész

2023. július 26.2022. június 1. Szerző: Kaczur Sándor

Folytatjuk Tankockák blog bejegyzés sorozatunkat. A feladatban 12 összetartozó párt kell megtalálni az ismert Java csomagok, osztályok, interfészek témakörben. Ez a témakör mindhárom tanfolyamunkhoz kötődik: Java SE szoftverfejlesztő tanfolyam, Java EE szoftverfejlesztő tanfolyam, Java adatbázis-kezelő tanfolyam. Ezek egyszerű lexikális ismeretnek tűnhetnek, de jóval túlmutat azon.

Tipikus hibaforrás, ha az osztály és/vagy interfész neve a különböző csomagok esetén megegyezik és megszokásból, rutinból, figyelmetlenségből rossz csomagból importálunk. Nem biztos, hogy rögtön triviális: mi a hiba, miért az a hiba, hogyan oldjuk meg. Például Timer osztály van a java.util és a javax.swing csomagokban is és nagyon nem mindegy, hogy mikor melyiket (és persze mire, hogyan) használjuk.

Hóesés szimuláció

2023. augusztus 4.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.