Layout after resizing

I am creating a grid that displays values ​​that change very often. Because of this, I use TextView, which automatically analyzes when its contents change ( Auto Scale TextView Text to Fit Within Bounds ). Resizing takes place, but the view is not properly formatted

layout after resize

The fact is that when I view an action using the HierarchyViewer , the layout is displayed the way I want.

layout after hierarchyviewer

I assume that the HierarchyViewer calls requestLayout () or invalidate () in the view, but I tried this without success. This code is called in the main action without effect.

new Handler().postDelayed(new Runnable() { @Override public void run() { getWindow().getDecorView().requestLayout(); getWindow().getDecorView().invalidate(); } }, 5000); 

I also tried to invalidate the view after resizing.

TextView has gravity set to Center, and if the size does not change, it looks fine.

Any hint would be welcome, thanks in advance!

+7
source share
3 answers

I solved it by overriding onLayout in one of the TextView parent and using the handler created in the constructor

 public class CellView extends LinearLayout{ public CellView(Context context) { super(context); mHandler = new Handler(); View.inflate(context, R.layout.cellview, this); } @Override protected void onLayout(boolean changed, int left, int top, int right, int bottom) { if(changed){ mHandler.post(new Runnable() { @Override public void run() { requestLayout(); } }); } super.onLayout(changed, left, top, right, bottom); } 

I tried calling requestLayout inside the TextView onLayout, but this did not work, I'm not sure why. Perhaps this is due to the fact that the value was updated via Observer, but the onTextChanged listener should happen in the user interface thread. I hope that he will serve someone else.

+2
source

The requestLayout() method is that when called in the view, it plans the layout schedule itself and all its children. This is advisable whenever the view is shifted or changed in accordance with changes to fields, additions or content.

The documentation for the getDecorView() method is not entirely clear what exactly it gives you. However, in the documentation for the website :

Note that calling this function for the first time “blocks” the various characteristics of the window, as described in setContentView (View, android.view.ViewGroup.LayoutParams).

This leaves me to believe that there is something special about the relation that getDecorView() returns. What you are probably doing is that the persistent view layout never changes when you make the requestLayout() pass.

This is apparently the right way to get the root view of all your activities.

However, for efficiency reasons, I recommend calling requestLayout() on the youngest child you may be able to. As I said, he plans to go through the layout for viewing and these are the children. If you make the layout at the top level, you will fundamentally rebuild everything that includes the views that remain in place.

+2
source

You probably need to run the timer code in the user interface thread using runOnUiThread , as described.

0
source

All Articles