I have a store application, which I built by reading Big Nerd Ranch's iOS Programming, and I advanced my application to the another level and I have created another Item Detail View Controller. It is similar to iPhone's Settings.app, it is a table view controller. This table view consists 2 static table view cells with UITextField's. There is no problem about accessing this text fields, however I'm not able to save data taken from them. My table view controller has no idea about it's parent view controller (which is also another table view controller). So with basic - (void)viewWillAppear and - (void)viewWillDisappear methods I couldn't succeed save data. Having read some documentation about protocols and delegates, I couldn't help myself. Also I have no storyboards or .xib files. Just .h and .m files, may seem stupid but I hardcoded all of them. Ideas???
Let me show you what application looks like:
Related
I have a view controller in my main page, which includes a tableview;
in the row of the tableview, I have dragged and added a collection view.
In the storyboard I can click drag the delegate and data source of the collection view to the main view controller (easy enough).
However I like to bind these to a custom subclass of UICollectionViewController (to have a self contained MVC for collections) and not reply on the main page's view controller. How can I do this? (associate custom controller class with the collection view?)
Would I have to use a container view controller? What is the right approach for something like this?
I am newbie to iOS and would greatly appreciate any guidance.
You could drag a container view into the row, instead of the collection view. Then drag the collection view into the container's associated view controller scene. Change the class (in InterfaceBuilder's identity inspector tab on right) to be your custom view controller class.
--- end of answer ---
Now with that said, consider embracing more of an MVVM approach than MVC. By this I mean simply to not bother splitting out to separate view controllers for the sake of MVC, but instead to keep all your view controllers simple. Have each own one (or more) ViewModels, where all the business logic lives that's associated with that view controller. Each ViewModel (which is just an NSObject or even a Swift struct if you wish) can be independently unit tested without involving any UI at all. The view controllers just literally wire up the data from the ViewModels to the controls & views, and configures the controls & views while relying on the viewModel for any decision-making. It'll radically improve your architecture for minimal effort. Hope this helps!
I am trying to create an app for iOS using Swift but running into problems with the very basics.
To keep it simple I just want the app to initially be a single view application with a button and some sort of list view on the page. I believe a TableView is what is recommended here. When I click the button, I just want it to populate the list/table view with some entries, that's it. To start with, I don't care if these entries are hard-coded, I just want to get something working.
I have been looking at different samples but I am getting confused. Some of them seem to suggest using a TableViewController others don't. When I use a tableview controller, the UI I had created seems to get completely replaced with just an empty tableview list and the button is gone.
I previously have developed apps in Windows phone and found it a lot easier. I'd just add a listview object and in the click method of button, add the items programmatically etc. But this is my first time trying to create an iOS app and it seems a lot more confusing. There are delegates, controllers, views all seemingly needed in order to do something very simple.
Can anyone give me some basic step by step instructions about how to add a tableview to an application and load some data into it through a button click?
Make sure you are clear about the difference between a view and a view controller.
iOS uses the MVC design pattern (Model View Controller).
A view object displays contents to the user and responds to user interaction.
A model object stores state data.
A controller object drives the app logic and mediates between the model and the view.
A UITableViewController is a special subclass of a UIViewController who's job is to manage a table view. It has some extra support in it that makes it a good choice for managing a table view, BUT... there is one annoying thing about it. It is designed so the ONLY view it can manage is a table view. You can't use a UITableViewController if you want to add buttons, labels, and other UI elements to your screen outside of the table view.
What I usually do is to create a create a table view controller, create a separate regular view controller, add a container view to the regular view controller, and then use an embed segue to embed the table view controller inside the view controller. (you just control-drag from the container view to the table view controller.) That way you get the best of both worlds. You may want to create a protocol that the table view controller would use to communicate with it's parent view controller.
You should be able to find a tutorial online on setting up a table view controller as a child of another view controller using container views and embed segues. It's quite easy.
I am at the beginning of developing an iOS app I am having trouble understanding the MVC (Model-View-Controller) design pattern. I thought I had it down but the more I read the more confused I get. I don't know if this should be an iOS specific question or if the same goes for every use of MVC. I am not using storyboards btw, I want to do it all programmatically.
I believe I understand the basic relationship between Controllers and Models, it's the separation of Views and Controllers that I don't get. Let's say I want to create a UIButton and display it on the screen. Should I initiate the button in the Controller or the View? The controller is responsible for what should be displayed, correct? Wouldn't you just call on a View to display that and not worry about creating the button in the Controller? From what I understand, View Controllers are just Controllers and should therefore control the View, not be the View. It seems like most people do just about everything in the View Controllers. I guess my question boils down to what code goes where?
UIViewController is controller part in the MVC pattern of code.
M(Model)
C(ontroller)
V(View)
Controllers handle navigation between different views , etc.
From here you can get more idea : view and viewcontroller
A view is an object that is drawn to the screen. It may also contain other views (subviews) that are inside it and move with it. Views can get touch events and change their visual state in response. Views are dumb, and do not know about the structure of your application, and are simply told to display themselves in some state.
A view controller is not drawable to the screen directly, it manages a group of view objects. View controllers usually have a single view with many subviews. The view controller manages the state of these views. A view controller is smart, and has knowledge of your application's inner workings. It tells the dumb view objects what to do and how to show themselves.
A view controller is the glue between you overall application and the screen. It controls the views that it owns according to the logic of your application
About View Controllers
View controllers are a vital link between an app’s data and its visual appearance. Whenever an iOS app displays a user interface, the displayed content is managed by a view controller or a group of view controllers coordinating with each other. Therefore, view controllers provide the skeletal framework on which you build your apps.
iOS provides many built-in view controller classes to support standard user interface pieces, such as navigation and tab bars. As part of developing an app, you also implement one or more custom controllers to display the content specific to your app.
Not sure about any iOS specifics but from a PHP standpoint controllers are there to get any data that is needed for the view (via models) and then pass that data to the view.
The view is there to render things to the screen only and should have no logic in it.
So from a website point of view if you wanted to display a users name on the screen:
The controller would request the username from the model
The model would get the username and return it to the controller
The controller would then pass the username to the view
And the view would then render the username.
Hope that helps.
To be not specific, but on a upper layer, you can say as following :
You can put controller code in class extending UIViewControllers
You can put view code in class extending UIView
You can put model code in class extending NSObject
I have a Table View Controller that displays information using JSON. I want to change the styling of my app, and I don't want it to have that "table" view that it has now. Whats the easiest way to change my Table View Controller to a regular View Controller, the biggest problem I have is that the code uses a tableView and I dont know how to get it to work as a regular view controller.
I using a Storyboard with a TableViewController thats linked to a controller called UpcomingReleasesViewController.
I want my app:
To look like this:
My original answer was assuming you just wanted to convert from a UITableViewController to a UIViewController. Looking at your screen snapshots, I infer you really want to switch from a UITableViewController to a UICollectionViewController (which is an iOS 6 feature than allows you to do precisely what you want).
In that case, change your base class to UICollectionViewController, and replace your UITableViewDataSource methods with UICollectionViewDataSource methods. And then redesign your scene using a Collection View Controller.
See the Collection View Programming Guide for more information. Or see WWDC 2012 sessions Introducing Collection Views or Advanced Collection Views and Building Custom Layouts.
If you need to support iOS versions prior to 6, then you have to do this collection view style coding yourself manually, putting your image views on a scroll view and using a standard UIViewController. It require more effort than using a collection view, but can be done.
Original answer:
If this view controller will have a table view on it, but you just want to add more controls to the scene? If so, just change the view controller's base class from UITableViewController to UIViewController, create the new scene, add a table view to it, and specify the table view's delegate and data source to be the view controller:
Also, make sure you define an IBOutlet for your table view (and if you call it tableView, that will minimize any coding changes needed).
If you do that, you can quickly convert a UITableViewController based controller to a UIViewController with minimal code changes.
If you're looking to make something like your new UI mockup, look into UICollectionView. You'll see many of the same concepts (i.e. dataSource, delegate method signatures are similar) that are used in UITableViews used in the collectionView API.
Background
I'm using interface builder to create the UI for an app I'm working on. The app has a single screen that displays a series of buttons. Clicking on a button displays an associated view which overlays the buttons. Clicking another button hides the previous overlay view and displays another one.
Too make managing the UI easier in IB I've decided to create multiple nib files for each sub view that is to appear when clicking the relevant button. I'm then loading the sub view's nib file in the view controller's viewDidLoad method using the UINib class.
The idea behind this was to avoid having multiple views stacked on top of each other in a single nib file as this would be hard to manipulate in IB. I could have created all the views in code but this would require a lot of tedious coding as the layouts of each sub view are quite complex (with multiple child views).
Example code loading a sub view from a nib file.
- (void)viewDidLoad
{
UINib *aSubViewNib = [UINib nibWithNibName:#"aSubView" bundle:nil];
NSArray *bundleObjects = [aSubViewNib instantiateWithOwner:self options:nil];
// get root view from bundle array
UIView *aSubView = [bundleObjects objectAtIndex:0];
[self.view addSubview:aSubView];
...
The code above is repeated for the other views.
To summarise I have a single screen iPhone app that has layered views that are shown/hidden by clicking buttons. This is achieved with a single view controller with an associated nib file and a series of additional nib files for the sub views which are loaded in the view controller's viewDidLoad method.
Questions!
Sorry for the long introduction but I wanted to be very clear what it is I am doing.
Is my approach bad or unusual?
Are there any potential issues to doing it this way?
What have other people done when they need a dynamic interface and
still want to keep everything in Interface Builder?
Notes
Before anyone asks why don't I just display the sub views on a new screen and use the navigation bar, let me say that I have very good reasons and I do understand iOS UI guidelines. The above use case is not exactly my use case but it's one that clearly describes the problem without getting bogged down in my development app.
Also I know I could have written all the sub views as code but each sub view has a complex layout of child views and it would be a lot of code and messing around to try and get them looking right.
Thanks in advance.
There isn't necessarily a 1-to-1 relationship between view controllers and views. Most views contain many subviews, which are views themselves, so this literally doesn't make sense.
However, depending on the complexity of the views (including their content), you may want separate view controllers... or not.
For example, if you have two sbuviews that are each tableViews, you may want to have one view controller for each tableView. This is because each tableView is looking at the same delegate methods, and if they are in the same viewController, then the delegate methods have to differentiate between the tableViews. The delegate methods have signatures that allow this, but, in my experience, it can really make for a messy code design that is hard to follow and hard to manage.
On the other hand, you may have two tables that are managed by the same viewController, where one table is filled with meaningful data and the other is simply a place holder (as when the data source is empty). One might be visible while the other is not. Why make you life complicated by creating two view controllers when both are driven by the same data source (the model)?
In my mind, it comes down to how difficult it is to follow and manage the code. If the complexity of using a single view controller becomes burdensome, consider using more view controllers.
UPDATE
By the way, I have an example that I am currently working with that may illustrate a similar situation. In the InAppSettingsKit, that a lot of developers use, there are several xib files for pieces of the main view. You can look at the structure here on github. There is one main view controllers and several xib files. (There is also what I would call a "helper" view controller and an email composer view controller.) In this example, the xib files may be used multiple times to specify the layout of table view cells. There is no view controller for each xib file, though. (The documentation for InAppSettingsKit is sparse, so these things may not be obvious just by taking a quick look at it.)
Every View should have a corresponding UIViewController. Using one ViewController to "Control" more than one view breaks the MVC paradigm. "Controlling" multiple "views" from one controller will make it much harder to change one thing without breaking something else. The choices you make on how to present the content to the end user will be different for every individual. So if you say a NavigationController won't work in your case, maybe a Modal view is the answer or, you might just instantiate your custom UIViewControllers and add them to your view ([addSubview:]), if thats the road you want, but like I said, it would be beneficial for you to make a "controller" for each view object along with the corresponding xib. If you need information sent back, use a delegate or use Notifications to send the message back to the parent view. I learned the hard way that not following MVC paradigm, will make you life miserable. Try and keep your code as decoupled as possible. And read up on the MVC design pattern, you won't regret it.
actually its possible to do this.
Open your .xib file,select File’s Owner(in placeholder) -> "identity inspector" (utilities) -> change class name to your controller classname -> press control and drag file's owner placeholder to View object, select "view" in dialog.
Now you can customize your view.
p.s. you can use the same outlets as first xib, you need only to drag them to the new xib(+control sure).
here is an explained tutorial:
http://irawd.wordpress.com/2013/09/05/how-to-link-a-xib-file-to-a-class-and-use-2-xib-files-for-iphone4-and-iphone5/