Forem: Atsuko Fukui

Exploring the Impact of verticalScroll() on fillMaxHeight() Modifier in Android Compose

Atsuko Fukui — Sat, 13 Jan 2024 08:06:42 +0000

Encountering a peculiar situation in Android Compose where the Modifier.verticalScroll() seems to ignore Modifier.fillMaxHeight() when applied to the parent composable sparked my curiosity. Let me share my notes on what I discovered while digging into the internal workings.

What Caught My Eye

Consider this scenario: without verticalScroll() on the parent, the child's fillMaxHeight() behaves as expected.

@Composable
fun Sample(modifier: Modifier = Modifier) {
    Column(
        modifier = modifier
    ) {
        Text(
            modifier = Modifier.fillMaxHeight(),
            text = "Without verticalScroll",
        )
    }
}

However, once you add verticalScroll() to the parent, suddenly fillMaxHeight() is overlooked.

@Composable
fun Sample(modifier: Modifier = Modifier) {
    Column(
        modifier = modifier.verticalScroll(rememberScrollState())
    ) {
        Text(
            modifier = Modifier.fillMaxHeight(),
            text = "With verticalScroll",
        )
    }
}

I'm eager to understand the specifics of what verticalScroll() is doing to cause this shift in behavior.

Insight from the Official Documentation

The documentation sheds some light: "Modify element to allow to scroll vertically when height of the content is bigger than max constraints allow."
This suggests that if the content's size relies on the parent's size, determining whether to scroll or not may become challenging, leading to the observed behavior of being ignored.

Peeking into the Internal Mechanism

Let's take a closer look at what's happening inside Modifier.verticalScroll(). Skipping over some details, the crucial point is the utilization of ScrollingLayoutModifier.

fun Modifier.verticalScroll(
    state: ScrollState,
    enabled: Boolean = true,
    flingBehavior: FlingBehavior? = null,
    reverseScrolling: Boolean = false
) = scroll(
    state = state,
    isScrollable = enabled,
    reverseScrolling = reverseScrolling,
    flingBehavior = flingBehavior,
    isVertical = true
)

