Világos, köszönöm.

Egy kis stream alap...

A végrehajtásban a .map upperCase -ként fűzi, adja tovább a stream elemet. Ez eddig érthető(számomra). Az .anyMatch -nél nem értem, hogy a kiértékelt boolean eredmény mit jelent. A következő stream ciklusban megint az eredeti következő stream elem lesz manipulálva.
Hogy is van ez?

    Stream.of("d2", "a2", "b1", "b3", "c")
        .map(s -> {
            System.out.println("map: " + s);
            return s.toUpperCase();
        })
        .anyMatch(s -> {
            System.out.println("anyMatch: " + s);
            return s.startsWith("A");
        });
    // map:      d2
    // anyMatch: D2
    // map:      a2
    // anyMatch: A2    

anyMatch egy Predicate-et vár. A Predicate egy olyan függvény, ami valamilyen bemenetre egy booleanüt ad vissza.
Az anyMatch addig folytatja a kiértékelést, amíg a predicate igaz nem lesz. Tehát jelen esetben addig, amíg nem talál olyan elemet, ami nagy A-val kezdődik. Utána leáll a további feldolgozás, mert teljesen felesleges lenne.

I am having fun staying poor.

A stream-et egy iterátorként fogd fel, és a benne lévő lépések végrehajtódnak minden elemre.
Tehát minden elemre végre fog hajtódni először az upperCase, ami nagybetűsít. Ennek az eredménye megy át elemenként az anyMatch-be, ami megnézi, hogy az adott elem A betűvel kezdődik-e. Az anyMatch egy terminal operátor, vagyis zárja a stream-et, további lépést nem tudsz hozzáfűzni. A visszatérési értéke boolean:

boolean anyMatch(Predicate<? super T> predicate)

Tehát az egész stream kiértékelés eredménye egy true/false érték, és true akkor, ha valamelyik elem nagybetűsítve A-val kezdődik. Az első sor elejére ezt is írhatod:

boolean existsWithA = Stream.of("d2", "a2", "b1", "b3", "c")...

És jelen esetben ez true-t fog visszaadni, de ha az a2-t kiszeded, akkor false-t.

Hazudnék, ha cáfolnám annak tagadását, hogy ez az ital nem nélkülözi a koffeinmentesség megnemlétének hiányát. Na most akkor van benne koffein, vagy nincs?!

Köszönöm mindenkinek. Teljesen fordítva gondoltam az .anyMatch kiértékelést. Addig megy amíg igaz nem lesz a kiértékelése

[ Szerkesztve ]

Ha keresed a bajt magadnak ...
nő vagy ?

A gázt is és a féket is egyszerre nyomni nem menő dolog !

Megismerkedtem a "stream" technikával. Nagyon tetszik tizen- sorok helyett egy utasításba lefűzni a kódot.
A kérdésem, hogy ez a tömörség csak a forráskódot érinti, vagy a lefordult
bájtkód/végrehajtási sebességet is gyorsítja?
(Biztos össze lehet hasonlítani méréssel, de nem akarom feltalálni a kereket. )

Alapból a stream-nek van minimális overhead-je a hagyományos bejárással szemben, viszont sokkal jobban karbantartható kódot eredményez.
Másrészt ha nagyon heavy a stream kiértékelése (pl. sokmilliós rekordszám), akkor a .parallel() lépést beiktatva a stream-be párhuzamosítja a feldolgozást, és magszám-közeli szorzót lehet így elérni sebességben.

Hazudnék, ha cáfolnám annak tagadását, hogy ez az ital nem nélkülözi a koffeinmentesség megnemlétének hiányát. Na most akkor van benne koffein, vagy nincs?!

Elakadtam a következő stream soron:
 ArrayList<Literacy> list = new ArrayList<>();
        try {
            Scanner scanner = new Scanner(Paths.get("literacy.csv"));
            while (scanner.hasNextLine()) {
                String[] line = scanner.nextLine().trim().split(",");
                list.add(new Literacy(line[0],line[1],line[2],line[3],Integer.valueOf(line[4]),Double.valueOf(line[5])));
                
            }
        } catch (IOException ex) {
            System.out.println(ex);
        }
        list.stream()
            .sorted((p1, p2) -> {return p1.getLiteracyRate() - p2.getLiteracyRate();})
            .forEach(l -> System.out.println(l));
