Architectural approach to handling swiping back an

2019-09-09 05:51发布

问题:

I am developing an app in MonoTouch for iOS.

A big part of the functionality is that the user will need to swipe between pages (screens) of data continuously and go back and forth.

I need to keep in mind memory consumption, so my thought is I could only have a few screens in memory at a time. For example, lazy load the next 1 screen ahead of time only, so it's available when the user swipes to it. (Or lazy load on swipe).

When the user swipes back to a previous page they were on, I need to make sure that that page is still in memory and hasn't left memory. Pages that are a few behind, I can lazy re-load once the user swipes back. Therefore, I will need a mechanism to send screens to GC if they have not been viewed by the user in a while and have them automatically loaded when the user swipes to that page.

I was thinking of creating a List of objects where each object has information about what to display on the view along with a reference to the actual view itself. If this reference is null, I know to create the view. If the reference exists and is not disposed I can just show the user that existing reference. As the user swipes left and right, I can go to the next (or prev) item in the list and do the same thing. Check if it has a view reference and load that view, or create it.

Performance is key here, as the user may be swiping through potentially hundreds (or more) of screens.

Any thoughts on the best architecture for speed and memory management?

回答1:

Key would be to reuse views if possible. In my app I have swiping left/right similar to what I think you want, and I just have to create up to three views: one for "on screen" and then right/left off-screen (although left is not created until needed).

You can get pretty creative by doing as much as possible related to your page build-out in a thread and just update the UI on main thread. Also I definitely focus first on the to-be visible page when loading new dataset before moving to the right not visible page and, if it makes sense, left not visible page. When user swipes to new page, the views get reused and moved around the larger UIScrollView content area.