IssueTracker

First of all thanks for this detailed issue.

This issue had been investigated thoroughly when it was first reported internally. The surprising detail in this report is that the issue is not reproducible before 1.7. I will look into this.

The main problem with POBox is the fact that it is deprecated. Since 2021 Sony has been shipping new Xperia devices with Gboard pre-installed. Although we are aware that there is still a considerable amount of users still using POBox, the described behavior is caused by POBox's noncompliant behavior with InputConnection and InputMethodManager documentation. However, this is understandable since TextView implementation was also not respecting the behavior that is expected from Editors.

Ultimately we have decided to enforce the documented behavior with specifically regards to when editors should call InputMethodManager.updateSelection. Also, although unconfirmed, there were traces of possible custom code being included in Sony OEM images that changed how InputMethodManager was notified from TextView. If POBox also depended on something like this, it would be impossible for Compose code to replicate the same unknown behavior.

Just to be sure, it is dangerous to replace Compose TextField with Android View EditText as a workaround for this issue.

Compose 1.7 has a bug that causes ANR when the focus is on EditText. https://issuetracker.google.com/issues/369354336

Another View-related bug in Compose 1.7 is that an Android View is focused by calling FocusManager.clearFocus(). https://issuetracker.google.com/issues/374031296

Perhaps there is a lack of testing of Compose 1.7 in combination with Android View. There is also a possibility that there are other fatal bugs related to View.

In other words, the only options for apps targeting the Japanese market that require POBox support are to continue using Compose 1.6 or to use EditText in combination with various workarounds.

Project: platform/frameworks/support
Branch: androidx-main
Author: Halil Ozercan <halilibo@google.com>
Link:      https://android-review.googlesource.com/3317256

Fix POBox keyboard issue

Fix POBox keyboard issue 
 
Fix: 373743376 
Fix: 329209241 
Test: NullableInputConnectionWrapperTest 
Change-Id: I94e0e598274fb88b255f977f9fbd50dfbbb1ecb1

Many thanks again for this report. Especially for giving us a huge clue in terms of what could be going wrong. The fix is now merged and I will ask for a cherry-pick into a stable release.

Yes, this fix is planned to be included in a future 1.7.x release.

Thanks for the fix. Sorry to follow up on this. is it possible for you to share specific release version/date for the stable version? We are waiting on this to decide on our direction.

Can we just drop offset in favor of translate then?

It might be interesting to take into account the global positioning with the entire transform. I am not sure what happens in this case, but what if the text is rotated/scaled and text is selected, do the selection handles also rotate/scale to take this into account? I'm not sure what the intended behavior would be here, however, if we had these transformations report global positioning as well it would create a single spot of maintenance.

I think we should have the layer transformations update global bounds and deprecate Modifier.offsetPx and just keep translate. Is there anything else that Modifier.offsetPx provides that layer transformations do not that we should look into?

We should not avoid introducing the correct API usage in the event that a developer goes out of their way to provide a less optimal solution. I'm not sure I follow why layouts cannot leverage the layer based translation API which will always be more efficient as it just translates the underlying displaylist without re-measurement/re-layout or even invalidation of the layout itself. Additionally because we are introducing layers within a draw modifier implementation, we would need to have some concept of translation at the graphics layer so I'm not sure we can remove the translation API from layer itself.

It is up to the developer use case. If they are never translating the child composable after the fact, then this implementation is fine as is. However, if they intend on animating it afterwards then we should be pointing them to use Modifier.translate instead.

I added Matvei because I think he preferred opacity over alpha.

We can't remove offset/offsetPx as they are now as they are layout parameters and don't require a layer. I don't think we want to be adding layers for each offset, do we?

I think it is fine to have separate modifiers for rotation and scaling. We may even prefer to make only the simple versions (rotationZ and scaleX = scaleY) and require developers to use the graphicsLayer modifier for the fancier versions. They are convenience methods, after all, and only 1 liners.

I don't see any benefit from adding a translation modifier. I doubt it will be common use and, again, a two-liner if the developer makes it themselves. Most commonly, the developer will use offset + graphicsLayer to achieve the same thing.