A fordítási hibaüzenet: incompatible types: bad return type in lambda expression
possible lossy conversion from double to int
A Literacy osztályban a getLiteracyRate double típus.

Nem értem mi a baja két double kivonásával és visszaadásával? (int-el működne, de nem az a feladat)

p1.getLiteracyRate() - p2.getLiteracyRate()
Ehelyett írd ezt: Double.compare(p1, p2)

Redmi Note 9 Pro

Egy kis magyarázat: A comparator mindig int visszatérési értékű. Az érték előjele mutatja meg, hogy merre néz a kacsacsőr. Ha nem primívet használsz, akkor az object rendelkezik egy compareTo metódussal aminek int a visszatérési értéke. Szóval ha double helyett Double lenne a property, akkor hívhatnád így is. p1.compareTo(p2). Vagy ha ez az egyetlen property akkor akár comparator nélkül is mehet: sorted()

Redmi Note 9 Pro

 .sorted((p1, p2) -> {return Double.compare(p1.getLiteracyRate(), p2.getLiteracyRate());})
Így már működik! Megjegyeztem. Köszönöm!

Hopsz! Igen, azt nem írtam ki szépen. De látom ügyesen megoldottad. Szívesen!

[ Szerkesztve ]

Redmi Note 9 Pro

Metódus-referenciát akartam írni, de elbabráltam.
Ha a Literacy osztályban implementálsz egy static compare metódust a Double::compare mintájára (ahogy a lambdában csináltad), akkor úgy is lehetne a streames kód, hogy:
.sorted(Literacy::compare)

Rövidebb nem lesz összességében, de elegánsabb, és nálam egy kód reviewn is hamarabb átmegy

[ Szerkesztve ]

Hát igazából, ha már ott implementálja, akkor simán override-olhatja a compareTo metódust, és akkor üresen is hívhatja a sorted() függvényt.

Redmi Note 9 Pro

Mindig tanul az ember valamit

Egy másik megoldás még ide, amit gyakran szoktak alkalmazni:
.sorted(Comparator.comparingDouble(Literacy::getLiteracyRate))

Igaz. Ezeket mindig elfelejtem, pedig nem hülyeség

Még egy kis kiegészítés a comparator implementációhoz.
Ha nagyon nagy számokkal dolozunk, akkor nem szerencsés a kivonásos módszer használata, pl. a p1.getLiteracyRate() - p2.getLiteracyRate(). Ugyanis ha egy nagyon negatív számból kivonunk egy nagyon pozitív számot, akkor az eredmény túlcsordulhat és átcsap az ellenkező előjelbe, ami nyilván elrontja az egész sorrendezést.
Érdemes inkább a relációs operátorokat (<, >) használni a kivonás helyett.

(Most nincs lehőségem kipróbálni, ezért kérdezek. )

Ebben az esetben az intermediate egy int eredményt vár, hogy sortolja a stream-et. A kacsacsőr boolean-t ad vissza. Vagy ezt az igaz/hamis értéket még vizsgálni kell operátorral? Így kell érteni?

A boolean-ből könnyen csinálhatsz 0, 1, -1 értékeket. Puskázva az Integerből :

public static int compare(int x, int y) {
return (x < y) ? -1 : ((x == y) ? 0 : 1);
}

[ Szerkesztve ]

Volt már hasonló kérdésem saját osztállyal. (ősosztály metódus elérés, override)

Azt még mindig nem értem, hogy beépített osztályoknál mi a különbség a list1-list2 között, ha az egyiket List-be a másikat ArrayList típusba teszem. (ez a kérdés akár a Map/HahMap -re vonatkozhatna)

List<String> list1 = new ArrayList<String>();
ArrayList<String> list2 = new ArrayList<String>();

A list1 List típusú a fordító és a runtime számára, aminek nincsenek olyan metódusai, amiket a list2-ben megtalálsz. Pl. a java 8 szerint a forEach.

És amennyiben nincs is szükséged, hogy elérd ezeket a metódusokat, mindig az interface-t használd típusnak, ne a konkrét megvalósítást, mert így bármikor ki tudod cserélni a tényleges típust (pl. LinkedList-re) anélkül, hogy a kódod egyéb részeihez hozzá kellene nyúlnod.

Hazudnék, ha cáfolnám annak tagadását, hogy ez az ital nem nélkülözi a koffeinmentesség megnemlétének hiányát. Na most akkor van benne koffein, vagy nincs?!

A List interface-ben van forEach, nem?

