I have a view controller with multiple UIViews on it, made in two different ways, all sitting in a scrollview. The top one was added through storyboard, and was done so to make it easier to style and work with segues. The others are more of a newsfeed post type deal, and are dynamic, so they are programmatically added. When I travel to another ViewController from this one, and I'm not scrolled all the way to the top I find that when I return, my storyboard added view is moved up, and almost out of the screen.
How do I fix this? I feel like it has something to do with the scrollView or the fact that it was added in storyboard, since the other views dont move, just this one.
Related
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
When a view controller (VC) has hordes of views and subviews it becomes very difficult to modify a subview because I can't even see it completely (it is hidden behind some other subview). For example please have a look at current state of one of my VC:
I can't see highlighted "Congratulations - UILabel" or its UIView.
Is there a way I can see a specific view clearly (may be at the top of all the other views)?
Generally I drag drop a UIView on a different dummy blank VC, design view completely on that VC with all constraints and finally drag drop it back to my actual VC. This works most of the times but it seems like an inefficient approach to me.
I've observed that seeing overlapping views used to be easier in iOS6 but it is Very difficult in iOS7. Is there any feature in iOS7 Interface Builder that I am missing? Thanks for your precious time.
Update: Would Spark Inspector help me here? I am newbie to development so don't want to waste my time trying and understanding new plugin if it doesn't help me achieve what I want. Thanks.
This is widely considered one of the weak points of Xcode's new Storyboards feature. They're great for apps that require a large number of simple controllers, but they become difficult to work with when your interfaces get complicated. Most experienced developers use Storyboards in some places and individual controller XIBs in others, depending on what they're building.
Here's how to solve your problem:
Step 1. Break the View Controller out of your Storyboard into it's own XIB
From the File menu, choose New File and choose an Empty XIB file (from the User Interface section). Name it "YourExactVCClassName.xib".
Go to your Storyboard. Copy the entire View of your View Controller and then delete it.
Paste the View Controller into your new XIB. Change the class of "File's Owner" to be your View Controller, and set it's "view" property by drawing an outlet from the view to File's Owner.
When your app runs, it will try to instantiate the view controller
from your storyboard. When it realizes there's no view in the
storyboard for that controller, it will automatically find the file
MyViewController.xib and load it from there.
Step 2. Organize the contents of your main view into detached views that make sense.
In your example above, it looks like you have different views for different states of the game (game over, high score, etc.) Take each of those and remove them from the main view. With your controller in it's own XIB file, you can just drag the view out in to the whitespace around your controller. Each view you drag out becomes a top level object in the XIB file that you can design and see easily.
You're no longer stuck with an iPhone-5-sized workspace.
Create IBOutlets for each of your detached, top level views so you can reference them in your controller.
In viewDidLoad, programmatically add each of the separate views to your main view. Note that you may want to set their frames, make some of them invisible, etc. You have to write more code, but it's generally worth it for an easily maintainable XIB.
I'm fairly new to iOS development and I want to make something like the attached screenshot.
I've read the nested UINavigationControllers is not a good idea, if not impossible, so I'm more than willing to accept ideas on how to implement what I want.
On my second screen there are two views I want to switch back and forth between (NOT using gestures and push animated), while maintaining a static header and footer.
The only way I know how to do a push segue is with a UINavigationController, hence why I see the need for nested ones.
How do I implement this? I thought that in my second UIViewController I could programmatically create a UINavigationController and add it to self.view, but I ended up doing this:
self.subNavigationController = [UINavigationController alloc] initWithRootViewController:[someVC alloc] init]];
[self.view addSubview: self.subNavigationController.view]
But that only adds the view of self.subNavigationController to self.view, not self.subNavigationController itself.
Like I said, I could easily be way off base on how I should be handling it, any advice is appreciated.
OK, if I've got this right then what you want is an app where you can navigate between different views (like any other app).
This will use a UINavigationController (lets call this "nav1") and this is the bit that you're OK with.
However, you also want a view that will have a static navigation bar. i.e. as far as nav1 is concerned this is only a single part of the navigation through the app. It also wants to have two potential views in there. (the map and the table view) and it will have a static bar along the bottom too (in IB this is a ToolBar I think). Lets call this the "mapAndTableViewController".
You haven't said exactly how this works but you don't want swipe gestures between them. So I'm guessing you will have a button or something to swap between them?
Something like this...
http://www.youtube.com/watch?v=eg6vWGh67zk&feature=youtube_gdata_player
The way I've done this is to use a single view controller with a scroll view. On the scrollview set scrolling disabled and set paging enabled. This sounds odd but this removes the touch scrolling from the scrollview while still allowing code access.
Now, in the mapAndTableViewController you populate the left and the right hand side of the scroll view.
What you do here is now take the two view controllers... mapViewController and yourTableViewController and instantiate them. Then add the views of these controllers in to the scrollview left and right sides accordingly.
Essentially you will have THREE view controllers. One for the scroll view, one for the map view and one for the table view.
Without any further explanation from you I can't really help beyond this as I don't fully understand what it is you're trying to achieve.
Hope this helps...
I apologize in advance for not being able to efficiently describe my problem statement. But, I shall include a link to an image to better describe what I'm looking for. Basically I have a Viewcontroller with a TableView inside it and I have a toolbar on top with three bar button items on it. Now what, I want is to be able to have a functionality whereby the user taps on any of these buttons and we go to different views. Now, I would like a design where if possible I stay on the same screen and render the information in the tableview below depending on which button has been pressed. Visually, I'm trying to go for an effect where the button that is pressed is shown as being depressed and information is rendered and on pressing a different button a different view is rendered. I'm familiar with attaching different view controllers to all the buttons and then segueing into those viewers. However, I would like to know if there's a way in which I can stay on the same view controller and just use sub views. If there is, how can I do this from storyboards? Again,, I apologize for being verbose, my picture should hopefully be able to tell you what I'm trying to do.
The link to what I'm trying to achieve: http://imgur.com/GM5eH
Well, one basic solution is simply to add these other views in your controller. Now that subview is set to hidden on viewDidLoad:. Then just create an action, and show the subView. You can size that view however you want, and play around with the other view as well.
Now, there might be a better way to do this, but that is how I would do it.
EDIT - Concerning Apple's method on Calender
Now, I have never tried anything like this, so this is all theory.
First, you create three classes. Each with it's own custom view. This view should be the size you need it on the other (Main View). You can set the size to freeform in the Interface Builder.
Once you have that done, you head to your main view. That view will have the three buttons. Set an IBAction for each of those that creates an instance of each view and places it on the screen. (I am not sure how to accomplish this, but I am sure there is a way. Take a look here: Objective-c Adding subViews in my controller
You should dealloc each view after you head to another view as well for memory management.
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