I'd really like to do something similar to Tinder's "pile of cards" interface, but with a UICollectionView.
I would assume that if you need the other cells to dynamically move given the cell you are interacting with, one would be in Edit Mode on a UICollectionView, but I'm not sure.
Please don't reply with specific Cocoapods that do this and "why don't I just use those?"; it goes beyond just that. I have all sorts of content, and this is just one of the layouts / presentation types I need. Sometimes it's a grid. A lot of the controller actions are the same; just the display and interaction is different.
That said, please DO refer me to any code that may already do this, that I could use as a starting point.
Otherwise, I would be grateful to know where I would get started. I'm thinking maybe one of those projects that re-creates Springboard with a collection view??
EDIT: I was looking for something like a card stack, but not like Tinder in that you can interact with the top card before swiping or letting it return. In the end what I was trying to accomplish was similar to the old iPod-style 'Cover Flow' view.
I'll try to answer my own post. I made a few incorrect assumptions. In the end it was a lot less complex than I thought.
To get a collection view whose layout isn't just 'static within a scrollview' but changes dynamically with the contentOffset property, you need to subclass UICollectionViewLayout and make sure first of all you return YES for - (BOOL)shouldInvalidateLayoutForBoundsChange:(CGRect)newBounds
from there, most of your heavy lifting will be done in the - (void)prepareLayout method.
I basically used the following tutorial as a starting point and kind of followed what they were trying to do (or just downloaded the final project and saw how they did it, and mimicked the same effect), but obviously had a different prepareLayout method:
Ray Wenderlich
Related
Thinking it over, this feels like a bit of a noob MVC question, but I can't come up with or find a definitive answer so I feel I should ask and get some clarity for myself.
I have a custom view that I created using a xib. It is going to be used in, currently, 4 other places in my app. Each usage has identical functionality, so I'm basically just creating a custom control object that I can reuse multiple times.
My "control object" consists of a UITextField, and two UIButtons.
The functionality I'm looking at implementing is, the first button will bring up a UIPicker and the 2nd button is essentially a done button and will just resignFirstResponder on the UITextField. As previously mentioned, this is consistent everywhere this will be used.
What I'm curious about is, is it ok for me to build this functionality directly into the custom UIView subclass since it is consistent behaviour for all instances of my control object? Or, do I need to create a custom UIViewController subclass to go along with it?
Currently, in my main UIViewController for my app I am creating instances of my custom UIView "control object" and treating them the same as any other control object. If I should actually be creating a custom UIViewController class to go along with it, well, I'll have more questions for another thread as to how I should be doing that (unless someone can direct me to a resource on this)
So far, searching the web has yielded nothing for me and from everything I've seen so far with iOS development in general, I've gotten the vibe that UIViewControllers are really only ever for a main, presentable view (that takes up the entire screen.. I might be missing some terminology for this).
My gut feeling is that no view controller is necessary in the scenario I'm describing, but I'd like to try to get some sort of confirmation, if possible.
There is no silver bullet, so no approach is absolutely right or absolutely wrong. What you describe here is just a view that changes its states. So putting everything in your UIView subclass is completely OK. It also conforms to the KISS principle.
However, as far as I understand, and correct me if I'm wrong, the input of your custom view - the text and the picked value from the picker does not really affects the view itself, but the viewController it's attached to. So you need to pass that input to the hosting viewController. This can be achieved by protocol with a default implementation. So the handling of the input data is written only once, but can be attached to whatever viewController you want.
Based off of everything that you've said, I see no need for another view controller. I can see where the answer could be a little unclear considering that the actions are something that ViewControllers usually handle, but I think you'll be just fine letting your custom view handle this by itself.
If you add more functionality or more complex operations, then perhaps it is time to explore other options but for now I think the single view will be fine.
Is what I'm trying to accomplish here even possible? I've been searching for hours for sample code and/or SO answers that demonstrate this simply enough to follow, but so far no luck.
Goal: implement something that looks roughly like this mock:
Yes, I know this is easy with a tableview, but the full design includes custom interactions, multiple columns, UIKit dynamics, and custom animations when adding/deleting cells, so UICollectionView is the better candidate. Until I can get this core layout to work, though, the rest of it is just a pipe dream.
So far I've started with a subclass of UICollectionViewCell that has a single label with constraints to all 4 sides of the content view. At which point I run into these issues:
It's unclear how I can calculate collectionViewContentSize() when the cells don't exist yet, esp. given that the majority of cells are actually offscreen most of the time!
If I just throw in an arbitrary content size (e.g., 320x1000), my views show up, but their heights don't adjust to the label content…I can't seem to read the cell height from within my UICollectionViewLayout subclass.
Seen or done anything like this? I'd include code, but after hours of futzing with it. I'm just looking for a clearer tutorial or sample code that fits this scenario.
There's a project you might want to look at. It's fairly involved and probably has a lot of code for situations that don't quite match yours, but does indeed create a chat view using a UICollectionView.
It can be found here:
https://github.com/jessesquires/JSQMessagesViewController
For item 1 - with regards to calculating collectionViewContentSize, I think you'll find you may not need to calculate that, at least as long as you're using a UICollectionViewFlowLayout subclass for the layout.
And for item 2 - rather than set a fixed 320x1000 take a look at the JSQMessagesCollectionViewFlowLayout.m for sizeItemAtIndexPath.
Sorry, this probably should have been a comment, but I lack the reputation to comment & so I made it an answer (doesn't that seem backwards? Ah well.)
Im trying to do app with a card based ui, kind of like Jelly. I was wondering the how this would be done. Im thinking by using a collection view but Im not sure. Are there any open source libraries that would make it easier to do this? Thanks.
You're probably not going to be able to accomplish this using out-of-the-box components. I don't think UICollectionView is going to get you very far. You will almost certainly need to roll your own.
I would start by creating a View Controller class for the "cards", instantiate a few of them, add the views as subviews to the main view, and get to the point where you can comfortably push these cards around with your fingers. You will want to read up on animating UIViews, and UIGestureRecognizers. Make sure the momentum is right. Apps like this really really demand highly-tuned physics, otherwise they'll feel awkward.
Once you get to the point where your cards are happily zipping around the screen, it's just a matter of getting them to "sink" into a couple pre-defined positions (focused front-and-center, and resting in a stack down below). You would probably also want to give your view controllers some sort of state that indicates whether they're "active", or not.
Easier said than done, obviously.
I developed a custom UICollectionViewLayout to handle some advanced layout requirements on a clients application what seems to work really well.. Until I start trying to use animations.
I took some time out of work to document and make it a bit more flexible so it can be found here: https://github.com/liamnichols/LNCollectionViewPagedLayout.
Its purpose is to page the content onto new pages if it will not fit on the previous page to ensure that the content does not get cut across two pages and it seems to handle this OK.
I noticed from the start that there where animation issues with it however I never needed to use animations originally so didn't attempt to investigate/fix although now its become a requirement that a UICollectionViewCell can expand revealing some more content and when I attempt to use any form of animation methods (reloadRowsAtIndexPaths:, performBatchUpdates:completion: ect) I always get very strange behaviour ranging from crashes (view argument is nil) to messed up layouts.
Currently my layout works by creating a dictionary of UICollectionViewLayoutAttributes on prepareLayout by asking the delegate for the size of each cell then running some logic to see if it will fit or not and so on...
When the layoutAttributesForElementsInRect: method is called, it can then simply query the dictionary and fetch an array of attributes that are relevant for that rect.
First off, is that the best way to go about creating this layout? I found it very hard to find documentation on creating custom layouts to meet my needs and ended up looking at other open source libraries for pointers on what to do.
Secondly, I haven't implemented the initial/final layout attribute methods as I cannot figure out how to correctly use them. Is this the reason I'm having issues or are these optional?
Any help or pointers to correctly creating UICollectionViewLayouts would be great.
For issues with expanding cells (or just cells changing size in general), this answer may be helpful. The short answer is that the default implementation of initialLayoutAttributesForAppearingItemAtIndexPath: (and, in general, all of the initial/final layout attribute methods) doesn't always return the correct frame and you've got to override this method and fix the errors.
Debugging these types of issues is fairly straightforward. Start by logging the attributes being returned with something like this
- (UICollectionViewLayoutAttributes *)initialLayoutAttributesForAppearingItemAtIndexPath:(NSIndexPath *)itemIndexPath {
UICollectionViewLayoutAttributes *attributes = [super initialLayoutAttributesForAppearingItemAtIndexPath:itemIndexPath];
NSLog(#"indexPath=%#, attributes=%#", itemIndexPath, attributes);
return attributes;
}
and determine when the frames are incorrect. From there you can come up with an approach to correct the errors. Thats about as detailed as I can get without knowing more specifics.
I am new to iOS development, and I have been doing a fair amount of research. Unfortunately, as the title of my post suggests, neither possibility seems exactly suited to my needs.
I need a lot of customization with respect to the look and feel of each individual table view cell, and I need for my table to have header sections which are clickable. I would actually like for the section headers to have the drill down quality and not the cells beneath each section header.
To my knowledge, the problem with PFTableViewController is that it doesn't easily allow for multiple sections (even less so if I need for these section headers to be clickable and of a different look and feel from the regular cells.) Furthermore, customizing the PFTableViewCells doesn't seem terribly simple either.
However, if I use the regular UITableView even with Parse as my backend, won't I run into some difficulties with respect to loading, pagination, etc...?
I have a pretty good idea of how I would implement this app with regular UITableViews so I guess here is my question: is it worth it for me to try and figure out all of this PFTableViewController stuff?
I should also mention the fact that my table view controller will not take up the entire view but only half of the screen.
Thanks in advance for any and all advice
It seems that a normal UITableView will suit your needs. If you want to customize the look and feel of individual cells, you can just subclass a UITableViewCell and modify it.
In terms of your needs with the headers, it's hard to say without knowing more about your app, but you want to follow standard user interface conventions. Users don't expect headers to be clickable. Instead, they attempt to traverse information hierarchies by selecting table view cells, which then bring them to new views with more information. Based on your, needs I think that a standard table view controller with some customization is what you want.