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.
Related
I am making modifications to an existing iPad application, and I'm having a hard time dealing with really messy scenes in storyboards. Almost every scene in the app consists of multiple views laid one on top of the other, each containing a different set of controls. Depending on the situation or data coming into the scene, some views are hidden, and others are shown.
It takes a LOT of time to decipher such scenes, and even when I figure out what changes I need to make it's terribly difficult to make those changes, and easy to screw up other things.
As an example, the following scene has 3 views that could appear (Start View, End View, Drawer History), depending on the situation, and they are all laid out on top of each other...
This seems like a terrible way to handle this, and I'm having a hard time believing this is standard practice, but I'm not finding much in the way of alternatives. I find very little in the way of questions where people are dealing with this problem, and the tutorials on how to design user interfaces seem to be too simplistic and never deal with scenes that are complex enough to run into this problem.
Unfortunately, this app is my primary introduction to doing user interfaces in iOS, so it has apparently become the default solution in my head. I've tried many tutorials, but they take a long time and don't seem to ever get to a situation that needs such a technique to solve it.
I would hope there would be a solution where each alternate view in the scene could be laid out on its own, and be made to appear within a placeholder view as needed.
What would be a more enlightened / more manageable approach?
That's what you'll get with Storyboards/Nibs/Xibs. I'm not saying coding your UI is better than using interface builder, but it is, at least for me. I believe, as far as I know, there's no other way to handle such multiple layers of views in one view controller in interface builder. I actually used to use interface builder before and that's how I add multiple layers of controls too. Sometimes some views are initially made hidden, but that would probably confused me or the other developer looking at the layout. Sometimes I extend the viewcontroller height to know that there's a view container with a constraint a thousand constant or a negative thousand constant to make it hidden and ready to animate when it's needed to be shown.
There are ways to somehow improve and organize your Storyboards. You can separate modules into different storyboard files; you can use references; avoid segues; and whatnot. It's still an individual or team's preferences.
Some ref:
https://cocoacasts.com/organizing-storyboards-with-storyboard-references
https://medium.com/#stasost/xcode-a-better-way-to-deal-with-storyboards-8b6a8b504c06
EDIT:
I'm thinking you could also layout separate view containers into a separate xibs, and then call them or layout them when needed. But that would add more files to your project.
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
EDIT:
Imagine that I'm in the business of reimplementing CoreText.
I'd get an NSString here which is an ordered list of code-points, and a set of glyphs there (an NSFont/CTFont) that basically is a list of CGPathRef.
Something in-between is in charge of the layout.
And some kind of environment must provide a CGGraphicContext to render into.
The kind of objects I have to display are CGPath. I am worried of creating one UIView for each CGPath! For a block of text, you wouldn't create an UIView for each character-glyph, would you?
I have a potentially large set of (tiny) objects to draw at once. In the 1000's. Many will be offscreen until scrolled into view.
One one hand it looks like my best bet would be to create one UIView for each one. The reasons are that:
with proper tiling I can make sure that the views that are offscreen
are not even in memory most of the time and brought up to life when
required
more importantly, when zooming I want to set each such view's layer contentScale to the zoomFactor such that I still get the full
precision and not the blurry stair-case
On the other hand I have no idea how the (otherwise perfectly generic) parent view will behave with 1000's of children.
So I am tempted to rethink my code such that the "children" just become an area of the single view.
But then I start thinking of setting that view's layer contentScale and I'm worried about exhausting memory just while zooming: I do not know if the layer machinery is "clever" enough not to create a huge backing bitmap when most of its contents would be invisible anyway
What to do, oh what to do?
Anyone has any experience they want to share?
I recently saw a presentation on a game involving hundreds of sprites implemented as UIViews, mostly image views. Performance was excellent on both an older and recent generation iPad. His code is available at https://github.com/bentford/ButtonWars/ , so you may want to test it to see if the performance meets your needs.
There is often an assumption that views are heavyweight, but experience doesn't bear that out.
If most of the objects will not be on the screen at any time, it's probably better not to create views for all of those off-screen objects. You need to intelligently add views for just those objects that are visible, and remove them from the view hierarchy when they go off-screen. You might be able to use UICollectionView to make this easy - it is very well designed, efficient, flexible, and easy to use and customize - but I don't know if it works with zooming.
If you decide to draw everything in one view, with deep zooming, you should look at CATiledLayer. It is designed for zooming in very deeply. Apple's MKMapView uses it under the covers to support scaling its viewport from Earth-sized down to a (relatively) few square meters.
If you cant use UICollectionView due to iOS version boundations, and you are intrested in re using views in UIScrollView, than have a look at this class. It is used the same way UITableview is used. Just pass in number of views and it will reuse the views.You can go through readme. Its very straightforward.
In my two recent questions here and here I laid out my problem a bit, but I want to ask a more general question here. First my goal: I am trying to animate views side to side with a fixed background image.
I am new to iOS, and so I don't know all the tools that are available to me, but each time I started hacking this together I kept thinking that there must be a built-in way to do this. I didn't want to reinvent the wheel, so what is the common way to implement this?
The best approach I think is making a UIView based in two main views:
The background, that always will stay
And on top of it, another UIView with your animated view
In case you want to animate it, its quite easy, just check this:
iPhone UIView Animation Best Practice
I'm making a role-playing game, and I want to have a Map View and a Battle Screen. With the possibility of other screens as well.
I thought the best way to achieve this was to use multiple NIB files.
When I prototyped this by have one view that creates content, switching to the next view, and then back, the content on the original view was reset.
How do I make it so that the first view doesn't reset the data each time it's loaded?
Your question is a little vague. A view usually does not get "reset" unless you run into a low memory warning. That said, even then it's just up to you to keep the right references and setup your view correctly. Maybe have a read through Apple documentation or provide some code. Adrian also has a good write-up about this.