[AC-2134] iOS: Scrollview bug on SDK update (2.1.3.GA and 2.1.0.GA)
| GitHub Issue | n/a |
|---|
| Type | Bug |
|---|
| Priority | n/a |
|---|
| Status | Closed |
|---|
| Resolution | Invalid |
|---|
| Resolution Date | 2012-12-12T20:00:11.000+0000 |
|---|
| Affected Version/s | n/a |
|---|
| Fix Version/s | n/a |
|---|
| Components | n/a |
|---|
| Labels | triage |
|---|
| Reporter | Riccardo Zambon |
|---|
| Assignee | Shak Hossain |
|---|
| Created | 2012-10-30T15:56:46.000+0000 |
|---|
| Updated | 2016-03-08T07:41:06.000+0000 |
|---|
Description
Hi, I've developed an iOS (iPAD + iPHONE) application using Titanium 2.1.2 and Titanium SDK 2.0.1.GA2 on Xcode 4.3.2. This application uses both horizontal and vertical scrollviews (organized in a tree of three layer for details) to show many contents.
The source code for the scrollview tree creation is shown in the attached Visita.js
Here at each horizontal scroll a new "subtree" of scrollviews is created, in order to browse lower layers (views).
It works well for iPad IF I compile under Titanium 2.1.2 on Titanium SDK 2.0.1.GA2, Xcode 4.3.2.
The issue happens when I switch between 2.0.1.GA2 (Xcode 4.3.2) and 2.1.3.GA(Xcode 4.5.1), with NO code changes...
As shown in the attached videos, the horizontal scroll from a view to another one is fast by compiling under 2.0.1.GA2, and also details are created quite istantaneously to be browsed in vertical scroll.
By compiling under 2.1.3.GA the scroll between views is incredibly slow, unusable.
Furthermore, when the movie scrolls down, the view shown is not the correct one, and it is updated without interaction suddenly..
It seems that the new SDK needs much more time to do the same things done with the old SDK.
Finally, a view overlapping flashes..
it seems to be a Titanium SDK bug, no code changes are made between the two movies...
NOTE: the same happens when I compile from Titanium SDK 2.0.1.GA2 to SDK 2.1.0.GA (with the same xcode 4.3.2), so the issue could be in the transition to 2.1.0.GA
Attachments
I've added a note: This issue happens also when I compile from Titanium SDK 2.0.1.GA2 to SDK 2.1.0.GA (with the same xcode 4.3.2), so the issue could be in the transition to 2.1.0.GA
Is it possible to create a reproducible test case for this which doesn't require external files? Cheers.
Hi Daniel, sorry for the delay.. I have attached MuseoLight.zip file containing the Titanium Project. I have reduced the project, by deleting other views and windows which are not affected by the scrollview slowness bug reported. Briefly, the application is composed by a starting view where you can click on 'English', then on 'The Museum'. Here you access the scrollview part of the application. It is composed by three levels, in order to browse three (originally much more, as you can see by the movie) museum rooms, each room with several pieces, each piece with several details. Level1 Specifically, in the project you have three rooms: Mappamondo, Pace, Pilastri Level2 Mappamondo has 4 pieces, Pace has 3 pieces, Pilastri has 2 pieces. Level3 Mappamondo piece1 has 3 details, Mappamondo piece2 has 4 details, Mappamondo piece3 has 3 details, Pace piece1 has 4 details, Pace piece2 has 5 details, Pace piece3 has 4 details, Pilastri piece1 has 0 details, Pilastri piece2 has 0 details. ON THE CODE SIDE: by clicking on 'The museum' on the menu.js, you launch Visita.js Visita.js creates an array of views which will be scrolled horizontally, for all the rooms (viewSaleArray - by calling creaSale), for all the pieces concerning the first room (viewOpereArray - by calling creaOpere), for all the details of the first piece of the first room (viewDettagliArray - by calling creaDettagli). Furthermore, it creates the first "column" of views (Mappamondo room - all Mappamondo pieces - all Mappamondo piece1 details), for vertical scroll (viewVerticalArray). At each horizontal scroll, it creates the new "column" of views (for vertical scroll) by starting from the reached room. If you scroll horizontally at piece level, only details array for the reached piece are created. COMPILING: If you compile this project with Titanium SDK 2.0.1.GA2 and try it in on a real ipad (i.e. ipad 2 or new), everything will be OK, scroll is fast and you can reach immediately each image you want (i.e. by scrolling right-right-down you immediately reach pilastri piece1, with no flashings). If you compile this project with Titanium SDK 2.1.3.GA, 2.1.0.GA, 2.1.4.GA) and try it in on a real ipad (i.e. ipad 2 or new), the scroll is very slow, unusable. Furthermore, by scrolling right-right-down you does NOT immediately reach pilastri piece1, but you first see Mappamondo piece1 (with Mappamondo piece2 flashing up on the right), then it switches to Pace piece1 (with Pace piece2 flashing), then it reaches Pilastri piece1. Finally, Pilastri piece2 is visible (by scrolling right from pilastri piece1) when compiled with 2.0.1.GA2, but this is not reachable compiling with 2.1.0.GA, 2.1.3GA, 2.1.4GA... any ideas? Thank you for your time Riccardo
Hi Riccardo, Thanks for the test case. I don't have 2.1.0 installed, but I've tested and confirmed the issue between 2.0.3 and 2.1.2 GA. What's interesting is that on 2.1.2 the first and second scroll view rows lag when dragging horizontally, but the third row is smooth as expected. Vertical scrolling is also still smooth. As for your second issue, I think for now we should focus on the scroll lag. There's far too much code for me to go through and debug the logic, which actually will be much easier without the lag, and it may be related. It would be even better if you could further narrow down the horizontal scrolling lag issue, for example, we might be able to reproduce it simply by having 1 row, and you can try removing the sub views as well to leave just the images, and also take out the database. Our engineering team will want a more specific test case before I can move this to TiMob. Thanks!
Hi Daniel ok, I'm going to reduce the code in order to focus only on horizontal scroll. However, as you can see there is no problem (only a little delay, but acceptable) with 2.0.X SDKs, so I think that the problem is something concerning memory or processor allocation (inefficiency?) in 2.1.X SDKs. In fact, the delay in showing the Pilastri piece1 is a result of a loading delay of previous "column of views"... I also suppose that, if I remove the huge (but still accptable in 2.0.X SDKs) computational work needed to load subtrees (vertical views tree), images etc., the scrollview lag issue will smooth or disappear... but our app need such complexity to be a good app.. Actually, we need to "come back" to resource management of 2.0.X SDKs, hopefully preserving 2.1.X benefits for all the other issues. However, you'll receive the horizontal scrollview project as soon as possible (within tomorrow morning?) thanks so much Riccardo
Hi Daniel I've uploaded MuseoUltralight.zip only with 1 level on horizontal scrollview. As I suppose, the lag issue is not present here due to very low view complexity (I mantain the creation of pieces and details during the scroll between rooms but I do not attach them to a scrollview). I think the problem is in the creation of multiple views associated to the (alrady) created pieces and details at each scrol, maybe some memory or resource overuse of the new SDK? Actually, I think that is not possible to reduce the code thus mantaining the problem.. Any suggestion? How can I help you to better study this issue? thanks Riccardo
In 2.1.0 the scroll event in scrollable view was redefined. Use the scrollEnd event in the Visita.js file http://docs.appcelerator.com/titanium/latest/#!/api/Titanium.UI.ScrollableView-event-scroll
Event was redefined in 2.1.0 and clearly documented.
Hi Vishal, I've switched from scroll to scrollEnd and the app works fine Problem solved Thank you so much Riccardo
@Ricardo Glad to help.
Closing as per Riccardo's feedback.