Support for exclusions. Support for -568h@2x images. Strayed frameworks moved into the Frameworks group for the demo project.

[schiffy91]

Exclusions

Background

The NUI community wants to exclude specific classes, and their derivatives, from NUI's styling.

Problem

There is no way to exclude specific classes, and their derivatives, from NUI's styling.

Solution

I have edited - (void)setNuiClass:(NSString*)value in UIView+NUI and added + (NSArray*)getExclusions to NUISettings to support recursive styling exclusions. This solution does not traverse the display tree; instead, this solution iterates through an array of excluded classes, which are set at runtime.

Notes

Similarly to below, I opted for a small solution that is non-obtrusive and easy to understand. It is less performant than a more complex solution that I can provide, if necessary. The more complex solution will most likely involve caching and hashing.

-568h@2x

Background

UIImage's - (UIImage *)imageNamed:(NSString *)name natively searches for @2x files on retina devices; however, this method does not search for associated -568h@2x files on iPhone 5.

Problem

NUI does not load -568h@2x files on iPhone 5 when they are present.

Solution

I have edited + (UIImage*)toImageFromImageName:(NSString*)value in NUIConverter to search for -568h@2x files on iPhone 5. If a -568h@2x variant is found, it is returned; otherwise, the value from UIImage's - (UIImage *)imageNamed:(NSString *)name is returned.

Notes

I opted for a small solution that is non-obtrusive and easy to understand. It is less performant than a more complex solution that I can provide, if necessary. The more complex solution will at least require one class extension or proxy.

[tombenner]

These are looking very promising; thanks! I'll need some time to review them more, but out of curiosity, could you very generally describe your complex solution to the exclusions issue? No worries if it isn't fully fleshed out yet.

[schiffy91]

@tombenner, my complex solution to exclusions removes the necessity of traversing the excluded class list for each rendered UIView. Currently, if there are n excluded classes and k UIViews, NUI calculates n * k additional steps to manage exclusions for any given rendering. This doesn't include the additional steps for each isKindOfClass call (which is allegedly optimized). The upside to this solution is that it is very easy to implement and understand, does not require traversing additional rendering trees, and memory management is also low.

To improve rendering performance, NUI can exhaust all subclasses of each excluded class at the time of initialization for the app, throwing each class's stringified representation in an NSDictionary with their values being a static non-nil NSObject. Upon rendering, NUI would then check to see if the value associated with the class is not nil (which can be done in O1 time if I implement cuckoo hashing), or if its parent is nuiIsExcluded.

There are numerous downsides to this, and the most important is that it's very ugly. Finding all of the subclasses of a given class, despite being a one-time job, is not performant or 100% reliable (dynamic classes, for example, would be impossible to exclude). An example of how to implement this class-hierarchy traversal can be found at: http://www.cocoawithlove.com/2010/01/getting-subclasses-of-objective-c-class.html. This also significantly increases memory usage by NUI. The upside is that there is little-to-no performance impact with the actual rendering of UIViews.

I personally think this solution is very excessive, but I'm unfamiliar with NUI's performance and how much of an impact (for better or for worse) either will make.

[tombenner]

Interesting; I'd like to continue thinking about both of these (I agree that there are downsides to the complex solution, but it's an interesting path). Many thanks for spending time with this; it helped force me to think about it more, too. You may've seen that I've merged #65, as its simplicity seemed best for the short term, but I'm definitely still open to other ideas. Thanks!

Support for -568h@2x images needs to be added, too; I'm still evaluating the best approach for that.