I'm looking for some ideas what's the best way to implement the following behaviour (and a starting point in code/pseudo-code if possible):
BookViewController with ViewA - contains some UILabels (e.g. information about a book)
MainViewController with ViewB - contains some UI elements and displays ViewA in the middle (one view at a time)
The user should be able to swipe inside ViewB to view different books i.e. I will need to manage a number of ViewA views, create new ones and populate them with new data, and then replace the current instance visible in ViewB. So effectively I'll be changing views in the centre of the screen. What's the easiest and most efficient way to accomplish this functionality? Any suggestions comments are appreciated - thank you.
You just need one view controller. It should control a scroll view with paging enabled at the center and e.g. three book views, one visible and the ones left and right of it. The controller should manage the data displayed in these book views.
Related
My app contains a Table View which is scrolling and taking events properly. But after that I have to show a custom pop up to screen for that I have added a full view over the Table View. But after adding the view over Table View, Table view is still scrolling and taking events.
Please help if anyone have knowledge about that...
Thanks
The best way to achieve this is to add a blur view into your nib file first. This is better approach as the user is made aware of the current enabled object.
Once you add the blur view over the tableView you are showing, add your custom pop-over. This would maintain a clear demarcation between the two views and you would be able to achieve the functionality you want as the touches won't flow to your tableView.
Follow below steps may work:
Add overlay view on screen to show data on top of table view
make TableView Disbaled as soon as u add view on it.
Here is what I'd like to achieve:
1) present a fairly large number of screens (about a dozen) with identical layouts but different info. (Basically a set of info pages for different events - dynamically set)
2) the user should be able to use swipe to move between the pages, and the transitions should be animated
3) I'd prefer to manage all the data from a single view controller.
What would be the optimal way to achieve this? I was thinking of keeping only two views in memory, dynamically updating the content of the currently invisible view when the user swipes, and then animating from one view to the other. Should I use one of the container view controllers?
Thanks!
Sounds like you should look at using a UIPageViewController. It is a parent view controller that manages a group of child view controllers that each display a single page of content.
Each page would be an instance of the same class of content view controller that you create.
A page view controller uses a data source and a delegate much like a table view does.
There is an app in the Xcode docs called PhotoScroller that shows how to set up a page view controller using a swipe gesture to switch pages. It's got a lot more complexity than you need in the view controllers that display photos (those photos are large tiled images and the photo view controllers have a bunch of code you can ignore that manages tiled images.)
I'd probably use a UITableView that has cells large enough to take up the whole screen. That'll handle reusing the views (UITableViewCells) for you and you'll need to disable the tableview scrolling and implement paging when the user swipes.
Apply a rotation translation to the tableview's layer and then apply the inverse rotation translation to each of the cells if you want a horizontally-scrolling tableview.
Alternatively, I believe iCarousel will handle view reuse.
I have seen questions asked about mutliple UITableViews in one view but they all have only one table visible at a time. I am after something different please.
In my head I want four UITableViews visible in one UIScrollView inside one UIView. The four tables will be visible and populated at once. They will have a dynamic number of rows each so the scroll view will allow users to scroll off of the page to see rows that do not fit.
The tables would be two side by side and then below them the next two side by side so that you end up with a 2x2 square.
I can (sort of) wrap my head around how to code this in the controllers etc. but I cannot figure out how to organise the hierarchi. I have tried using the storeboard to layout the tables inside the view but 9 out of 10 attempts to drop controls in fail as I am obviously not fully understanding this.
Do I need to generate the UITableViews in the UIViews implementation file and add them as objects to the UIView? Or can I use the Storyboard?
Could someone please explain how the hierarchi of objects would be structured?
In my head it would be:
UIViewController
-> UiView
---> UIScrollView
------> UITableView
------> UITableView
------> UITableView
------> UITableView
But trying this in Storyboard doesn't work. I assume each UITableView will want its own UITableViewController and what I have read in other posts I would likey need to do this connecting in the UIViewController implementation file.
Any help is appreciated.
I think you might try to drag UITableViewController into your view Controller, at least I don't have that problem to add 4 table view into a scroll view.
here is how i added it
1.> Drag the scroll view control into view controller
Your view controller should look like this:
2.> Drag the table view control into the scroll view, and set the size and position of that table view
Your view controller should look like this:
3.> Then drag all the rest 3 table views onto Scroll view
But i would like to suggest a couple of things in your case
no using that much table view in the same view controller, it's a chaos in your codes to maintain all them. There are always better
options than 4 table view, maybe consider collection view. or even
separate the use flow.
If i were you, i won't use table view inside Scroll view, they are like scroll view inside scroll view, if you don't design the
interaction very very well, they become extremely hard to use.
If you still want to use four table view in the same view controller after all, you want to pay extra attentions on your table view datasource and delegate. very carefully handle all the cases.
Hope that helps you.
Tableviews are very customized scrollviews. I wouldn't put 4 of them on a scrollview, this wouldn't be very intuitive for the user as your finger would scroll the view in many ways depending on where exactly it touches the screen.
Instead, try having your 4 tableviews in a 2x2 pattern directly onto a simple UIView. This can be done inside the Storyboard.
As for filling up and using them, you have 2 ways :
A) Your UIViewController is the delegate and datasource of each of the 4 tableviews. When executing, you perform a switch on the first parameter (the tableview that called you) to determine the appropriate course of action.
B) You create 4 classes that each handle a single tableview, instanciate 4 objects inside your UIViewController and assign the UITableviews' delegate and datasource properties to these objects.
All technicality aside, 4 tableviews in a single screen is pretty crowded. Your design will definitely not fly on a iPhone, so I'm assuming iPad only. Even then, you should make sure that everything is visually appealing and the purpose of each control is clear. It's up to you, but I'd hate to see you work hard on an application only to see your efforts wasted because your visual design doesn't appeal to your users.
If the table views take up the entire region of the scroll view then they wont let any scroll events past to the scroll view that contains them, unless the scroll is horizontal.
For a simple one to one between a table view and a view controller, I would make each table view part of it's own UITableViewController (so you have four), and then make a UIViewController that adds each of the UITableViewControllers to it as a child.
This way you don't have to do any fancy logic around if statements on which tableview is asking for data, because the table view controllers only have one table view.
https://developer.apple.com/library/ios/featuredarticles/ViewControllerPGforiPhoneOS/CreatingCustomContainerViewControllers/CreatingCustomContainerViewControllers.html
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
I'm trying to figure out the best approach to take in my current situation.
I have an app with a navigation bar controller that at one point needs to present/show x number of table views.(x meaning that the number is decided by communicating with a server)... The table views will each represent e.g a class or a group... (this could be school classes or kindergarden classes)
Okay... So... Only one table view should be visible/in focus, but the others should be accessible from the same view...
E.g. The view is presented. A table view for class A is shown. The user can swipe to get class B
I've been considering different approaches, but I can't figure out the best approach to this...
I considered using a scroll view containing the x table views, where only one was visible at a time, and the others could be scrolled in view... But, after doing some research, it seems that Apple recommends that you shouldn't place table views in scroll views, because the scrolling can interfere with each other..
Using a tab bar... Again, my research told me that the navigation bar should be placed in the tab bar, and not the other way around... And I only want a tab bar on this view, and not earlier in the app..
Use a custom tab bar that better supports my "needs"...
Any ideas??
In my opinion the most important thing is that only one UITableView have to be visible. The best solution (ie the simplest) is a first UITableView with its UITableviewController that lists all the classes/categories A,B,.. retrieved from the server, and a secondary UITableView (ie controller /+ tableView) that will display the detailed list for a given class of items. You may also continue to drill down your data tree other sub-tableViews.
I recommend to use a UINavigationController to push/pop your tableViews when a cell is selected.
Stacking several UITableViews in a unique container view seems too much complicated and may lead to tricky and/or unwanted states.