I have a long list of items I need to load in scrollview.
Currently I'm iterating over the list and adding it. But since the list is long the scrollview is extremely slow when loading and scrolling.
Is there a way to only have the items from the list that are suppose to be on screen loaded instead of loading all items?
Or is there another technique that can be used?
Use this.
https://github.com/Mukarillo/UnityDynamicScrollRect
Its a custom scroll view someone wrote that only loads the visible elements. You just have to write a custom function for instantiating the elements
Related
In React and other web front-end frameworks, there is the concept of 'conditional rendering'. You render certain elements of the UI to the DOM based on certain conditions being true or not.
How does the concept of conditional rendering work in Xcode / Swift? Since you apparently build the UI on the storyboard, I don't know how to conditionally render elements.
A specific example: Let's say I've got an array of arrays and for each array in the array I want to render a tableview. How would I approach this problem?
Short answer: "It doesn't." That's not how iOS works.
Edit:
You can certainly write code that builds your UI from code, and if you do that, you're free to use conditional logic to decide what elements to add to your UI.
In fact, SwiftUI uses code to build a UI, and is a reactive style development platform. You should look into that.
A UITableView, as in your example, is a data-driven UI element. It uses a data source to decide what cells to display. Depending on the types of entries in the data source, it might create different types of cells. That is similar to what you describe.
It doesn't really make sense to have multiple table views on screen at once, so I'm not sure what "...for each array in the array I want to render a tableview" would look like.
I guess you could write a view controller that had a scroll view as it's content view, and when it loaded, it took your array of arrays, and used the outer-most array to decide how many instances of table views (or table view controllers, better yet) to instantiate. It would create table views/table view controllers in a loop, and install their views into the scroll view, keeping track of the geometry. Altnernately, you could put the table views in a stack view, and put the stack view into a scroll view.
However, the UX would be awkward. The user would need to drag up and down inside each table view to navigate inside it, and also drag up and down on the scroll view in order to move between table views.
Let's say I've got an array of arrays and for each array in the array I want to render a tableview. How would I approach this problem?
You would write code—presumably, Swift code, since you used the swift tag.
Let's make it even more concrete. You have a Bookcase object which has an array of Shelf, and each Shelf has an array of Book.
If you're using a storyboard, you can have a ShelfController scene in your storyboard with a single table view to display the Books in one Shelf. You can also have a BookcaseController scene with (let's say) a stack view. The stack view has no subviews because you don't know, when designing the storyboard, how many shelves you'll need to display.
Then, in Swift code, when BookcaseController is given its Bookcase model object, the BookcaseController instantiates the ShelfController scene once for each Shelf in the Bookcase. It adds each ShelfController as a child view controller, and adds each ShelfController's view (a table view) as an arranged subview of its (the BookcaseController's) stack view.
Let's say I've got an array of arrays and for each array in the array I want to render a tableview. How would I approach this problem?
You'd probably display a list of all the arrays (or whatever each array corresponds to) and a table. When the user selected one of the things in the list, you could then set the table view's data source to use the corresponding array.
That's not the only way, of course. If you really want to draw different tables for each array in the list, you can do that — you're in charge of your code. But why make things more complicated?
Since you apparently build the UI on the storyboard, I don't know how to conditionally render elements.
Storyboards aren't the only way to build a UI, and they're also a lot more flexible than just a static collection of elements. A storyboard is essentially a collection of connected scenes, where each scene is a template for a screenful of content. But your code can adjust the objects in a scene, including hiding or showing them, changing their position, and adding ore removing views. So if you want you could have a scene with a different table for each of the items in your list, and then just adjust the visibility of the various tables according to whatever thing is selected. Or you could have no tables at all, and your code could create one on the fly and insert it into the view.
In short: you're assuming too much about how storyboards work. Start reading about how view controllers work and you'll soon have a much better understanding of the kind of control you have over the UI.
I am trying to build this view where I have a UI Image view with some labels below it. And then Below this I have a Collection view which has a few items. I am struggling to figure out how I could have this view such that the whole screen keeps scrolling up once i get to the collection view.
Right now, the image view and the labels below scroll, but then the collection view only scrolls within its constraints. What I want is the entire screen to scroll up so the collection view items fill the screen up. I have seen several other replies to similar questions but am unable to follow it.
Can someone help with what I am doing wrong here ?
For the best practice on mobile programming, you should not have a scrollable view in another scrollable view. If you do so, you will have the problem as you described that your child collection view starts to scroll while other elements like your imageview and labels stay there.
To achieve your point, you can simply use a collection view and have custom cells. Now your entire window has only one scrollable view so it looks better. Then you are basically have different cell types. On top you have a collection cell as image, then you have few collection cell as labels, and so on.
I have a large number of custom views (all the same class) in a scroll view and I'm frequently getting memory warnings. Is it possible to somehow only allow a view to draw when it's about to be displayed and then release that view when it's no longer being displayed (i.e. it's been scrolled past) to reduce memory usage?
If you want to reduce the memory usage of views within a scroll view a better approach consist to define a set of views and reuse them during the scrolling process by putting them in a queue. This requires some work. I don't know how you want to layout your views but if it is a in a grid you can find some third parties libraries that does just that. One of the most famous one is called GMGridView it worth taking a look to understand how the views are being queued.
In the end I managed to solve this issue by removing all the unneeded sub views when one sub view was selected to be viewed in full and then adding them again afterwards because this isn't a hugely costly process.
In my iPad application, I've made a segmented control and one segment of which -when clicked- displays a long list (about 300) with images and labels from the local SQLite database. This is taking a lot of time to load and puts the app activity to halt while it's loading all of it from the database.
Although I've applied an activity indicator for the time being, but that looks very shoddy. Can anyone tell me how to apply Lazy Loading in a way that When the button is clicked to open that view, instead of loading all the content at once, it fetches only the content that's displayed on the content initially (about 9 images with lablels).
Thanks in advance.
You should implement paging on the list. Load first 25 item and then add button ("Next 25") on tableFooterView, which will load another 25.
If you use a UITableView, you might have a better chance.
A UITableViewCell loads cells one at a time(gives you the index of the item it is trying to load), so if you use a table view, it will only load the number of items that it needs to display. You tell it how many items there are, how tall they are, etc.
It also reuses cells, so it gives a lot better performance than creating 300 different views in memory at a time.
A UIScrollView doesn't know about your "items", so it lets you push as many items as you want into a view, and then adds a scroll bar. No optimization here for memory usage, or database access.
I'm working on making a special UIScrollView to show a timeline of events, (Like a gantt chart if you're familiar with such things) and there could potentially be dozens of these events, some visible and some not at different times.
What I'm wondering is this: should I make an implementation similar to UITableView to remove the items that have scrolled out of sight, and reuse the views for other items as they come into the screen?
It seems like it could take some work, and I don't want to waste time on it if this isn't something that will affect performance on a small scale.
I'm getting the idea from the UIScrollView class reference:
"The object that manages the drawing of content displayed in a scroll view should tile the content’s subviews so that no view exceeds the size of the screen. As users scroll in the scroll view, this object should add and remove subviews as necessary."
Thanks for any help.
It depends on how much memory each item in the scrollview requires. You cant really tell unless you build it or provide more information about exact amounts and what each element in the UIScrollview contains. Removing items that are not visible is not a massive job but it can have some problems. I would first try it without removing them and optimise the elements that you add to the scrollview so they use as little memory as possible and then use instruments to check your mem usage. Then go from there. Hope that helps.