I would like to create a small view under my navigation bar where i would display statistics based on the user utilisation of my app and those statistics could evolve in real-time.
I want to be able to "inject" this small view in lot of different views from my app just under the navigation bar.
I don't know how to proceed to create this small view that can use in different bigger views. And how i can interact with this view and others.
I read and tried things concerning xib files, but not sure i'm going in the right direction.
I'm thinking of using containers view but i'm not sure i can be able to "re-use" it in another view.
I'm a bit lost and i would like some guidance on how to make that in the best and flexible way.
Edit: I'have been trying with containers view. Here is what i did for the moment, i don't know if it's the right/best method.
In my two main view controller i got a container who embed the small view container where i'm gonna put my statistics.
Thanks !
I think you're on the right path with containers.
I suggest creating a view controller that has the view you want always displayed and a container view that takes up the rest of the screen space. This is your container view controller.
Each other view that you want to show inside the container area would be managed by a child view controller. This way, the controller with the most-persistent view is the parent of the ones that change.
Related
I want to create a basic version of the slide out menus that apps like Barclays Bank and Facebook use, I don't want to use a pod that has already been created as it adds complexity to the project when new versions etc comes out (have to wait for the developer to update compatibility etc).
So I have the idea to present the menu view under the current on screen view and then slide the current view part way over which will expose the uiview that is under this.
This works fine however I have an issue and just trying to work out the best way around it....
When the top view slides over to expose the underneath view (menu) I also want to pass control to that exposed view so I can interact with it and not the top view?
Any ideas on best way to achieve this?
topViewController.view.userInteractionEnabled = false
Eventually sorted it, had to create a view controller that had a uiview and a container view, with the container view over the uiview. This allowed me to move the view over and still interface with the uiview as I want swapping view controllers on the nav stack.
I've been a Mac programmer since 1993 and find it somewhat hard to get into the iOS frame of mind from time to time.
I've got an iPhone app that was designed for the iPhone 5 screen size and shows 3 different views with different functionalities depending on the orientation of the device (portrait and 2xlandscape).
Now on the iPad I want to separate the landscape screen into a left part controlled by one (existing) view controller and the right part by another (existing) view controller.
As part of trying to support split screen multi-tasking I want to support size classes but my views are in xib files at the moment.. and as far as I know size classes are bound to using storyboards, so I'm migrating to storyboards which seem very ill-structured for my purposes.
I can see that the idea is
1 window = 1 root controller
and
1 screen full = 1 scene = 1 view controller.
But what I need is two (or 3) view controller in a single scene.
I've had a look at UISplitView, which seems perfect only that the left view controller has to be a navigation controller, so not what I need. Perhaps a custom collection view controller is the answer?
I'm sure I'm missing something as I'm very much stuck in a Mac mindset and haven't used storyboards before.. what's the best way of re-using my existing view controllers in this scenario?
Any advice would be very much appreciated.
Take a look at this image:
There is a component in the object library called a container view. You can connect a new view controller via a segue to that container view. Basically, you can create a parent view controller whose sole purpose is to manage/move the views of other view controllers.
The parent view controller can have outlets to container views (which are simple UIView objects) and each container view can be its own view controller.
Hope this make sense, and sends you in the right direction.
So here is the problem I am trying to solve.
In each viewController I am trying to insert ads and the actual control elements. I finished couple of tutorial on raywenderlinch.com to understand that how people professionally put ads in their app. They used UIViews to have two views under mainview of view controller. So I completely understood that one subview hold the ads and another is holding actual app contents. if Ad is loaded take up the screen or else let other view have all available area.
After I came back to xcode I started coding the way I learned there. but when I was dropping UIView on storyboard, I saw containerView, which I think was not present when the tutorial was written.
So I am here to ask about the both approach and their pros and cons.
So basically its UIView vs ContainerView. Which way I should do, and why ?
Any help would be greatly appreciated.
You use UIView when you already have a view and you do not need to have a dedicated view controller to build and handle interactions within it.
From the UIView help page:
UIView object claims a rectangular region of its enclosing superview (its parent in the view hierarchy) and is responsible for all drawing in that region ...
Simplified structure:
YourViewController ---(has)---> UIView
You use UIContainerView when you need to embed another view controller in the one that you already have. The embedded view controller is in charge of returning a view for the region that the UIViewContainer occupies. Therefore, your UIContainerView knows which view controller to use to render UIView inside the region it occupies.
From the UIContainerView help page:
Container View defines a region within a view controller's view subgraph that can include a child view controller.
Simplified structure:
YourViewController ---(has)---> SubViewController ---(has)---> UIView
That SubViewController returns a view and handles its events.
As an alternative answer, you can also consider the use case instead of the technical differences. For example: Why use a container view?
A common use for container views is to reuse (share) a view, directly in the storyboard. Previously, reusing a view required creating a separate "xib" file, and programmatically adding that view when the view controller was loaded.
The above image is from this extremely simple, easy to follow guide that walks you through how to setup a container view that is shared between 2+ view controllers.
A few other thoughts on when to use it:
A navigation bar is part of a UINavigationController, which is a container view controller. So, if you wanted to build a custom alternative, you'd probably use a container view.
A container might help anytime that you want to temporarily show a complex view on top of your current VC but can't/don't want to present another VC modally. This approach still allows you to build that temporary view in interface builder, to setup auto layout constraints for it, etc
I also found a guide explaining that there's a way to switch out different container views based on the situation, allowing your VC to have sub-sections which are very dynamic, yet without having to build those sub-sections programmatically. A picture, from that guide, exhibiting what I'm referring to:
Hopefully this helps people who are trying to figure out when a container view applies to them. If you have other example use cases, please edit/add them or leave them in the comments!
If you see in detail these container view of UIView class type. To get the insights of why we need containerView you should see below portion
In most ways, a container view controller is just like a content view controller. It manages views and content, coordinates with other objects in your app, and responds to events in the responder chain. Before designing a container controller, you should already be familiar with designing content view controllers. The design questions in “Creating Custom Content View Controllers” also apply when creating containers.
for more detail about container view goto link
But before you begin you should have an understanding of
and also you can check this tutorial for how to use container view.
Thus you can go for both the approaches.
Hope this will help you. happy coding :)
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