DP utitilies on Int and Float about android-ktx

[omarmiatello]

I wrote this utility:

fun Context.toPixelFromDip(value: Float) = TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP, value, resources.displayMetrics)

fun View.toPixelFromDip(value: Float) = context.toPixelFromDip(value)

Pro:

• toPixelFromDip() is very clear the origin and the destination
• It's handy when you call this method from a Context or (more common) a View, ex: View().apply { translationX = toPixelFromDip(2) }

[daberni]

I am not sure if it should be treated/interpreted as a conversion. mostly you simply want do pass a value in dp to a method which takes pixels. so 9.toDp() I would assume converting 9px to Ndp but what we want is to be get the value 9 get treated as dp and therefore I would prefer 9.asDp()

[JakeWharton]

I think we would call these toDp as conversion factory extensions are prefixed with "to".

[imminent]

Ah, that's fine, updating the description to to. 👍

[nohitme]

Just curious, why is it applied on Int & Float instead of on DisplayMetrics ike displayMetrics.toDp(9)?

That way you can also name the param "pixel" so it's less confusing.

[imminent]

DisplayMetrics is merely a tool needed to execute the conversion, the parameter that matters is the value. In an ideal world it would be 9.toDp().

[lub0s]

Wouldn't accessing system Resources just be sufficiet? So we can have something like:

val Int.dp: Int // or just return Float here
    get() = (this * Resources.getSystem().displayMetrics.density).toInt()

and use it in place like val side = 42.dp ?

[omarmiatello]

I don't think so. Your application resources may have a different density. Maybe not now, but you don't know in future.
Also seems correct take it from application context.

[Kevinrob]

What about using Number?

fun Number.toDp(context: Context): Float {
    if (this == 0) return 0f

    return TypedValue.applyDimension(
        TypedValue.COMPLEX_UNIT_DIP, 
        this.toFloat(), 
        context.resources.displayMetrics
    )
}

[romainguy]

This wouldn't work with multiple displays (virtual or physical).

[johanneslaubermoovel]

In my opinion, this is the best implementation.

fun Number.dpToPx(): Int = (toFloat() * Resources.getSystem().displayMetrics.density + .5f).toInt()

[romainguy]

@johanneslaubermoovel This doesn't work with negative numbers. Also you are relying on display metrics that might not match the display.

[hendraanggrian]

I am against using Number as input since only Int and Float are the common types representing dimensions in Android.

This wouldn't work with multiple displays (virtual or physical).

@romainguy this just blew my mind. Say a secondary display is connected, which DisplayMetrics then would the Resources refers to?

[romainguy]

Resources will use the DisplayMetrics of the Display the Resources came from.

[lukewaggoner-zz]

I personally would go with the following methods:

fun Number.toDp(displayMetrics: DisplayMetrics? = null): Float = this.toFloat() / ((displayMetrics ?: Resources.getSystem().displayMetrics).densityDpi / 160f)
fun Number.toPx(displayMetrics: DisplayMetrics? = null) : Float = this.toFloat() * ((displayMetrics ?: Resources.getSystem().displayMetrics).densityDpi / 160f)

displayMetrics is an optional parameter in case you have multiple displays. If not, you have the option of a simple 8.px() or 12.px().

[romainguy]

This seems error prone. The DisplayMetrics should be mandatory. BTW no need to / 160.0f, just use DisplayMetrics.density instead (and you need to properly round and handle negative values correctly).

[iglaweb]

@JakeWharton What about using these converters?

fun Number.toDp(displayMetrics: DisplayMetrics): Float = this.toFloat() / displayMetrics.density
fun Number.toSp(displayMetrics: DisplayMetrics): Float = this.toFloat() / displayMetrics.scaledDensity
fun Number.toPx(displayMetrics: DisplayMetrics, fromSp: Boolean = false): Float
        = this.toFloat() * (if (fromSp) displayMetrics.scaledDensity else displayMetrics.density)

[romainguy]

These are incorrect, toPx in particular does not round properly (which needs to take negative numbers into account). I would also prefer to not have a fromSp boolean, but a separate method.

[imminent]

If you allow arch components, then you can have an onCreateProperty (which is like an Android-specific lateinit var) and define extensions on Activity and Fragment:

/**
 * Initializes a property with the DP value
 * @receiver An [Activity] that is a [LifecycleOwner]
 * @return [Float] representation of the DP value
 * @see [onCreate]
 */
fun <T> T.dp(value: Float) where T : Activity, T : LifecycleOwner = onCreate {
    value.toDp(resources.displayMetrics)
}

/**
 * Initializes a property with the DP value
 * @receiver A [Fragment] that is a [LifecycleOwner]
 * @return [Int] representation of the DP value
 * @see [onCreate]
 */
fun <T> T.dp(value: Int) where T : Fragment, T : LifecycleOwner = onCreate {
    value.toDp(resources.displayMetrics)
}

// In Activity
val margins by dp(5)

[iglaweb]

@romainguy I refined concrete types for these density functions, could you explain why they are not applicable for negative values? (tested myself)

fun Int.toDp(displayMetrics: DisplayMetrics): Float = this.toFloat() / displayMetrics.density
fun Int.toSp(displayMetrics: DisplayMetrics): Float = this.toFloat() / displayMetrics.scaledDensity
fun Float.spToPx(displayMetrics: DisplayMetrics): Int =
        (this * displayMetrics.scaledDensity).roundToInt()
fun Float.dpToPx(displayMetrics: DisplayMetrics): Int =
        (this * displayMetrics.density).roundToInt()

[romainguy]

roundToInt() rounds toward the nearest integer (towards positive infinity when there's a tie), so it won't round in the right direction for negative numbers. For instance 0.5f rounds to 1, but -0.5f rounds to 0.

[lukewaggoner-zz]

What would make it error prone? The only reason you'd ever need to specify displayMetrics would be if you have more than one display. That's never happened to me.

…

On Tue, Mar 6, 2018, 11:06 AM Romain Guy ***@***.***> wrote: This seems error prone. The DisplayMetrics should be mandatory. BTW no need to / 160.0f, just use DisplayMetrics.density instead (and you need to properly round and handle negative values correctly). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#132 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGAblJmBErnf4IzdoB6M72YRpRZPWRwsks5tbtAfgaJpZM4R6ERs> .

[iglaweb]

@romainguy possible fix, round should be ok

fun Float.spToPx(displayMetrics: DisplayMetrics): Int =
        (this * displayMetrics.scaledDensity).round()
fun Float.dpToPx(displayMetrics: DisplayMetrics): Int =
        (this * displayMetrics.density).round()
private fun Float.round(): Int = (if(this < 0) ceil(this - 0.5f) else floor(this + 0.5f)).toInt()

[arekolek]

How about a small DSL that would make it possible to write stuff like:

view.context.pixelConversions {
    outRect.left = 80.dp
    outRect.right = 20.dp
}

Using the idea from the first post, that would be:

fun Context.pixelConversions(block: ConversionContext.() -> Unit) {
    block(ConversionContext(resources.displayMetrics))
}

class ConversionContext(private val displayMetrics: DisplayMetrics) {
    val Int.dp get() = toFloat().dp.toInt()

    val Float.dp get() = TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP, this, displayMetrics)
}

After trying to apply it in a different setting, I'm not sure how useful this idea actually is 🤔

(I forgot this repo is unused now, is this ticket tracked on google issue tracker?)