I would like to add a file to my project, who's sole purpose would be to hold an array. I would then #import this file wherever I need to add/get from the array.
My problem is that when I create a new file (I'm using Xcode 4), I'm not sure what type of template to choose, and then what subclass to choose.
My reason for doing all of this is because I have a SplitView-Based app, and one of the views has a textfield, where I am trying to output data. My problem is that whenever I switch to a different view and then switch back, only the most recent entry is there. I am not 100% why that is but I suspect it is because when I switch to a different view, the current view is forgotten about, along with the variables in it.
This is not a good way to do it. There are many ways to do what you want: prepareForSegue: if you are using storyboards, delegation, instantiating your viewcontroller in code and setting a property in the header-file..those are just a few ways.
The way you are proposing is a slippery slope to bad Objective-C code and is only going to cause you more headaches in the future. Take the time to learn to do it right.
Check out this to get you thinking in the right direction.
How you save your data doesn't appear to be your problem. Take a look at the MVC design pattern and how view controllers implement it. They often rely on a dataSource protocol, which links the data from a "Model" to your "View" in a logical way to achieve your intended purpose.
The view controller should then be able to assign a delegate (usually itself (self) to keep the view populated with the correct data, whether the view gets unloaded or not.
If your view controller doesn't refer to a data source or a corresponding protocol, it would still be worth your time to see how you might take advantage of that design pattern. It will pay off in the long run to know this.
Instead of saving variables to a text file, you should consider using NSUserdefaults instead.
But I don't think that's the real solution to your problem, just wanted you know that there are other ways than saving stuff to a text file.
Related
In all my apps I am delegating all my UIButtons,UITextField,pickers etc.I am able to delegate these by 3 ways.
1-I am simply control+dragging the buttons,text field etc from the story board to the .h file which creates the delegation directly.
2-In .h file I am creating the buttons,text fields etc and then making the connections.
3-Programmatically doing the delegations
I want to know which is the best way to do it.
Best way is to use storyboard for referencing outlets and delegates. If you are not able to use storyboards then you do by codding. Storyboards will save your time of codding there is no major difference then this.
That is depending on you,you can do any way based on your
requirement,but Final result is same for all three methods.
if you want to create dynamic labels and buttons at that time you must
use programatical method because you don't have any other solution
,like that you can do it by your choice based on your requirement.
They are equivalent. It's the same question as "is it better to write my UI programmatically or design it with Interface Builder?". The end result is the same; you should think about Interface Builder as simply a convenience tool and mechanism for creating interfaces and logic quickly. And if you need, you can mix both methods without problems.
When you drag your control from the IB sheet to your controller's code, you're creating a target-action association that is stored in the .xib file. When the .xib file is unpacked at runtime, your controls are created and their connections are restored, the same as if you did that programmatically.
In MVC the View shouldn't hold it's data. However I know in Objective-c you do: [textField setString:#"hello"];, that string is then retained by the text field. The same applies for the textField's font and text colour, etc.
However a UITableView uses a datasource to ask a controller for it's data, it's then up to the controller to reload the table view. But it also stores some data itself, like background colour.
I can understand a reason as to why a UITextView doesn't use a data source the code would become much more lengthy, if every property had to be a method. But why use a data source in some cases and not others, why not just set an array of UITableViewCells (I know that this means cells could not be reused and so it would use more memory, but what other design reason is there), for the UITableView to display?
And when creating you own objects how do you know when to just store a small amount of generic data (e.g. the string a textview displays can only be a string, but any the string itself can be anything)in a view, or use a datasource?
MVC is a pattern, not an edict. Let the view do the work. Some coupling is just going to happen. Follow the guidelines of the pattern, and bend it to the style and desires of your developers and organization.
I'm not familiar with objective-c's mvc framework, but I think I understand the question.
Basically, you don't want the view doing anything with the datasource backend, that is, anything having to do with the plumbing of accessing the DB.
But its ok for the view to have access and use the data itself. That is the M part of MVC. The model gets passed around. The view knows how to display it. The controller knows how to do the business logic to it (including interacting with backend systems like the data access layer).
In the case of data grid, it has to hit the backend to get the data, so it has to rely on the controller.
Ideally, the view knows only about display related information (like the background color). The whole idea being separation of concerns. You want the view to handle just its part of things, like-wise the controller. Then you can modify them independently of each-other.
As for the specifics of the datasource (versus an array), grids tend to be complex. Maybe that is handling paging or other niceties. In this case, I don't think its so much the separation of layers (since an array could just as easily be the model), but handling more functionality.
I'm not sure what you mean re 'storing' small amounts of data in the view. The view should tend to deal with 'view stuff'.
My app requires an interface that has many buttons, text fields and matrixes. And they need to change from time to time. Right now I do this by having all elements in IB already and hiding/showing/moving them when needed. What would others recommend? Should I do that? Should I use an NSTabView? NSView? Should create the elements programatically? If so, what if I have an element that is already created that I need again without changes? It would be a waste of releasing it and creating it again.
Any help would be greatly appreciated.
In my opinion, it's better to create interfaces programmatically if you have to animate views around a lot. If it's just a matter of hiding/unhiding them, IB works great, but if you need re-layout or create unknown numbers of views dynamically it's not worth trying to make it all work with nib files.
As for general advice:
Create subclasses (from UIView or UIControl or one of their subclasses) for every kind of element you're going to use. It's tempting to piece together composite views from your UIViewController, but you'll really be much better off creating real classes.
Study the standard Cocoa view classes, and try to create similar API:s in your own controls and views.
Put as much data (sub-element positioning etc) into a plist, so that you can easily change it from one centralized place instead of having to dig around in the code.
If you are often creating several dozen short-lived views, it's worth keeping them in a pool and reusing them. But if it's just a few labels being added and removed intermittently I wouldn't worry too much about it. As usual: don't optimize too early.
Your current approach sounds fine. If you're showing/hiding them but otherwise they remain unchanged, why go through the trouble of creating them with code, when your XIB keeps a "freeze-dried" copy of exactly what you need already?
As long as you're keeping them within logical groups, you can just move/swap/show/hide the group's container (like NSBox or an NSView). If you have a LOT of logical groups, which aren't always shown every session, you can separate them out into their own XIBs and only load them when they're needed, to save launch time and memory.
If you use NSViewController, it's even better because you can make clean breaks for each logical group. Load the panel as the view and the view controller will keep outlets/actions and has a one-to-one relationship with a xib.
I've a fairly complex window that is backed by a controller class that is obviously growing to meet the needs of my view window. While I believe I am sticking to proper MVC I'm still having problems managing a fairly largish controller class.
How do you breakdown your objects? Maybe use Categories? For example, one category to handle the bottom part of the window, another category to handle my NSOutlineView, another category to handle a table, and so on and so forth?
Any ideas or suggestions are welcome.
It sounds like it's a complex window controller that's growing to unmanageable proportions? This is getting to be a more common issue because of applications which, like the iApps, do most of their work in a single window.
As of Leopard, the recommended way of breaking it down is to factor out each part of the window into its own NSViewController subclass. So, for example, you'd have a view controller for your outline view, and a view controller for each of your content views, etc.
Also, I'd like to second the use of #pragma marks to divide code files up into segments, and in addition to categories, I also like to use class extensions for private methods.
It's a simple answer, but the code folding feature of the Xcode IDE can be handy for focusing your attention on sections of a class. Another little thing that might help is going to View->Code Folding and turning on Focus Follows Selection. This makes it so the background color of the scope of your current selection is white while everything else is shades of gray.
Categories are ideal for this. Create a new file for each category, and group them by functionality, as you suggested.
I've tried using Categories in situations like this and I just end up confusing myself, wondering how in the world I'm calling that method when it's "obviously" not in the class I'm looking at.
I'd recommend liberal use of #pragma mark in your source code. Makes it super-easy to browse through all your methods.
I've searched and searched but nothing has really worked.
I'm trying to set a textvalue from a text box, into a string or whatever, so that I can call it up later in a different view controller. I can't seem to get it to work!
I'd also like numbers to be carried over, such like currency's.
Any ideas on them?
Cheers.
You could make an instance variable on the other view controller retain or copy the value before you push/pop the view. For example:
OpenNextViewController *varNextPageController = [[OpenNextViewController alloc] initWithNibName:#"OpenNextViewController" bundle:nil];
varNextPageController .textString= self.textString;
[[self navigationController] pushViewController:varNextPageController animated:YES];
[varNextPageController release];
In "OpenNextViewController" in this example have an instance variable "textString" that retains or copies (depending on your needs) your text.
Spend some time trying to grok the Model View Controller pattern.
In your case you may be looking to share data between different views sharing a common Model. The Model is the store of your data, in your case the textvalue.
Your question is a bit vague. Could you give any more specifics.
It sounds like you want to know:
How to get values from controls. In the case of a text field there should be a text property you can get the value from.
How to share values between controllers. Not sure exactly what you mean. The controller usually orchestrates the sharing of values between different views by using a model as the authoritative version of the data.
Again, if you can be any more specific we may be able to help more
If you want it in several controllers, then I would think you need to run it through the model?
Do you guys think that using the AppDelegate as the holder for one's model is fundamentally wrong? I mean AppDelegate is easily visible to all controllers so it's easy to bind to and get/set it's properties.
pom