I'm new to iOS development but have used MVC frameworks on other platforms. In ready through the getting started documents about view controllers, it seems that there are several approaches in it's use.
I'm building an app that will have numerous pages / scenes. In using the storyboard, I'm creating a scene for each screen e.g. sign up, log in, home, and feeds to name a few. My question is should a separate view controller be created for each screen e.g. signupcontroller.swift, logincontroler.swift etc.? I started with the single screen project in XCode and have not been able to locate the automated way to create a new view controller for each scene. Is this indeed a manual effort, or is there a better starter projet type for a robust app such as this one?
Thanks much for your help and guidance.
You generally have a separate view controller class for each "scene," although it is often the case that several scenes will share a view controller with different data associated with them. Once you make the scene in the storyboard, you create a new UIViewController class and then associate it with a view controller in the storyboard...
Add a new Cocoa Touch class to the project
Name the view controller
Associate the view controller in the storyboard with the new class you created.
Related
I am fairly new to swift and iOS programming, and I've been watching video tutorials of people making things visible and not visible. When it comes to large scale projects I am start to doubt that they have one million features toggling between visible and not visible on the tiny screen.
So my question is, is I am making a tiny app how do I transition from basic view such as logging into a game and changing the login view to actually ingame. How do these type of things work?
What you're asking is the basics of programming on Apple platforms. This can't be simply explained in a single answer. Please, start reading this tutorial from Apple to get the understanding of the MVC concept and storyboards.
In short. You use the storyboard in Xcode to build your screens. Each screen is a scene in your program and represents a view controller. The view controller organizes how data is displayed on a screen and how to react to user input. You can create view controllers in code in Xcode and link these to the scenes (that are also view controllers) in the storyboard. In the code you can program the behavior of the different views that you put in each scene. Moving from onze scene to another is done with segues.
A segue can be made programmatically, you drag iT from onze view controller to the other. Or, in the storyboard boy dragging it from, e.g., from a button to the next view controller. You give the segue na identificeren and in prepare for segue (a method) you can program what data needs to be transferred from the existing to the destination view controller.
I am following an iOS Swift tutorial to build an app. The instructor suggested that I delete the ViewController.swift file and add a new Cocoa Touch Class template which would be a subclass of UIViewController but did not explain why. Can someone enlighten me on the reasoning behind this and its benefits oppose to building the app in the original ViewController.swift file?
Is it just a customization method to naming your files?
The ViewController.swift file is created by default with the Single Application project template. An iOS project can have a lot ViewControllers.
View controllers are the foundation of your app’s internal structure. Every app has at least one view controller, and most apps have several. Each view controller manages a portion of your app’s user interface as well as the interactions between that interface and the underlying data. View controllers also facilitate transitions between different parts of your user interface.
For more information you can check Apple documentation: The Role of View Controllers
I'm just getting back into iOS development after a year or so away and am looking for a way to have a single view above or below a UITabViewController view. The idea is to have one ad view that is used throughout the app instead of one on each tab. The constant reinitializing of the ad view seems like it would be a lot of overhead so having one persist throughout would seem to be more effective.
I've searched for this but not found much of anything so even a useful link would be appreciated.
Thanks in advance,
Jason
I see several approaches here:
Since you are setting up your view hierarchy in your application's delegate, I'd suggest creating a separate UIViewController and managing it from your app delegate. That way you can show/hide it in the main UIWindow, without having to do much work.
You can subclass UITabBarController and show the ad in the visible view controller. This is more work, but your app architecture is arguably cleaner, because your app delegate doesn't get cluttered with ad-related code.
Another option is to look into a UIViewController category, where you can manage add related code. Not necessarily the cleanest, but it keeps the ads out of both your app delegate, and your tab bar controller. (You'd add the ad view as a category property via runtime level calls and associate objects, but that gets messy.)
I'd probably go with the first approach if it were me, but I could argue for either of the other two approaches, since an ad view doesn't really necessitate it's own view controller.
How about create a parent view controller and each view controller inherits from that parent view controller? Parent view controller has a ad view or table view, so every child view controller will has those two view as well.
Okay, after spending some time trying to create and manage a customer view controller for this I stumbled on the Container View Controller capability Apple added in iOS 5. I have no need to support iOS 4 or earlier so this works good for me. There's a good description of it here (unfortunately the author never wrote part 2 with a tutorial):
Container View Controller description
And a decent tutorial is available here:
Container View Controller tutorial
Between the two of these I was able to create a good setup with an AdViewController and BodyViewController (TabBarController) contained in a Container View Controller. This gives me all the capabilities I need (at least so far).
I'm still relatively unfamiliar with all the new features of iOS 5, and what I can do in Xcode now. So, a good explanation would be appreciated.
I'm designed a single-view application and I have both an iPhone and iPad storyboard. I chose 'Single View Application' when I first started, so Xcode created a ViewController for me. Both storyboards list this view controller as their own.
Back in iOS 4 the way that I linked button actions to my view controller was to Right-Click on the button on the nib, pick the action that I wanted, then drag it over into the view controller's '.h' file, which auto-created a method/property for me.
I am confused about how to accomplish this now, since I have multiple storyboards but only one view controller. Do I need to have multiple links for each button; one for the button on the iPhone and one for the iPad? Or is there a better way to accomplish what I am trying to do now?
You do it the same way you did it in iOS4. But obviously you never built an universal app there ;-)
It's totally okay to have a single UIViewController class for two different nib files.
And if you use storyboards it's fine to use different storyboards and a single viewController too.
You can even use the same viewController for different scenes inside a single storyboard.
The connections to the viewController are saved in the nib or storyboard. So you can't overwrite them while designing the other user interface.
Open the iPhone storyboard, make your connections to actions and outlets. Then open the iPad storyboard and make totally independent connections.
In response to the first reply, I was under the impression that a view controller could only support two scenes in a storyboard layout. I say that because I found this thread.
(I don't know if this is something specific or different with Xcode 4.2.)
I create my views / controllers programmatically and don't use interface builder or nibs etc. Can someone tell me what the difference is between creating a project that is an "empty" application versus a "single view" application? The former has just the app delegate, and the latter has a delegate and controller provided, but I was wondering if there was any difference I should be concerned with.
I typically aim to have my main/root controller create a root empty view on which I attach and detach views as I add/remove screens. My hunch is that I may as well go with the single view project but am wondering if there is any clutter that this project has that I should avoid by just making an empty project.
By the way, I use this empty root view because (if I recall correctly), there were some strange auto-rotation issues related with swapping out the root view (versus having a steady root view that simply swaps out its subview). If this is a waste of time, I'd appreciate that being clarified as well.
You are right in stating that the single view application template provides a pre built View controller (XIB, .h and .m files) for you to work on. And that is the only additional component that is added to the project.