Android API and Kotlin syntax

[TobseF]

Hi @ZeroOne3010,

I needed a Philips HUE API lib for my Android App. Your yetanotherhueapi seemed to be a very good match. It's up to date, has a very good API, it's tested and it's available in the Maven central, Great 👍

But to use it on Android it has the problem, that it uses java.awt.Color which is not available there. Although the Java 8 API seems to be improper in the point of a Kotlin program - e.G. using Optionals. And you are forced to use Android api level 26 to get Optionals to work - instead of 6.

So I forked it and did a total to Kotlin conversation: yetanotherhueapi-kotlin

Do you have also plans to support Android or to migrate to Kotlin?

Best wishes,
Tobse

[ZeroOne3010]

Hi @TobseF, thank you for the compliments! :) That conversion you did was quite a feat! :o I'm not much of an Android or Kotlin programmer myself, so no, I have not had any plans to support either of them... I'm too fond of the Java 8 streams and Optionals to go back to Java 6 style of code. ;) Is there anything else I could do for you regarding the library?

[TobseF]

The library worked like a charm. The only confusing thing was, that I have to choose a style of setting a light. So if I set a light by color, I'm not able to also set the brightness. E.g. it's not possible to call:
State.builder().color(Color.RED).brightness(254).
That's ok, and it make sense, if you know the HUE API, but using it for the first time was tricky.

As a Kotlin fanboy I can only advice you to give it a try. I bet you will never switch back 😉
With Optionals and Streams... it's the opposite... Kotlin solves it much better and removing them wasn't a step back.

E.g. your loved Stream API:

# Java
return Collections.unmodifiableCollection(this.sensors.values().stream()
        .filter(s -> type.equals(s.getType()))
        .map(sensorClass::cast)
        .collect(toList()));

VS

# Kotlin
return this.sensors.values.filter { type == it.type }.map (sensorClass::cast)

It's also complete typesafe. You will also receive e a unmodifiableCollection. And the "==" check also calls the equals method. And you can skip the collect(). What do you think is more expressive?

And in Kotlin Optionals are completely obsolete, because you have to specify on every type, if it's nullable or not. You can never set a String to null. If you need it, you have to declare it as String?. Then you can set it to null, but also have to check it, before you can call it. So goodby to NPEs.

KOTLIN FANBLOCK END 😁

[ZeroOne3010]

Yeah, well, how would setting both color and brightness even work? What should happen if you set a very dark color, such as #220000, but set it to 100% brightness? So you should just choose a brighter color. :)

The StateBuilder has been designed to protect the user from setting options that are contradictory, such as setting both the color (RGB value) and the hue (a value from 0 to 65280). It does still need some work, as I've previously noted here: #9 (comment)

I suppose I do need to try Kotlin some day, maybe the next time I come up with a new project. ;)