I saw in eclipse articles saying that we can subclass Canvas and Composite.
And they have mentioned some points about subclassing the components.
Is that only applicable to SWT components or are they mentioning general
disadvantages of subclassing all the UI widgets? Please refer the site below.
Writing Your Own Widget
They are saying you should only subclass Canvas and Composite. All other SWT widgets do actually check for subclassing and throw exceptions (although this can be overridden).
As the article says the widgets are generally platform specific so you would have to do an override for each platform. Since the widgets are not designed to be overridden the internal fields and methods are usually not accessible anyway.
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.
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
Here is a screenshot from Evernote. It appears to have (but i might be wrong) a custom UINavigationBar as well as a custom UITabBar.
A quick glance at the apps on my phone shows i could use a screenshot of Instagram, Path, DailyBooth, ...
From the docs:-
Because managing the navigation bar is
the responsibility of the navigation
controller, direct modification of the
navigation bar itself is considered
off limits for the most part.
Does Apple regard this kind of thing as grounds for AppStore refusal?
There's a distinction between "custom" navigation bars and using private methods.
Apple prevent you from directly modifying the navigation bar by make a lot of the required methods private or properties read-only. If you were to modify a read-only property or use a private undocumented method your application would be rejected (Apple automatically analyse code upon submission to detect for this sort of thing).
However, there's nothing to stop you from implementing your own UINavigationBar equivalent, or customising it using publicly available SDK methods. The issue then becomes whether your application strays too far from the Human Interface Guidelines: although to be honest, Apple are generally fairly flexible on that.
Whilst I wouldn't necessarily recommend this, I've worked on one app where we rolled our own navigation controller because we had some animation and transition requirements that we couldn't achieve with Apple's own class. As long as you're not calling anything untoward or drastically going against the HIGs, you're generally fine.
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.
I seem to enjoy designing new UIViews and UIControls that implement their own -drawRect: method. This work well for me, especially when composed using UIViews in Interface Builder.
But composing them in Interface Builder is annoying because they just show up as boring plain rectangles.
It would be great if the views would actually render themselves as the built-in controls do.
Is there any way I can structure my project so that Interface Builder will render my custom views?
In order to do this, you actually have to create a plug-in for Interface Builder that uses your custom class. Once you create and install your plug-in, you will be able to drag and drop instances of your class (your view) onto another window/view/whatever just like any other control. To get started with creating IB Plug-Ins, please see the Interface Builder Plug-In Programming Guide. Also, I recommend taking a look at Aaron Hillegass's book, Cocoa Programming for Mac OS X. As well as being very well written and easy to understand, it has a chapter on creating your own IB Palette controls.
This is achievable by marking your UIView subclass with #IBDesignable. Once you do this, your custom views will render themselves in Interface Builder. You can even add parameters that can be configured by marking them as #IBInspectable. Here's a Swift example:
#IBDesignable class customView: UIView {
#IBInspectable var count: Int = 0
}
There's an article on NSHipster that provides more detail.