search

Automattic / Gravatar-SDK-Android

Gravatar Android library
https://gravatar.com
Mozilla Public License 2.0
36 stars 8 forks source link

Consider dropping Java Desugaring #295

Open AdamGrzybkowski opened 1 week ago

AdamGrzybkowski commented 1 week ago

This forces SDK consumers to enable it in their apps. Let's consider alternatives to the java.time.

wzieba commented 1 week ago

+1. As a library consumer, I don't want to be forced to enable desugaring, as it can negatively impact my build time.

An alternative could be kotlinx.datetime and, ideally, the API could not have any of these in the public contract, to not force library consumers to use a specific API. If possible, please consider using standard java.util.Date or similar API, which is available out of the box.

AdamGrzybkowski commented 1 week ago

I have to double check but I'm pretty sure the only place where we use classes from java.time are API models, so they would be exposed. Here's an example - https://github.com/Automattic/Gravatar-SDK-Android/blob/trunk/gravatar/src/main/java/com/gravatar/restapi/models/Profile.kt#L113

We could keep them in raw ISO 8601 format and leave it up to third-party devs what libraries they want to use to handle those dates if needed.

AdamGrzybkowski commented 4 days ago

@maxme Do you have any opinions about it?

maxme commented 4 days ago

I agree we should remove it. I'd keep the dates we get from the backend as strings for now. I'm not sure what format will be used in the stable version of the API, but we can add documentation / comment to let third party devs what's in there.

Note: something similar we've done in the past to drop android.net.Uri https://github.com/Automattic/Gravatar-SDK-Android/pull/82