Thanks Rob, understand...
When trialing on an iPhone 4s, [faster devices less noticable but still a hint of following problem] I touch a visable row on one table[call it A ] that creates a new table, and there is a delay of at least 500 miliseconds on the original viewed table touch [highlighted] before anything changes on screen, or more, and it appears to the user that the app has locked , a while.
There are about 52 rows on the new table [call it B] that we are waiting for. With 'just' 52 rows in table B the tableview list does not fill the screen in portrait[very narrow height rows]. In landscape only about 18 rows are visible [all very narrow to show a pattern like a chess board, 50 across]. Here in landscape only partly filled so last row never seen until user scrolls up.
When the original table A is touched, spinner:start() is called, then a change of storyboard scene occurs. Table B is then built in the new scene in the 'createscene' event. In the 'Rowrender' event each row has to examine data and highlight sections of the 'chess board' effect, looking at prior and expected next rows to map out the desired pattern, which takes some 'complex' processing time on each row render. Hence the need for spinner to appear while building the TableB, until the table is viewable on the screen. [ hence the request for an event that fires when the table has reached the limit and 'painted' (70 -end of, or 18 rows -only veiwable)-each case rows rendered has completed and now displaying on screen- however now due to possible processing bound multitalking lockouts (see below) another event may not solve this, becuase like you I had assumed things were happening too fast to see the spinner...].
In the code I stop the spinner in two places.
1. Stopped in the enterScene event when transferred from another scene:
[most of the time no spinner seen. Spinner was expected all the time on slower devices while table is built. The app appears very hesitant at touch row table A , the spinner should show because before gotoscene we do spinner:start(). In other scenes that do not do much processing, per table A row the spinner appears momentarily. So, in my view, it is something to do with multi-tasking. It would seem that a row render process can 'lock out' other activities if heavily processor bound. If this is the case ]
2. Or Stopped in the row render event, only when the table B is rebuilt within the same scene;
[Here we do spinner:start(), deleteRows and then rebuild the tableview list. In this situation we never see the spinner, I think due to so much processing in the row render event, within the same scene - no gotoscene here.]
However, after all that I still have some further thoughts on this following piont.
Note However: In portrait I physically see the last row appear in the row render event as it is on the screen. In landscape the last row does can not be physically seen [ so in theory but not desired, the spinner should be still shown spinning in landscape as the last row is not seen; this 'thought' highlighted the problem initially in testing. Here the spinner is seen still running!!
This means it is not 'a too quick to be seen' issue, but is a multiprocess lockout issue-because nothing is seen when table A does spinner:stop() before scene changes.Here in landscape the spinner is not seen until the actual tableview has finished appearing even in landscape and only 18 rows have been 'painted'
I hope this helps understand the raise forum subject, I have tried mainy other ways to get the spinner appearing in the process bound situation but without success. In other situations the spinner spins happily and is working fine e.g. while downloading asychrounously, other different scene to scene change and so on...
At one point I thought the spinner might be hidden, but if I do a spinner:stop() withdelay, of a few seconds then the spinner can be seen running after the table is completed in portrait or landscape...
Thanks for the feedback.