I'm trying to build a view where customers can swipe side to side between potentially thousands of records, so my thought was to use a UIScrollView with 3 view controllers to display the details, so there is always a view controller off screen to the left with the previous record and a view controller to the right with the next record.
What I need help with is the logic to move the view controllers around in the scroll view.
I've seen examples online but they mostly seem buggy, or they allocate 1 view controller for each piece of data they want to display, but obviously I don't want to put thousands of view controllers in memory.
Can anyone point me in the direction of a good solution for this situation?
I appreciate any help...
Check out the documentation for UIPageViewController, which can be initialized to scroll horizontally between its pages. Here's a tutorial if you need help getting started.
Related
So I am trying to set up a UIPageViewController, and I have several UIViewControllers, but I want to set it up so I can animate(translate) a subview of my first view controller into the second view controller as it is transitioning. I have the UIPageViewController transition set to scroll. So that is what makes me believe this should be possible correct me if I am wrong. My google searches came up empty, but perhaps I am searching for the wrong thing.
Please point me in the right direction here in the form of a tut or how to conceptually think about this. My current thought is that I could have two identical views in different controllers, and as the user swipes the first view travels from left to right and then when I know it is at the edge I could have the other view take over perhaps using the prepareForSegue method.
Have a look at the Hero library (https://github.com/lkzhao/Hero) for custom animations between UIViewControllers.
Since a PageViewController doesn't really allow custom animation have a look at the AppleHomePageExample to see a example.
I've been using UIPageViewController with transitionStyle UIPageViewControllerTransitionStyleScroll in order to be able to easily move between views in my app.
I'm looking for a bit more functionality that I won't get from the UIPageViewController so I'm looking to make my own solution - perhaps still a subclass of UIPageViewController.
To explain the extra functionality I'll provide a scenario & a diagram:
In A the app is currently showing the first view controller. I then drag from right to left which will of course start to show the second viewcontroller as shown in B. If I stop panning before the point where the UIPageViewController decides whether or not to show the second view controller or go back to the first one I'd like it to instead show the second viewcontroller (taking up one third of the screen) instead of hiding it completely.
If I was to keep panning a bit further beyond the halfway point and then released I'd like the second view controller to take up two thirds of the screen, while the first view controller takes up one third.
That's essentially it. I'd appreciate any advice on how to go about doing this. I'm thinking I'll subclass UIPageViewController and override the delegate methods, but I'd really appreciate any advice on a better solution.
Many thanks
Maybe this could give you a hint or and inspiration. >>
http://www.raywenderlich.com/78568/create-slide-out-navigation-panel-swift
I'm trying to build an interface that has two horizontally scrolling collection views, but I'm still torn between having two separate view controllers control their respective views or controlling the two views within the main view controller.
People, at least in the past, have said having a controller that controls only a fraction of the screen is not good practice. But I also have a feeling that's only a relic of pre-iOS 5 days.
The thing with controlling two rows of collection view is the data source object, in this case the main view controller, gets very confusing and it's hard to pass on data to subviews of collection views because I have to check which collection view is sending the message and such.
I asked a similar question in the past but the thread got blocked or something. Please don't. I don't see anything wrong with the question and I've been pulling my hair for so long.
Thanks
After a lot of hair pulling and experiments, and reading posts about table views embedded in other table views, it seems that the best way to do it is have one main view controller control all the subviews.
I tried adding collection view controllers as child view controllers, and setting the frame and layout and everything, but they will always end up weird. It does seem Apple doesn't allow for view controllers to control only a small portion (I may be wrong, but based on my experience with UICollectionViewController this is the case).
The problem with identifying which view is which in the data source methods, you can use the tag property.
Here is a screenshot of a view that I have right on my device.
The design issue that I am having here is that the top part of the screen is always going to be static - as far as its placement. The rest of the screen are a row of buttons added to this view programmatically. The arrows represent the idea that you could swipe in 4 directions(from top, from bottom, from left and from right) which would animate a new view onto the screen. This view is the same instance as the view before it. In fact all these views are the same instance but the buttons will be different.( i dont want to get too specific here.)
My design right now calls for pre-loading the views ahead of time. The data for each button for each view will be in core data. I will not know ahead of time how many views there are. One view might just have a view to the right that you can swipe in from the right and that view might have a top and bottom arrow - that would allow you to swipe from bottom or top that would be another view(same UIView subclass). So basically a tree of views.
I guess I am trying to figure out my options. A NavigationController is not really what i want because i have no need for a navigation bar, although in my mind it makes sense that i would have an array of view controllers here each with its view property pointing to each view that is allocated and then as i swipe i would bring in the appropriate view by using the view controller index.(through some animation code)
Another possible option would be UIScrollView but that seems cumbersome and may not be what i would really want.
One of the easiest setups would be to create a XIB file that would consist the top part of the screen and on the bottom an empty UIView that i would programmatically populate with the buttons(and their unique data). The problem that I am havign with this is, is how would i swap the views this way. I guess i could make the rootViewcontroller the first viewcontroller instance with the first view and then swap them.
I guess I am wanting to see if anyone had any questions or suggestions to come up with the easiest(most modular) approach to swiping in different views. Is using an array of view controllers the way to go?
A couple of thoughts:
This screams custom container view controller to me (if iOS 5 and above). See Creating Custom Container View Controllers in the View Controller Programming Guide for iOS.
You talked about using UISwipeGestureRecognizer. You could always contemplate UIPanGestureRecognizer, too. It's nice to have continuous gestures. Think about reading a book where the page swipe tracks your finger, but you can stop and go back, mid gesture. Sure, start with swipe gestures for now, but if your UX lends itself to it, you can always contemplate continuous gestures in the future.
You said that you're planning on "pre-loading the views ahead of time". Generally, given the limited memory capacity of mobile devices, you'd want to be more conservative than that. Maybe load the current view, and the four ones that you're likely to go to in each of the four directions (so that you can present them instantaneously), but leave it at that. Once you go to one of the four possible destinations, then go ahead and release the ones that are not reachable from the current one and tee up the ones that are.
One Xib is enough for you (for this part of your app anyway).
Don't use a UINavigation Controller. The NavController metaphor is one of a stack of cards. You don't have that data structure.
The general idea is one ViewController for one screenful of stuff. If you feel the need for two viewControllers (one for the top part, one for the bottom part) then you are going to have to look at custom container controllers, to ensure that the contained controllers receive their instance methods correctly (viewDidLoad, viewWillAppear, etc). An example container controller managing a pair of viewControllers is the iPad splitViewController. But I don't think you need to do this.
I suggest placing a scrollView on the lower half of the screen and using that to manage your data views. If the upper part of the screen also needs to change (under other conditions) you could even have two scrollViews, one up top, the other below. They can be paged, and contain views that are the exact size of the respective screen portion. They can share their single containing viewController as a common location for their delegate methods.
I can't really help you with more detail, as I don't have a precise enough idea what you want to achieve. Perhaps you should try and implement it one of these ways and come back here with more questions as your ideas become concrete. Start out with the simplest idea (eg scrollView inside a single viewController), only chuck it out when you find you have to break it!
update
following your comments, I do think a scrollView might work for you. I think that managing a stack of view controllers with a custom container controller (as Rob suggests) could get overcomplicated. You will have to create your own custom container controller, the pre-existing ones such as UINavigationController are not appropriate for your data strucure (from what I can gather anyway).
You won't need to manage tons of UIViews, in fact you only need 5 - one for the onscreen portion of the scrollView, one for the screen immediately left and right, and similarly for the immediate one above and below. You can reuse these views as you swipe, much the way that tableViews reuse their cells. The rest of it will be about manipulating your data so the right content is arranged in the views as they come onscreen.
See my answer to this question for some more ideas on this: UICollectionView horizontal continuous loop
There is something that bothers me about this concept of having table view controllers in a page view controller.
Yet, the customer wants separate pages with a table view in each page. It even makes sense in this case. However, I have not come across this before and something bothers me about it.
By the way, each row of a table will take a person to a detail view controller where the data can be edited.
I think if gesture recognizers are used that allow page transitions to happen via tapping or flicking, that could get in the way of the table rows.
I am going to check it out. However, my time is limited and I will have to bail quickly if this does not work out.
Anyone see gotchas on this and I should come up with another approach now? :)
update: Another approach could be a navigation controller containing tableview controllers.
For the basic case, there is no reason a PageViewController cannot contain a TableViewController