WAI
Status Update
No update yet.
Comments
lb...@gmail.com
I guess hidden should just be defined. Meaning, right now, hidden should just defined as "whether this fragment was hidden as part of a transaction". Hidden is not equivalent with visibility. I think that's where the confusion comes from.
lb...@gmail.com
We have passed this to the development team and will update this issue with more information as it becomes available.
lb...@gmail.com
Yeah, I'm seeing this issue as well, currently this is the workaround that I've come up with:
// This method is called when hide()/show() methods are called on the transaction. Unfortunately Android doesn't
// propagate it to the child fragments (even though their visibility is affected by the parent visibility), so we
// do it manually.
override fun onHiddenChanged(hidden: Boolean) {
super.onHiddenChanged(hidden)
childFragmentManager.fragments.forEach { it.onHiddenChanged(hidden) }
}
// This method is called when hide()/show() methods are called on the transaction. Unfortunately Android doesn't
// propagate it to the child fragments (even though their visibility is affected by the parent visibility), so we
// do it manually.
override fun onHiddenChanged(hidden: Boolean) {
super.onHiddenChanged(hidden)
childFragmentManager.fragments.forEach { it.onHiddenChanged(hidden) }
}
en...@google.com
ro...@google.com
@4 That actually won't technically fix as isHidden() will technically mismatch with the state passed into the child fragment. Each child fragment legitimately needs to have their state set to hidden.
lb...@gmail.com
Yeah, I realized that as I kept working further on it. Nevermind that solution, it doesn't work.
lb...@gmail.com
@6 I don't know what the ramifications are, but when you iterate, you can save the "currentState" and then hide them all via a transaction. When restoring to visible, restore to the original state.
Description
- Steps to reproduce the problem (including sample code if appropriate).
Try to develop an app, that shows a text inside a TextView, where the words are aligned in RTL (right to left) order. The words are:
1. a Hebrew word, like "שלום" (means "hello"/"peace") .
2. an English word, like "world"
3. a number, like 67 .
- What happened.
The problem is that no matter if you edit it in Android-Studio or any other text editor, and no matter how it looks to you in each tool and what the real order of the words is, you will get issues.
The kind of issues you will see are at least one of those:
1. wrong order of words compared to what was typed/shown.
2. wrong alignment of what is shown.
3. even if usually everything looks ok, if the text is too long to be inside the TextView bounds, the Hebrew word actually goes below the rest That's even though it should be considered as the first word. Sadly, this is actually logical, as the only way to solve this issue is to enter the numbers part, then the English part, and lastly the Hebrew part.
- What you think the correct behavior should be.
There should be a way to overcome this.
The tested Android version is 5.1 , but the same issue occurs on any other Android version.
I've attached an image showing the issue. Also attached the sample project with this issue.
The sample shows all possible combinations of the 3-parts-texts (which is 6 in total).
Even though the last TextView in she sample seems ok, if you set it to have 100dp of width, you will see
I know this is a complex issue, but there should be a way to overcome this no matter what, and I've tested all possible combinations already.
It would be best if there would be a compat-TextView to solve such things for all Android versions.