We still need translation to do efficient movement/scrolling of children within a container. Additionally it is useful for modifying a composable in response to touch gestures (drag and drop). Using offset for these requires layout + measurement passes instead of just an efficient invalidation call (draw commands are not re-recorded).

I do like the 1 liners however, I am concerned that it forces developers to think of order of operations for multiple transformations which may introduce additional/unnecessary layers as a result. But generally speaking keeping the names consistent with the fields (i.e. using alpha vs opacity) is clearer.

Another thing to consider is how Modifier.offset is consumed within a composable container. For example we could have a FlexLayout composable that will always attempt to layout children from left to right until the available width is consumed. Then subsequent children will be positioned below the previous ones. I believe it would make sense for offset to contribute to the "reflowing" of content to the next line. However, if we wanted to translate content to be drawn on top and not contribute to reflowing of content (ex. for a drag and drop UI or text marquee) we would need to leverage translation here. While offset and translate are similar to do serve different use cases.

offset should not affect the measure pass, but it will have to rerun placement.

With respect to alpha/opacity, these terms may both be consistent, but with different surfaces. It may be that Material Design specifies "opacity," while the graphics engine specifies "alpha." I think that in this case, we should choose whichever is more familiar to the application developer.

offset should not affect the measure pass, but it will have to rerun placement.

The contents will measure the same way however in the FlexLayout example, an offset modifier placed on a single child will affect the layout placement of the other siblings in the composable container.

I think that in this case, we should choose whichever is more familiar to the application developer.

Should we stick to alpha to be consistent with View.setAlpha? We only used opacity within the Drawable#getOpacity API which used to be a hint for an internal optimization in the framework that is no longer done anymore.

Offset does not affect the placement of other siblings. It simply offsets the child.

The language around opacity may come from the Material spec. I am unsure and want Matvei's input here.

Hello! I used to prefer opacity since you are modifying the opacity of the component, not the "alpha channel". As far as I'm aware, material also prefers opacity, but since the API we're making here are not purely material, this is not super relevant I'd say.

Overall for me it's 60/40 preference for opacity over alpha. Also plus for opacity is that it's already familiar to compose devs. I will leave this decision up to you folks since I would be happy to have any of whose, especially without draw prefix :)

Layer is a design language agnostic API so I am not sure we should be leveraging material naming conventions here. Different design languages (holo, material, etc.) should be built on the foundation building blocks rather than building the foundation on design naming conventions. If we need to the material lib could have a typealias for Modifier.opacity that maps to alpha if we need to keep naming consistency. Also if we are helping to onboard traditional android framework developers keeping alpha here would help for discoverability.

For simplicity I'm thinking maybe we could just have the simplest shadow, alpha, scale and rotate APIs without including pivot point. I am still concerned with extraneous layer calls because it is more likely to do Modifier.scale(2f).rotate(45) than to do Modifier.drawLayer{ /* block */}.drawLayer{/* block */}. The overhead of this API surface scales worse as additional transformations are added on.

That being said, what about the following convenience APIs?

Modifier.shadow(elevation: Dp, shape: Shape, clip: Boolean) // same as Modifier.drawShadow just drop the draw prefix
Modifier.alpha(alpha: Float)
Modifier.rotate(degrees: Float) // (aka rotateZ) rotates about the center of the composable
Modifier.scale(scaleX: Float, scaleY: Float) // scales the horizontal/vertical dimensions about the center of the composable
Modifier.scale(scale: Float) // same as above except scales both horizontal and vertical by the same scale factor

All other use cases we can point the developer to use the Modifier.drawLayer API to rotateX/Y, rotate with a different pivot point, translate, configure camera distance, etc.

Thoughts?

Hehe... naming is always so complicated. :)

My 2 cents... I'm kind of fine with either "alpha" or "opacity" TBH. On one hand, "alpha" is nice because it's similar to what already exists in Android with View#setAlpha(). On the other hand, opacity is not difficult to understand (and is even used in SVG to apply opacity to nodes in the same way you apply alpha to Views on Android).

I tend to agree with you all that the 'draw' prefix is not necessary and goes against the conventions of other similar APIs.