[TIMOB-26283] insertAt not working as expected
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Medium |
Status | Closed |
Resolution | Not Our Bug |
Resolution Date | 2018-10-29T22:13:02.000+0000 |
Affected Version/s | n/a |
Fix Version/s | n/a |
Components | n/a |
Labels | n/a |
Reporter | Yordan Banev |
Assignee | Yordan Banev |
Created | 2018-08-10T10:28:08.000+0000 |
Updated | 2018-10-29T22:13:05.000+0000 |
Description
On Android inserting children in a view with defined layout (I have tested only with
vertical
so far) ends with a different result based on what order the method is called even if the position
property matches. In the attached sample the views on the left are added in descending order based on the position index and the views in the right container are added in ascending order based on the same. IMO it would make sense for the end result to be the same no matter in what order the method is called if the positions match.
After clicking the button to replace the view with index in the left container you can notice that it is not only changing color - from gray to red, but also changing its position. Having in mind that the left
property is 15 units multiplied by the position index it should remain in the same position. After the replacement the new view takes position which is the same as the view with index 3 in the right container. Which is the expected position.
-I haven't tested that on iOS and I don't know what is the behavior in such case.-
[~topener] ran the sample on iOS and we get the exact same behavior. Is this the intended behavior?
Attachments
File | Date | Size |
---|---|---|
app.js | 2018-08-10T10:28:04.000+0000 | 979 |
insertAt.png | 2018-08-10T10:46:35.000+0000 | 78862 |
iOS-Screenshot-WithNumbers.png | 2018-08-28T03:25:59.000+0000 | 23650 |
replaced.png | 2018-08-10T10:46:35.000+0000 | 78844 |
Simulator Screen Shot - iPhone X - 2018-08-10 at 12.40.22.png | 2018-08-10T15:16:04.000+0000 | 65395 |
Simulator Screen Shot - iPhone X - 2018-08-10 at 12.40.52.png | 2018-08-10T15:15:58.000+0000 | 65397 |
[~ybanev], I haven't look at this yet, but I do remember fixing
insertAt()
withScrollViews
last year. Please see the "ScrollViewAddRemoveTest.js" file attached to ticket [TIMOB-25415]. It allows the end-user to insert/remove rows in a vertical layout dynamically by tapping on them.I just test this out. I'm not convinced this is a bug in Titanium. And the behavior between Android and iOS is the same too. Let's have a look at the following...
Note that
viewLeft
is empty before entering the above for-loop. OurinsertAt()
method will not allow a position index to be set higher than the number of children. So, a position index of 6 while the child count is 0 causes the actual insert position to be 0. When you attempt to insert the 2nd view at position index 5, it ends being inserted *after* the 1st inserted view. And the reason why the left child views appear *staggered* is because you're inserting backwards and the last half of the inserted views will have valid position indexes. * View6 -> insert index 6 -> [View6] * View5 -> insert index 5 -> [View6, View5] * View4 -> insert index 4 -> [View6, View5, View4] * View3 -> insert index 3 -> [View6, View5, View4, View3] * View2 -> insert index 2 -> [View6, View5, View2, View4, View3] * View1 -> insert index 1 -> [View6, View1, View5, View2, View4, View3] * View0 -> insert index 0 -> [View0, View6, View1, View5, View2, View4, View3] So, when you do areplaceAt()
at position index 3, you're really replacing View5 whose "left" property was original set to75
, not45
. If you change yourcreateView()
to the a label like the below, then you can see what I mean.Below is a screenshot with the views numbered. !iOS-Screenshot-WithNumbers.png|thumbnail!
I tried it on native Android as well. It does not work as I thought there too. It throws an
Out of bounds
exception. This behavior is fine. Leaving it as is.