Right now, I have a collection view with scrolling inside a view.
I'd like the collection view's height to expand downward depending on how much content it has and not have any scrolling.
A user would then scroll from the outside view.
The collection view is the last section in the screenshot:
I tried using a table view with one cell having a collection view and that did not work.
"I am fairly new to Swift..."
You may want to first spend some time researching different ways to layout UI elements.
Depending on how many "repeating" elements you'll potentially have, you might want to take this approach:
If you'll potentially have many, many "repeating" views (cells), you might be better off using a collection view - with its built-in memory management - using one of these approaches:
Or, possibly a collection view with a Compositional Layout.
In any case, trying to "expand the collection view to show all the cells and then scroll the whole thing" defeats the purpose of using a collection view, and is rarely the appropriate way to go.
Related
I have two collection views with data loaded from an API. the data varies that means that the heights of each of the collection views should be varying. I have tried putting all of them ( 2 collection views and a label between them ) inside a scroll view but that doesn't work because I cannot tell the size of the contents before the data is loaded. How can I do this?
For many reasons, this is should not be the layout of choice for you in this situation. First, the collection views cannot determine their own size based on the size of their content, because they are in fact scroll views – and it would be weird for a scroll view to always scale to the size of its content, it would never scroll at all if it did. Second, as each of the collection views is a scroll view, you would have a hierarchy of scroll views which is hard to handle for the user, let alone the developer.
What I suggest instead is to use a single UICollectionView with multiple sections. You can also implement your own UICollectionViewLayout to suit your needs.
Need some suggestion. I am trying to create an interface as shown in the attached image. So its a horizontal parallax effect. Have you guys created something similar and give me some idea on how to proceed. Any library which can be used? Catch here is the element in RED which stretches across multiple views.
Another idea around this, do you think it would make more sense to have one view where i can show just part of the view based on user navigation. My only concern with this is it may become more complex if i have to support multiple display sizes.
I've implemented something like this with nested collection views. The top level horizontally scrolling collection view would have a custom layout object that added a decoration view holding your background behind the items.
You can setup the layout object to invalidate its layout on bounds changes, and pan around the decoration view position relative to the content offset of the collection view to get the parallax effect.
Then you would just need a collection view cell with a nested vertically scrolling collection view in it, which you could create 3 of (or however many you wanted).
Question: What happens to references to a collection view cell when it is scrolled offscreen and reused? All my attempts to supply cells without using "dequeue" have failed. Is there a way to tag a cell as non-reusable, so the collection will keep it around? I want to tell the collection "Hey, don't reuse this cell yet!".
Long story: I have a collection view where each cell has a collection view in it. I am using a custom layout (https://github.com/lxcid/LXReorderableCollectionViewFlowLayout) on the sub-collection views to enable dragging and reordering of cells, but I want to extend this to allow dragging cells from one collection view into another. I have it working, except that if a cell is dragged from a collection view that is then scrolled offscreen during the drag, it breaks because the layout handling the gesture, and its collection view, have been reused. The cell with the collection view and reorder-able layout is still doing work, and I need it to not get reused.
Thanks for sharing the long story. It helps to see what you're trying to do. I can understand your approach and can see why you might initially think this is a good logical approach.
However, I'll try to convince you to try to use another approach. The common approach is to take a snapshot of the view during the drag, then add it to the superview and move it around with the drag from one collection to another. Let me know if this approach makes conceptual sense.
I'm starting my development of an ios app using ios 6 and UICollectionView.
I've noticed there's support for both supplementary views and decoration views.
Can someone please explain in bullet points the difference between the two? They sound very similar.
If I want to add a loader to my collection view (that will appear at the bottom of each section, while the section is loading) should it be a supplementary view or a decoration view?
Thanks
Decoration views are just what the name says: decoration, chrome. Only the collection view layout decides what they are and where to put them (for instance, if you want to draw lines on the screen every 5 items).
Supplementary views are more related to your data. The collection view layout still decides where to put them, but they are provided by the collection view data source, just like regular cells. For instance, if you wanted to put titles for sections, you would use supplementary views because the title would be different for each section and you need to call the data source for each.
If your loader is generic, it could be a decoration view, however decorations views are not really accessible (the layout object says where to put them, and that is it, they are created by the collection view and you never get a reference to them), so if you want to start/stop animating it, a decoration view is not the best choice. If you use a supplementary view, then you have access to it at creation time (in your data source collectionView:viewForSupplementaryElementOfKind:atIndexPath: method). However, you can only query the collection view for regular data cells once they are laid out on screen.
Also, you will have to write your own UICollectionViewLayout class if you want to use custom decoration or supplementary views. The base UICollectionViewFlowLayout only provides for a footer and a header supplementary view.
from UITableView perspective :
Supplementary = sections.
Decoration = tableFooterView tableHeaderView
I am trying to create a table view, in which the table view cells contain a scroll view. The scroll view can contain one or two pages of one image view each. Note that the scroll view will only scroll horizontally, so it will not interfere with the Table View's scroll view that will scroll vertically. Depending on the content, I want the scroll view to be updated with these image views, and set the scroll view content size according to responses I receive from a server, instructing the application what images to display.
In order to do that, I initially thought of creating a custom UITableViewCell subclass, and do all my initialisation of the views inside that.
However, I am just thinking about performance and memory. I know that iOS automatically deallocates already seen views and cells, when it needs to, and that it reuses the old cells when it tries to display something new (by using a reuse identifier). However, each cell will contain a scroll view with content size and subviews that will change in each cell. I want to use a reuse identifier to ensure maximum performance.
Can anyone point me in a way in which I can set up the reuse of a cell like this, and change the contents of each scroll view successfully?
Thanks.
you can make the reuseIdentifier dynamic
e.g. "cell_with_1","cell_with_2","cell_with_x" where x is the number of images
that way equal cells can be reused when sensible (e.g. when the number of images in the view is the same): 'worst case' is no reusing and a tad overhead for trying but in general I'd deem it beneficial :)
*the allocation deallocation and the basic adding of the subviews is expensive.. changing frames or images seems reasonable to me