[TIMOB-1971] Android: Optimize TableViewRow Layout with Same Classname
| GitHub Issue | n/a |
|---|---|
| Type | Bug |
| Priority | Medium |
| Status | Closed |
| Resolution | Fixed |
| Resolution Date | 2011-04-17T01:57:41.000+0000 |
| Affected Version/s | n/a |
| Fix Version/s | Release 1.5.0 M04 |
| Components | Android |
| Labels | android, defect, performance |
| Reporter | Don Thorp |
| Assignee | Don Thorp |
| Created | 2011-04-15T03:06:55.000+0000 |
| Updated | 2011-04-17T01:57:41.000+0000 |
Description
We got a clarification today that TableViewRows that have the same structure are not allowed to change their layout. Previously we interpreted that they had to have the same controls in the same order, but layout might not be identical.
Optimize Rows such layout only occurs when a new internal row is created and when reused, only the data from each control is applied, not layout.
(from [e18980e31ba5c0e061da3ababd711467471bffeb]) pre-seed a relatively large number of row types so we can avoid calling setAdapter to tell the ListView about new row types (which causes all kinds of memory / model havoc). added a new forceCreateView in TiViewProxy to simply assign the internal view reference to a new instance, rather than forcefully tearing down the existing view. this fixes the className redrawing bug when the ListView recycler shuffles reused view instances [#1971 state:fixed-in-qa] [#2377 state:fixed-in-qa] [#2344] https://github.com/appcelerator/titanium_mobile/commit/e18980e31ba5c0e061da3ababd711467471bffeb"> https://github.com/appcelerator/titanium_mobile/commit/e18980e31ba5...
used KS example for linked bug to close this.[INFO] Titanium SDK version: 1.5.0 (12/08/10 08:34 4ee1205) G2 + 2.1 sim