I am getting incredibly frustrated with interface builder at the moment, and would appreciate some help before I ragequit it and code everything by hand (which seems to be much, much, much easier).
The basic situation is this: I need to make a model variable accessible to each view controller in my application.
The simplest way I can see to do this is to just create a property on the view controllers that retains the model, and to set that after the controller is initialised.
However, I can't find any of the actual initialisation code for the views shown on the storyboard in my project. There's no reference to any of them at all. Does the interface builder really generate not generate any code reference to its controllers in the app delegate?
For that matter, why is there no reference to any of the top level controller objects (tabview, tableview etc) in code at all?
All I want to know is how to force xcode to actually generate the controller creation code in AppDelegate.m - so that I have access to the created instance of the controller - or, failing that, a way to share the model between these amorphous objects.
Maybe it would be easier to create a singleton class where you can store all your global variables and methods. Example here.
You will need to manually create a subclass of your view controller and then override the methods you want to inject code into. In Interface Builder you can then choose to make your View controllers of this custom type.
Related
I'm presenting a page based modal using [self presentControllerWithNames:self.controllerNames contexts:self.controllerContexts];, where controllerNames is just an NSArray of NSStrings containing my interface controllers names. The problem is that I would like to access the created controllers.
The documentations says that
WatchKit loads and initializes the new interface controllers and animates them into position on top of the current interface controller.
but I would like to have a reference to them, in order to call the becomeCurrentPage method from outside.
So, I would like to be able to save those controllers after they are created in a list, and programmatically change the page using something like [self.controllers[2] becomeCurrentPage].
Because you're allowed to provide a context when you present an interface controller, you can pass a reference to self. That way, you can establish a reference from the presented controller to its parent. Once that relationship exists, you can use things like delegation patterns to communicate.
I use this extensively in my own Watch app, and I've wrapped a lot of these mechanics in my JBInterfaceController subclass on GitHub.
I created a very simple new Cocoa application, with a new class and custom controller (or object in interface builder, the plain blue cube). I connected all outlets with interface builder and assigned the custom delegate to the class. The problem is, the code does not get executed (checked by setting breakpoints), the window presents itself, and there are no errors.
The code of the class is really irrelevant, I tried once before with a proper set up and it worked there, I couldn't spot the difference however.
The key here is a separate controller together with class instead of the standard App's Delegate, to integrate the project to a bigger one.
I know it's possible to attach a custom view controller class to several different view controllers on a storyboard, but can it be done in the other direction; that is, depending on the situation, I want to bind different custom classes to a single view controller on the storyboard that will be instantiated using:
[self.storyboard instantiateViewControllerWithIdentifier:]
background: I used to have several view controllers on my storyboard that are almost identical. In fact, the custom classes that they each bind to are very similar as well. In an effort to clean this up, I refactored my custom classes into one base class and several subclasses. I then removed all the similar view controllers from the storyboard leaving only one which I've bounded to my base class. I then call:
MySubclass* mySubclass = [self.storyboard instantiateViewControllerWithIdentifier:#"StoryboardControllerBoundToBaseClass"];
Unfortunately, my subclass code is being ignored and only the base class code is ever run. Does anyone know how I can make it work without duplicating view controllers on the storyboard and binding each one to a different subclass?
It's not possible. Just because you say MySubclass *object = something doesn't magically convert object into a MySubclass object. It's stored in the storyboard with whatever class was assigned at storyboard compile time.
Rather than using subclassing, I figure I can reuse a view controller on the storyboard by using a delegate/proxy model. More specifically, I can bind the storyboard's view controller to a custom class that delegates all of its methods/events to others classes to handle. This isn't as elegant as subclassing but at least I can keep my storyboard leaner, not having to keep several copies of pretty much the same view controller. Plus, I won't need to duplicate future changes to every copy of these controllers to boot.
As guylegend writes. Apple doesn't support the way to do that. There are many workarounds e.g. with delegates but I finally found the answer and answered in another topic. Hope it helps!
https://stackoverflow.com/a/32103618/1943053
I'm going through my code to make sure that all of my properties have the proper weak/strong modifier and I ran across this situation which I don't know what to do with. Keep in mind that I'm fairly new to iOS programming.
I have a normal MVC hierarchy where my controller creates an object called FieldManager. This FieldManager is used by my controller to dynamically create textfields. However, this FieldManager also needs to be used by the controller's model to periodically query the manager to find out information about the fields (such as is it required, should it's text be capitalized...etc).
So to summarize, I have a controller which creates an object that is used both by the controller and the controller's model. Therefore, I don't know if I should make the model's reference to FieldManager a weak property or the controller's reference to it a weak property. It seems that I should make both weak properties, otherwise FieldManager will get released. What should I do?
Thanks.
Things like that should belong to your model, so the way to go is to have a datasource.
Your controller asks the datasource to create and return the textfields, the datasource contacts the model and asks for a field manager for that model.
That's the way I would do it...
Sorry for the stupid post, but I am new to Objective-C programming and Cocoa and have a couple of questions which I can't find the answers to, I'm hoping someone can enlighten me.
Firstly, in XCode, when using the Interface builder, when I want to create a new object I drag the object to my 'assets'. However I can't specify methods or anything without manually creating a new class file. Is there any point using the interface builder's 'object'?
The first app I built to test things with, I put most of the code in the AppDelegate class files. Research has shown me that the AppDelegate's purpose is simply handling application events like launching and closing. Was I wrong in putting the methods in this class? Does it make any difference?
Finally, if I have several class files created, each handling their own functionality with an interface built and linked to the classes, then what do I do with the 'main' file? It seems to me that the 'main' file and 'appdelegate' class files will be for the most case left as-is?
I hope that makes sense. Again i'm sorry for the silly-sounding questions but I can't find any answers.
Thanks in advance everyone!
Firstly, in XCode, when using the Interface builder, when I want to create a new object I drag the object to my 'assets'. However I can't specify methods or anything without manually creating a new class file.
Sure you can. Just set the class of the object using the inspector.
Note that you can only connect nib objects to an outlet or action. You can't specify any random methods, nor should you—the whole point of the IBOutlet, IBOutletCollection, and IBAction keywords is to declare in code that these properties/methods are used by a nib.
Is there any point using the interface builder's 'object'?
Yes, but pretty rarely. Usually you create objects in code and connect outlets to them.
The application's delegate is one object you may want to create in the MainMenu or MainWindow nib, if you build your application that way (the iOS templates have changed away from it for some reason).
The first app I built to test things with, I put most of the code in the AppDelegate class files. Research has shown me that the AppDelegate's purpose is simply handling application events like launching and closing. Was I wrong in putting the methods in this class?
Probably. The application's delegate generally should only handle business relating to the NS/UIApplicationDelegate protocol.
On the flip side, it's OK to make your root view controller the application's delegate, if it makes sense to do so (and the NS/UIApplicationDelegate implementation code is not too voluminous). The question you have to answer—and only you can answer it for your application—is whether you are making your root view controller the application's delegate or the application's delegate the root view controller. If in doubt, keep them separate.
Does it make any difference?
Long-term, yes. It's very easy, especially in the class of the application's delegate, to create a Big Ball of Mud class—one without well-defined and clearly-delineated responsibilities. Take dynamite to such a class as soon as possible.
Finally, if I have several class files created, each handling their own functionality with an interface built and linked to the classes, then what do I do with the 'main' file? It seems to me that the 'main' file and 'appdelegate' class files will be for the most case left as-is?
Yes. They're boiler-plate.
If you haven't written any code in the application's delegate (or have removed everything you had put there into new and better-delineated classes), such that all that's left are empty method bodies or none at all, you can safely remove the application's delegate. You can always create it again later if you change your mind.
Note that if you delete your application delegate class, you should also change the main.m file—or the MainMenu/MainWindow nib, if you have one—to not refer to it. Your application won't build if your UIApplicationMain call (or any other code) refers to a class that doesn't exist, and it will crash if your MainMenu/MainWindow nib (or any other nib) refers to a class that doesn't exist.
There is no shame in your application having a delegate if you need it to, but if you don't, removing it and the class you were using for it eliminates future temptation to stuff code there or use it to store third-order globals.
The point of using objects in interface builder is to connect methods of the object to UI elements.
It partly depends on what your methods are doing, but for the most part the app delegate class is going to be left alone. It isn't an actual requirement (your program will work either way) but it is common practice because it generally creates more maintainable code. The app delegate should just handle the application events ( using other classes to do any complex logic or heavy lifting ).
The 'main' file will most likely not change. I can't think of any reason to do so, but I wouldn't rule it out for some advanced cases.
To be honest I only used the Object thing in IB once, when I wanted a separate object to have some UI bindings.
About the app delegate and main file, yes, you'll leave them as-is most of the time. But if you try to do something besides test apps you'll need to handle open events to, for example, connect to a server, ask the user for a review, increment some launch counter, etc... Those are just examples!
The main file I advise you to left it alone and use the object oriented tools provided. You should have a view controller hierarchy, isolate your views from the data, and use the view controller to comunicate between view and model. Read about MVC if you want more info on how your application should be organized.