Annyit tennék, még hozzá, hogy az ArrayList mutable. A projektekben az ilyen típusú visszatérési értékek kerülendők. A HashMap is ilyen. Ezeket inkább csak függvények és osztályok belső logikájához használd. Visszatérési értéknek mindig próbálj immutable-t használni, mint a List vagy a Map. Azt gondolom észrevetted, hogy az interface típusokban nincs add és put. Okkal.

Redmi Note 9 Pro

A List meg a Map nem típus, hanem interface. És mindkettő a mutable típusok interface, a List interfaceben ott az add és a Mapban is a put.

LOL. Olyan rég Kotlin-ra váltottam, hogy már el is felejtettem, hogy a list is definiálja az add metódust. Akkor ha jól rémlik talán az Iterable a jó analógia rá.

Redmi Note 9 Pro

Iteratornak is van remove metodusa: [link]

Immutable kollekciokra tobb fuggveny van, pl. Collections.unmodifiableList, List.of (java 9), List.copyOf (java 10)

Nem vagyok egoista, csak uborkagyalu!

Android vonalon én java 8-nál tetőztem. Kotlinban ez pl. így működik:
listOf(...) és mapOf(...) ha final kell és
mutableListOf(...) és mutableMapOf(...) ha mutable kell

Az List.of szintén List típust add vissza, csak gondolom dob egy csinos UnsupportedOperationException-t ha add-ot hívsz az outputra.

Redmi Note 9 Pro

igen, bovebben le van irva a dokumentacioban
Collection
List

Helyesen unmodifiable-nek kellene hivni, mert attol fuggoen mi van a kollekcioban az elemeket lehet akar valtoztatni.

Nem vagyok egoista, csak uborkagyalu!

Nekem is meg kellett nézni, hogy rosszul emlékszem-e.

#11933:
Helyesen unmodifiable-nek kellene hivni, mert attol fuggoen mi van a kollekcioban az elemeket lehet akar valtoztatni.

Attól még maga a collection immutable.

[ Szerkesztve ]

"An unmodifiable collection is not necessarily immutable. If the contained elements are mutable, the entire collection is clearly mutable, even though it might be unmodifiable. For example, consider two unmodifiable lists containing mutable elements. The result of calling list1.equals(list2) might differ from one call to the next if the elements had been mutated, even though both lists are unmodifiable. However, if an unmodifiable collection contains all immutable elements, it can be considered effectively immutable. "

[link]

Nem vagyok egoista, csak uborkagyalu!

Azt a kotlin extension-ök sem állítják, hogy a listOf(...) eredménye immutable. Szóval nekem tökéletesen megfelel a kotlinos elnevezés. És annak legaláb egy olyan List a visszatérési értéke, aminek nincs add metódusa, ami aztán random RuntimeException-t dobál, mint a javas alternatívák. De abban egyetértünk, hogy lista elemeinek is immutable-nek kell lenniük.

[ Szerkesztve ]

Redmi Note 9 Pro

Nem teljesen java, inkább OOP kérdés, amiben kicsit elveszve érzem magam.
Vannak állataink, legyen mondjuk kenguru és tigris. Szeretnénk építeni egy cirkuszt, több ilyen állattal.
A cirkusz igazgató le tud hívni egy állatlistát, amiben látja mindkét fajt és az adataikat, pl. születési év. Illetve ha kiválaszt egyet, akkor utasítást adhat pl. egy gombbal. Mindkét állat tud a farkán ugrálni, viszont a kenguru el is tud rejteni valamit az erszényében.
A problémám, hogy sokak szerint egy instanceof mindig code smell. Akár leszármazást, akár kompozíciót használok, valahogy meg kell tudnom a lista egy adott elméről, hogy milyen többlet képessége.
Hogyan lehet ezt szépen megoldani?
Illetve lehet-e dinamikussá tenni az egészet, hogy kódváltoztatás nélkül új fajokat kreáljon az igazgató, amik saját "képességekkel" rendelkeznek?

Már van, de a java 8ról beszéltem a példa kedvéért, abban még nem volt.

