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.
Related
I did this wonderful tutorial: Photoshop Tutorial For Developers: Creating a Custom UISlider and came away with two questions:
The example above makes every UISlider customized. Can you just subclass UISlider and tweak this code to make it it's own class that can be called upon?
Further, could you make this custom control available in the object explorer within Interface Builder, so you can just drag and drop it on your view like anything else in UIKit?
The docs for CocoaTouch classes will usually indicate if a class is not designed for sub-classing. In the case of UISlider, there's also some instructions for customizing appearance.
Custom Component in Interface Builder
To use a custom component within Interface Builder, its necessary to use the "object" component, and specify the class type to your custom class. Unfortunately this does not render any visual queues, like core UIKit classes.
Your own Plugin
It may be possible to provide a plugin to tweak Xcode, however this is no small undertaking as there are no official docs, so its necessary to search for open-source plugins on GitHub, etc and study the code. Even then, the plugin may break with subsequent version of Xcode.
Recommended Approach
Interface Builder is an amazing technology, however for more complex applications I recommend implementing views in code (override loadView in the VC). Here's some reasons:
Promotes better encapsulation and reuse. You can compose your own components (eg composition vs inheritance) using UIKit components, and provide a custom OO interface to them. Contrast this with lots of IB outlets in a view controller, which leads to poor reuse.
Fat-controllers don't really honor the MVC paradigm.
More flexible and fluent. Not all properties are exposed via IB, so in a complex case, its hard to know where to look. Is that setting in IB or code? Custom fonts, for example.
Xibs are really tricky to merge in a multi-person team.
Is this really the proper and only way to programmatically set the target of an animation in a Windows Store app?
Storyboard.SetTarget(animation, someElement);
Storyboard.SetTargetProperty(animation, "Width");
It just seems odd not to use an instance method or property on either a Timeline or Storyboard.
It's the programming equivalent of reaching in your car window and using the interior handle to open the door.
Luke
It is the correct way, yes. I do agree it could be made simpler, but it is how it has been since WPF.
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];
}
Lately I've been running into some subtle layout issues in my iOS app. For example displaying a viewController from one part of the app causes the layout of some subviews to be altered (the z-axis ordering changes). Another subtle issue is the navigation bar flickering slightly.
What are some techniques for debugging these issues?
I'm especially interested in printing/logging properties of objects. For example I'd like to just dump/print/log all properties of the viewController referenced above to see exactly what changes. Then perhaps one can use symbolic breakpoints to pin-point the cause.
Check out DCIntrospect. It's a tool that can be very helpful for looking at view's info conveniently.
You can use KVO to observe frames changing, so you know what changes when, from and to what values. You can even use it to fix properties to some contant value. (See Prevent indentation of UITableViewCell (contentView) while editing)
You can use reflection to loop through all properties of an object. I don't know how such a broad approach would help you, but it is possible. (See Loop through all object properties at runtime)
Another technique to use is to subclass a UIView with override methods for re-positioning a view, or other aspects - then you can set breakpoints or log when the frame changes, or other attributes.
To use the UIView debugging class you can just change the type of a View in InterfaceBuilder to be your custom view type instead of UIView.
Use iOS App layout Debugging tool
revealapp.com
Just integrate revealapp SDK in your app and work as firebug
Is there disadvantages to using WebKit WebViews compared to using NSViews?
I'm using a webview to create a UI for an application. The application itself does not have much interactivity. I have seen it mentioned, on this website & others, that using a WebView can be convient means of prototyping.
However, with our team this seems like an ideal way to produce the production ready UIs, especially with WebKit. Are we missing something?
Thanks,
Ross
Okay, so you seem to be asking if using an HTML interface (presented via a WebView) for your application has any disadvantages.
The answer to this is "no", at least "not necessarily". This is analogous to building an iPhone specific web application, and there are some excellent examples of those. The caveat would be that a lot of those sites end up recreating the look and feel of a native iPhone app, for consistency and to make the users feel "at home".
Given that you're developing a native app anyway, it seems a shame to throw away, or recreate, the responsiveness and appearance of the native chrome. Of course, for certain types of applications (games are an obvious example) a user has no expectations about the application's UI, so you're free to knock yourself out.
The other factor to consider is the amount of interactivity (although I notice that you say there isn't much in your case). The native controls will make coding a lot simpler than having to capture all user input through the "filter" of a WebView, even though using one might make the initial layout of the screens easier.
I hope that's the sort of answer you were looking for (although it's mostly non technical).
As you might have known if you spend some time in the documentation, you'd have seem that WebView is a subclass of NSView.
The documentation says about WebView:
WebView is the core view class in the WebKit framework that manages interactions between the WebFrame and WebFrameView classes. To embed web content in your application, you just create a WebView object, attach it to a window, and send a loadRequest: message to its main frame.
And about NSView:
NSView is a class that defines the basic drawing, event-handling, and printing architecture of an application. You typically don’t interact with the NSView API directly; rather, your custom view classes inherit from NSView and override many of its methods, which are invoked automatically by the Application Kit. If you’re not creating a custom view class, there are few methods you need to use.
So here's the answer to your question:
Is there disadvantages to using WebKit WebViews compared to using NSViews?
Yes. You can't display any web content with NSView. That's what you need WebView for.
I suggest reading some more documentation though.