[AC-879] Delay in View Re-layout / Invalidation (Android)
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | n/a |
| Status | Closed |
| Resolution | Invalid |
| Resolution Date | 2016-03-05T06:29:58.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | n/a |
| Components | Titanium SDK & CLI |
| Labels | n/a |
| Reporter | Kiley Williams |
| Assignee | Shak Hossain |
| Created | 2016-03-04T17:49:28.000+0000 |
| Updated | 2016-03-08T07:37:10.000+0000 |
Description
Before expanding the views, the child view’s top values are set to -200 to be hidden from the interface. Upon header view click, we set the top values to the necessary values in order to expand and display the child views. Upon minimizing the views, we set the top values back to -200. You can see that the expansion does not cause any delays, but in minimizing, part of the child views are still visible. There are still visible until the user makes a gesture on the app. Upon research, it seems that it may be because postInvalidate() is called in the Ti.UI.View after “top” value is changed and it seems that invalidate() should be called instead. We investigated TiUIView.java as well, and only found postInvalidate() calls, rather than invalidate() calls.
Please see the following video for a visual reproduction of the issue: https://youtu.be/bW9uzULWb6c
The video shows a side-by-side comparison of how it works correctly on iOS, and how it has an issue on Android.
This was found to be not a bug, and rather a missed accounting for the way Android handles child views on the part of the developer. Thanks! This can be closed.
[~Yrkh8trnoy] could you elaborate a bit on this? {quote}missed accounting for the way Android handles child views on the part of the developer{quote}
Hi, so I was creating some test code as some other developers from TiSlack was willing to help. While I was creating the test code, I was adding more properties than I usually would because I was stripping it from its giant code that it came from. The test code didn’t run into any of the relayout issues in either the android and ios. So I’ve applied the extra properties to my original code and that have fixed the properties. It seems that at least for the android, parent views do not position themselves the same way as ios and you need to explicitly position them. Sorry for any inconvenience.
Thanks [~melissa7mb]. Still, I'd love to hear what properties were missing that triggered this unexpected behaviour for Android. It still could be a valid parity bug.
So the property that altered this for the Android was setting the "top" value for the views to 0 manually. For iOS, on a vertical layout I did not need to the top values for the children or parent views and it relayed out fine. When I had created the test code, I had actually manually set the top value of a all children and parent views on a vertical layout to 0. This had no affect for iOS, but manually setting the values for Android had solved the layout issue.