@OptIn(ExperimentalFoundationApi::class)
private fun Modifier.scroll(
    state: ScrollState,
    reverseScrolling: Boolean,
    flingBehavior: FlingBehavior?,
    isScrollable: Boolean,
    isVertical: Boolean
) = composed(
    factory = {


        val layout =
            ScrollingLayoutModifier(state, reverseScrolling, isVertical)
        semantics
            .clipScrollableContainer(orientation)
            .overscroll(overscrollEffect)
            .then(scrolling)
            .then(layout)
    },

The ScrollingLayoutModifier() seems to be the culprit as it's overwriting the child's constraints, setting maxHeight to Infinity, regardless of the original setting.

private data class ScrollingLayoutModifier(
    val scrollerState: ScrollState,
    val isReversed: Boolean,
    val isVertical: Boolean
) : LayoutModifier {
    override fun MeasureScope.measure(
        measurable: Measurable,
        constraints: Constraints
    ): MeasureResult {
        checkScrollableContainerConstraints(
            constraints,
            if (isVertical) Orientation.Vertical else Orientation.Horizontal
        )

        val childConstraints = constraints.copy(
            maxHeight = if (isVertical) Constraints.Infinity else constraints.maxHeight,
            maxWidth = if (isVertical) constraints.maxWidth else Constraints.Infinity
        )
        val placeable = measurable.measure(childConstraints)
        val width = placeable.width.coerceAtMost(constraints.maxWidth)
        val height = placeable.height.coerceAtMost(constraints.maxHeight)



        return layout(width, height) {
            val scroll = scrollerState.value.coerceIn(0, side)
            val absScroll = if (isReversed) scroll - side else -scroll
            val xOffset = if (isVertical) 0 else absScroll
            val yOffset = if (isVertical) absScroll else 0
            placeable.placeRelativeWithLayer(xOffset, yOffset)
        }
    }

This means that, with constraints' maxHeight set to Constraints.Infinity, the child's height becomes unbounded, effectively immune to the influence of the parent. Consequently, it adopts the height of the Text portion within the child.

For more insights into Compose's Layout and Constraints, you might find this reference useful.

How PendingIntent gets Activity with request key

Atsuko Fukui — Mon, 07 Jun 2021 13:14:47 +0000

Recently I wrote code like this for my Android app:

val requestCode = 0

val intentFoo = Intent(context, MyClass::class.java)
        .putExtra(KEY, "foo")
val pendingIntentFoo = PendingIntent.getActivity(
        this, requestCode, intentFoo, PendingIntent.FLAG_UPDATE_CURRENT)

val intentBar = Intent(context, MyClass::class.java)
        .putExtra(KEY, "bar")
val pendingIntentBar = PendingIntent.getActivity(
        this, requestCode, intentBar, PendingIntent.FLAG_UPDATE_CURRENT)

val notification = Notification.Builder(this, channelId)
            .addAction(Notification.Action.Builder(icon, getString(R.string.foo), pendingIntentFoo).build())
            .addAction(Notification.Action.Builder(icon, getString(R.string.bar), pendingIntentBar).build())
            .build()

I expected that MyActivity was launched with intentBar when I tapped bar action button in notification, but actually it was launched with intentFoo.

According to Document, we have to differentiate request code when we use multiple pending intent.

If you truly need multiple distinct PendingIntent objects active at the same time (such as to use as two notifications that are both shown at the same time), then you will need to ensure there is something that is different about them to associate them with different PendingIntents. This may be any of the Intent attributes considered by Intent.filterEquals, or different request code integers supplied to getActivity(Context, int, Intent, int), getActivities(Context, int, Intent[], int), getBroadcast(Context, int, Intent, int), or getService(Context, int, Intent, int).

In order to understand why intentFoo was launched, let's dive into the framework source code.

Firstly, PendingIntent#getActivity() calls ActivityManager#getIntentSender() internally.

public static PendingIntent getActivity(Context context, int requestCode,
                                        @NonNull Intent intent, @Flags int flags, @Nullable Bundle options) {
    String packageName = context.getPackageName();
    String resolvedType = intent != null ? intent.resolveTypeIfNeeded(
            context.getContentResolver()) : null;
    try {
        intent.migrateExtraStreamToClipData();
        intent.prepareToLeaveProcess(context);
        IIntentSender target =
                ActivityManager.getService().getIntentSender(
                        ActivityManager.INTENT_SENDER_ACTIVITY, packageName,
                        null, null, requestCode, new Intent[] { intent },
                        resolvedType != null ? new String[] { resolvedType } : null,
                        flags, options, context.getUserId());
        return target != null ? new PendingIntent(target) : null;
    } catch (RemoteException e) {
        throw e.rethrowFromSystemServer();
    }
}

From it PendingIntentController#getIntentSender() is called through ActivityManagerService.

public PendingIntentRecord getIntentSender(int type, String packageName,
                                           @Nullable String featureId, int callingUid, int userId, IBinder token, String resultWho,
                                           int requestCode, Intent[] intents, String[] resolvedTypes, int flags, Bundle bOptions) {
    synchronized (mLock) {

...

        PendingIntentRecord.Key key = new PendingIntentRecord.Key(type, packageName, featureId,
                token, resultWho, requestCode, intents, resolvedTypes, flags,
                SafeActivityOptions.fromBundle(bOptions), userId);
        WeakReference<PendingIntentRecord> ref;
        ref = mIntentSenderRecords.get(key);

Please note that in the last line we get IntentSenderRecord with PendingIntentRecord.Key. Let's check equals() method of PendingIntentRecord.Key.

@Override
public boolean equals(Object otherObj) {
    if (otherObj == null) {
        return false;
    }
    try {
        Key other = (Key)otherObj;
        if (type != other.type) {
            return false;
        }
        if (userId != other.userId){
            return false;
        }
        if (!Objects.equals(packageName, other.packageName)) {
            return false;
        }
        if (!Objects.equals(featureId, other.featureId)) {
            return false;
        }
        if (activity != other.activity) {
            return false;
        }
        if (!Objects.equals(who, other.who)) {
            return false;
        }
        if (requestCode != other.requestCode) {
            return false;
        }
        if (requestIntent != other.requestIntent) {
            if (requestIntent != null) {
                if (!requestIntent.filterEquals(other.requestIntent)) {
                    return false;
                }
            } else if (other.requestIntent != null) {
                return false;
            }
        }
        if (!Objects.equals(requestResolvedType, other.requestResolvedType)) {
            return false;
        }
        if (flags != other.flags) {
            return false;
        }
        return true;
    } catch (ClassCastException e) {
    }
    return false;
}

You can see requestCode is used here. If the package name, activity. the result of filterEquals(), requestCode and so on are all same, they're considered as equal.

Let's look at the detail of filterEquals(). We don't check extra as long as we don't override this method.

public boolean filterEquals(Intent other) {
    if (other == null) {
        return false;
    }
    if (!Objects.equals(this.mAction, other.mAction)) return false;
    if (!Objects.equals(this.mData, other.mData)) return false;
    if (!Objects.equals(this.mType, other.mType)) return false;
    if (!Objects.equals(this.mIdentifier, other.mIdentifier)) return false;
    if (!(this.hasPackageEquivalentComponent() && other.hasPackageEquivalentComponent())
            && !Objects.equals(this.mPackage, other.mPackage)) {
        return false;
    }
    if (!Objects.equals(this.mComponent, other.mComponent)) return false;
    if (!Objects.equals(this.mCategories, other.mCategories)) return false;

    return true;
}

Let's go back to getIntentSender method. After getting IntentSenderRecord, we replace extras completely in case of PendingIntent.FLAG_UPDATE_CURRENT flag.

public PendingIntentRecord getIntentSender(int type, String packageName,
                                           @Nullable String featureId, int callingUid, int userId, IBinder token, String resultWho,
                                           int requestCode, Intent[] intents, String[] resolvedTypes, int flags, Bundle bOptions) {
    synchronized (mLock) {

...

        PendingIntentRecord.Key key = new PendingIntentRecord.Key(type, packageName, featureId,
                token, resultWho, requestCode, intents, resolvedTypes, flags,
                SafeActivityOptions.fromBundle(bOptions), userId);
        WeakReference<PendingIntentRecord> ref;
        ref = mIntentSenderRecords.get(key);
PendingIntentRecord rec = ref != null ? ref.get() : null;
        if (rec != null) {
                if (!cancelCurrent) {
                if (updateCurrent) {
                if (rec.key.requestIntent != null) {
                rec.key.requestIntent.replaceExtras(intents != null ?
                intents[intents.length - 1] : null);
                    }

    /**
     * Completely replace the extras in the Intent with the extras in the
     * given Intent.
     *
     * @param src The exact extras contained in this Intent are copied
     * into the target intent, replacing any that were previously there.
     */
    public @NonNull Intent replaceExtras(@NonNull Intent src) {
        mExtras = src.mExtras != null ? new Bundle(src.mExtras) : null;
        return this;
    }

Now I understand why intentFoo was launched👍

[Kotlin 1.4] Suspend conversion on callable references is supported

Atsuko Fukui — Sat, 09 Jan 2021 04:49:18 +0000

From Kotlin 1.4, suspend conversion on callable references is supported 🎉 Release note doesn't say much about this feature but it's really helpful when you use Flow#combine().

Let's pretend you want to combine two flows and use them in collect(). Before Kotlin 1.4, you may write code like this:

suspend fun before4_1() {
    combine(
        flowA, flowB
    ) { a, b ->
        a to b
    }.collect {
        val a = it.first
        val b = it.second
        println("$a and $b")
    }
}

val flowA = flowOf(1, 2)
val flowB = flowOf(3, 4)

This code is kind of redundant and doesn't look great (too much as and bs! 😩)

From Kotlin 1.4, you can simplify the above code.

suspend fun from1_4() {
    combine(
        flowA, flowB, ::Pair
    ).collect { (a: Int, b: Int) ->
        println("$a and $b")
    }
}

val flowA = flowOf(1, 2)
val flowB = flowOf(3, 4)

Before Kotlin 1.4, this code causes compile error because the type of the 3rd parameter of combine() is suspend function. Pair class constructor is not a suspend function so compile error will occur. From Kotlin 1.4, this 3rd parameter lambda will be converted to suspend function automatically and work fine.

Bounus: I use destructuring declarations for the parameter of collect().

    ).collect { (a: Int, b: Int) ->

We can name values of pair.first and pair.second here. Type definition can be omitted but () is necessary.