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
Related
What I'm trying to achieve is basically a Instagram profile type screen.
I'm trying to recreate the segmented control section and what's beneath.
I thought about putting a container view containing the segmented control and a scroll view that switches between 3-4 views.
I saw many ways of implementing this, with or without a scroll view (the one I'm not really a fan of is the .ishidden method).
My main concern is memory. I don't know if it's better to keep them in memory or load them from scratch and also how to do that. Can you point me in the right direction ?
The instagram app doesn't do exactly what you described-- it looks like the only the first two options within the segmented control swap out the view underneath. The last two navigate you to another view
You definitely want to load your views, assign them to strong properties, and then swap them out.
Add a Custom View in Interface Builder, that will be your container, and then connect it to an IBOutlet in your controller. You can instantiate your scroll views when the controller is instantiated, and then you can then add the scroll view as a subview to the container. Then when the segmented control is pressed, you can remove that subview, and replace it with the new subview selected.
Instagram would arguably have some of the largest views, as far as memory allocation is concerned, to swap out (several images). Yet you can tell that the scroll views are stored in memory because you can switch between them without reloading the images
(I have read other questions and answers on this topic, but most are very old and do not relate to iOS 9 or 10.)
The app design calls for the top half of the display to always contain the same content. (An image being edited by the user.)
The bottom half of the display needs a UITableView. When a UITableViewCell is tapped, the bottom section needs to transition to a new UIViewController with slide-on animation, similar to how UINavigationController push segues work.
Problem: only the bottom view needs to transition to the new view controller(s), and back again. The upper half of the view hierarchy needs to remain unaffected. For this reason, I can't place everything inside a UINavigationController, and I can't have a UINavigationBar at the top of the screen.
Question: what approach should I take in such a situation, where I need only one UIView hierarchy to transition in push-segue fashion, but not anything else? Thanks.
Edited with Solution
Solution follows, for those following along at home.
Yes, you can actually use a UINavigationController for the bottom half.
If you are using Storyboards, the easiest way to do this is to use a container view for each part of the screen which you then can embed a UIViewController in for the top part and a UINavigationController in for the bottom part. If you are doing this programmatically, just add the view controllers as child view controllers to your app's initial view controller (see this answer for more info) which is essentially what the Storyboard will do for you automatically when using a container view.
As a child view controller, the UINavigationController will act independently from the top UIViewController and should behave as expected.
I recommend the programatic approach for the following reasons:
It helps you understand the inner workings of child/parent view controllers much better which will likely save you a significant amount of debugging time down the line.
It makes adding/removing/swapping child view controllers as simple as a few lines of code. Trying to do this with Storyboards is notoriously hacky and cumbersome.
It's much easier to keep track of changes using GIT (most mid-size/larger companies actually prohibit Storyboards for this very reason)
If you want change in part of the screen you can use container view. For details refer Swift - How to link two view controllers into one container view and switch between them using segmented control?
You can use multiple view in one view controller and can give animation like push or pop to show or hide it.
Second approach is you can use Container View which will give exact effect like navigation stack.
I am creating a simple little popup view, similar to the popup that appears when you push the volume buttons. I would like to display an instance of that popup view in different view controllers. I have been pondering a couple approaches, but I would like to know what is the best approach, taking into account MVC, complexity, and otherwise 'good' practices.
Currently, I am creating and displaying this UIView from within my UIViewController. I justified that approach since it's really a small view and I do a lot of work with it to modify its behavior in that VC, so that code was already going to be in the VC. Essentially, I make a frame, set the background, apply corner radius, add text to it, apply motion effects, then make it fade in then later fade out. I could copy and paste the code into my other VCs but that's obviously a bad approach.
I could create a subclass of UIView and I'm sure I could use drawRect to draw it, but I'm not sure exactly how to add that view to the VC exactly in the middle, unless I drag out a view to my VCs and change its class. But if I do that I can do most everything in Interface Builder anyways, which would be preferred especially if I can use Auto Layout to always keep it centered. But, I'd need to copy and paste that UIView into each VC and hide it - that doesn't sound good.
I could create a subclass of UIView and instead of drawing with drawRect, implement a method that creates the UIView and returns it. Then in the VCs I just call that method and add the view it returns as a subview. I've never done this, and I'm not sure if that's an appropriate approach.
What is a plausible approach to implementing such a view that can be thrown on screen from any of my VCs? Thanks!
Note that this view should always be the same size, in the center of the screen, not tied to any specific VC. It should remain on screen unaffected by transitions and such. It closely mimics the Volume popup.
I would like to display that same popup in multiple view controllers.
I expect that you mean you'd like to have separate instances of that same class in multiple view controllers. A given view can have only one superview, so it can't exist in more than one view at a time.
I'm not sure exactly how to add that view to the VC exactly in the middle
It's easy to center a view in its superview. To center horizontally, subtract the width of the view from the width of the parent. Divide the result by 2. That's your X coordinate. Same goes for the Y coordinate, except that you'd obviously use the heights.
An even easier method is to create a point by dividing the superview's width and height each by 2. Set your view's center property to that point.
What is a plausible approach to implementing such a view that can be thrown on screen from any of my VCs?
Don't try to reuse the same view. There's no need for that, and trying to pass it around between controllers will really complicate your code. Just have any controller that needs to display your popup create its own copy.
Remember, views are the interface to the data that's stored in your model -- they can display that data or let you interact with the model, but they shouldn't store app state themselves. Given that, there's no reason that you'd need to use the very same view in more than one view controller. As long as your pop up gets its data from the right place, you can have as many instances of it as you like.
If your popup really is separate from the content of any of your view controllers, another possible strategy is to use view controller containment. You can create one view controller that handles just the "app-wide" stuff, like this popup, and have it load and unload the various other view controllers as it's children. I'd caution against trying this, though -- it's probably more complicated than you need and surely more complicated than you should attempt right now given that you seem to still be getting your sea legs.
It sounds like MBProgressHUD is what you're looking for. FFCircularProgressView might also help.
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.
I am trying to have the ability to switch views in and out. The screens are generated on the fly and there may be anywhere from 30-100 of them that will be presented sequentially. A NavigationController may work, but I may be creating a hundred or so screens so I am worried it will run out of memory if I push that many views. Maybe this could work if I only ever added one screen at a time to the NavigationController, and when a new one is added remove all screens and then add the new one. But this may cause strange animations.
I tried creating a custom View Switcher that could load each of the views on the fly following the chapter 6 example in the apress book. The problem is that on rotations the events do not make it to the View Controller for the currently visible view. So it ends up doing weird things on screen rotations.
Another approach that I am thinking may work is to use a tab bar controller and make the tabs invisible. Then I can just use tabs 1 and 2 to hold the current view, and the last view and ping pong back and forth. Then memory is not as much of an issue as using a NavigationController.
Does anyone have any other ideas? I feel like there should be an easier way to do this that I am just not seeing.
How about creating a singleton "ScreenManager" that loads, adds and removes your views on your root view controller? This way you can make sure that the view hierarchy isn't convoluted and out of your control. It's also a good idea design-wise and should be very easy and efficient with memory management.