I want to add a button that when pressed will lock two sliders together such that the values for the two sliders will always be the same.
I have a solution for this using code, but I'm wondering if there is a way to do this with interface builder alone.
I am worried that the code based solution that one slider may lag behind the other in high CPU utilization environments.
No, there is no way to do this with Interface Builder alone.
Actually everything becomes code in the end, as far as I understand, Interface Builder was built to improve the development time, not necessarily to improve performance, I found this interesting quote on Apple's site about NIBs:
Xcode works in conjunction with these frameworks to help you connect
the controls of your user interface to the objects in your project
that respond to those controls.
Taking into account that, everything will become code (of some level). About NIB files.
At runtime, these descriptions are used to recreate the objects and
their configuration inside your application. When you load a nib file
at runtime, you get an exact replica of the objects that were in your
Xcode document. The nib-loading code instantiates the objects,
configures them, and reestablishes any inter-object connections that
you created in your nib file.
If you would really want to avoid such behavior probably the best you would be able to do is create the widget from scratch, but that would be a totally different question.
Just curious, why wouldn't you want to use code?
Locking the two sliders together in IB is easy. And I've never seen lag. Having that lock dependent on the press of a button is another story, that would have to be done in code, but it would not be too complicated. Assuming you have outlets connected in IB and declared in the controller
-(IBAction)lockSliders:(id)sender {
[slider1 setContinuous:YES];
[slider1 takeIntegerValueFrom:slider2]; // or takeFloatValueFrom or takeDoubleValueFrom
[slider2 setContinuous:YES];
[slider2 takeIntegerValueFrom:slider1];
}
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.
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.
I have a general question for Xcode programming and the usage of the Xcode tools.
I am quite new (4 months) in iOS development and I almost never used the Interface Builder for my purposes. I always created instances programatically. My question is basically if you think i should get used to work with IB or should/can i proceed like i do now?
If you are fine with defining your UI programmatically, then I do not see any issues with that.
Interface Builder allows you to "graphically" define your interface, and this can be an invaluable tool for playing with your UI prototypes, but apart from that there is nothing that you can do in IB that you cannot do programmatically.
In my case, I see that it depends on the kind of UI that I design. When I need a pretty basic UI, the IB is unbeatable for me. On the other hand, when my UI tries to be a bit custom, then I prefer doing everything programmatically.
An interesting point is that you could use IB to design your UI, deciding on sizes and positions of your elements, and the create it programmatically.
Yes you should use IB, basically xcode having IB for ease of development, no need to setting controlls by using coordinates and each time see their visibility by running the app.
just drag and drop and at the time of making the views, you can see hows your screen going to look.
Also using IB is not a typical task so,start development using IB.
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 have a large number of UIViews that are created in the app delegate applicationDidFinishLaunching and added to an NSMutableArray. The user pages through these views using a page control and scroll view. I created the UIView and its child components in IB. They are wired to a controller. To create 170 views on the iPhone takes about 30 seconds. Eventually, I'll have over 1000 views. Besides being slow, it will also kill the app because of memory use. How much faster and memory efficient is creating everything programmatically without views? How might some of the 6000 fact type apps be doing it?
Is there a better approach instead of creating everything at once? The user may access a view in slot # 400 and begin scrolling from there. Any suggestions are appreciated.
UIViewControllers are lazy. They only load when requested, and automatically unload when memory is tight (and it's easy to unload them manually by calling self.view=nil).
"Load" here means "read a NIB," or "build programmatically." ViewControllers don't really care. Building programmatically can be a little faster since you don't have to hit the disk, but this is seldom the bottleneck, since you only display one view controller at a time.
As to which way to go, it's more style than performance (with the exception of UITableViewCells, which there are reasons you need to build programatically in most cases).
Start by studying the View Controller Programming Guide. It'll show you how iPhone intends you to do this.
To eJames' comment about NIBs being XML files, this may be slightly misleading. NIBs are binary files generated by compiling XIB files which are XML. I'd do actually profiling on the phone before assuming that NIB load time is actually a problem. Much as I am by nature inclined to programatic layout, I've found in practice that NIBs greatly simplify many UI issues in practice, and I always come back to them for large projects.
It is difficult to suggest an answer without knowing a little bit more about your specific problem, but I would venture to say that if you expect to display 1000 different things, creating 1000 individual views in IB is not the way to go.
If your pages share a common layout, you can use a UITableView to display the content of each page, and store only the data for each page in your NSMutableArray.
An excellent tutorial on how to use UITableView can be found here.
If they do not share a common layout, laying things out programmatically will be the way to go. This should be no more memory or processor intensive than doing it using IB, and in fact it will probably be faster, since it removes the need to read and parse an XML file (which is what .NIB files actually are).