Tobbfele megoldas lehet, de talan a legegyszerubb az, ha csinalsz egy Activity osztalyt, ami leirja, hogy mit es hogyan tud csinalni az az Activity.
Az allat osztalyban meg eltarolsz egy Activity Collection-t, amire csinalsz egy getter-t.
Aztan az Activity-bol csinalhatsz mondjuk egy KangarooHidingActivity-t, ami a konstruktoraban megkap egy Kangaroo-t. A Kangaroo konstruktoraban meg megcsinalod a KangarooHidingActivity-t, meg a masikat es belerakod oket egy collection-be.
Igy amikor vegigmesz egy Animal Collection-on, le tudod kerni az egyes Activity-k kollekciojat allatoktol fuggetlenul, azok az Activity-k meg megis kepesek lesznek allat specifikus dolgokat csinalni, az eppen megadott allaton.
Azt nem tudom, hogy ez egy ismert pattern-e, meg van-e neve, de egyszeru esetben valami ilyesmit csinalnek. A Command pattern nagyjabol ez, de talan nem pontosan.

[ Szerkesztve ]

I am having fun staying poor.

Ráadásul ugyanezt meg tudom változókkal is csinálni, ugye?. Csinálok egy marker interface-t(AnimalAttribute), amihez hozzádobok esetleg egy getPossibleValues()-t és legrosszabb esetben kap az adott class egy wrapper-t. Így akár egy dinamikus listát is tudok csinálni, ahol a tigriseknek lesz Csíkvastagsága a kengurunak meg Erszénynyúlásiegyütthatója.
"Szabad" ilyet?

Szerintem az insteanceof önmagában még nem code smell. Kotlinban sem code smell az is operator. Sőt, ha használod, még smart cast-olja is az objektumot. A java azért más picit, mert ott neked kell cast-olni. Inkább azt mondanám, hogy könnyű code smell-t csinálni vele javaban. Például figyelni kell, hogy csakis final pointerre hívd meg, mert hiába csekkolod, hogy instanceof ha később változhat az object amire a pointer mutat.

Redmi Note 9 Pro

Belegondoltam és a változóknál bejön egy új aspektus, a backend.

Sziasztok!

Android telefonra keresek példát BT broadcast üzenetet küldeni.

A tippeket köszönöm.

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Szia! Nem értettem pontosan. Bluetooth broadcast receiver példát szeretnél? Vagy bluetooth-on szeretnél üzenetet küldeni?

Redmi Note 9 Pro

Szabadni szabad, de nem tul szep. Interface moge viselkedest illik rejteni, igy pl. azt, hogy miket tudnak csinalni az allatok, szivesen kiszerveznem interface-be, de azt, hogy milyen tulajdonsagai vannak az allatoknak, inkabb nem.
A backend dolgot nem tudom itt hogyan erted.

I am having fun staying poor.

Az OOP-vel könnyű átesni a ló túloldalára és túlkomplikálni egy egyszerű problémát. Pl. ha a kenguru el tud rejteni valamit azt lehet simán relációs adatszerkezetként is értelmezni. X elrjeti Y-t. Ez akár tárolható egy táblában is. A kengurunak nincs szüksége "elrejt" metódusra. Az lehet egy tőle független metódus. Az ugrás szintén egyszerű. Hiszen olyankor mozgatod és animálod az állat objektumot. Nem feltétlenül kell tudnia magáról, hogy ő képes e ugrani. Az ugrás metódus majd eldönti, hogy az adott faj képes e rá. Mozgatja és keres hozzá egy animációt, ha van. Ez mind megoldható faj azonosítóval. Nem kell instanceof. Próbáld az adatszerlezeteidet minél egyszerűbre írni. Egy állat nagyon sok mindenre képes. Hatalmas osztályaid lesznek, kismillió őssel, ha ilyen szemléletben tervezed őket. És az végül mindig visszaüt.

[ Szerkesztve ]

Redmi Note 9 Pro

Küldeni akarok. Sender kell az android telefonra. Az android telefon körül létező - és éppen broadcast-ra figyelő - összes BT eszközknek akarok egy pár karakteres üzenetet eljuttatni az androidról.

[ Szerkesztve ]

កុំភ្លេចប្រើភាសាអង់គ្លេសក្នុងបរិយាកាសអន្តរជាតិ។

Hm... Gyorsan rákerestem a githubon és egy ilyet találtam neked: [link] Kiindulási pontnak talán jó. Bár nem írtad, hogy a többi BT eszköz is androidos e.

Redmi Note 9 Pro

Amúgy nem iBeacon-ről van szó véletlenül? Mert ha igen, ahhoz itt egy library és egy sample projekt: [link]

Redmi Note 9 Pro