Posts Tagged ‘Cocoa’

Changing Colors

Friday, September 27th, 2019

For those customizing their details view it’s always been a request to be able to change the background color of the image well and the color of the banners that appear over the image to indicate a status, so that they match their main window style.

Matching the Pro Look Dark Style

It’s now possible! With a hidden preference for now. With the beta version of the programs you can use the program called Terminal (located in your Utilities folder) to change the colors. It’s a window were you can give your Mac written commands. Here are the commands you would copy paste with little tweak:

To change the background color of the image use:

defaults write com.bruji.cdpedia "Image Background Color" -string "{200, 200, 200}"

Restart the Pedia and the background of the image will be the above color. The above is a gray. What are those numbers you ask. The numbers are the amount of Red, Green and Blue from 0 to 255. Must color tools will give you those values for a specific color, including Apple’s own color tool in the RGB sliders. Also it’s Pedia specific, be sure to change cdpedia above to the Pedia name you want to modify.

For the banners it’s the same, but they have a gradient, so there are both a top and bottom color (also no restart needed, simply change items in the view).

defaults write com.bruji.cdpedia "Banner Coming Soon Bottom Color" -string "{255, 126, 76}"
defaults write com.bruji.cdpedia "Banner Coming Soon Top Color" -string "{255, 237, 76}"

More yellow pop for those around the corner releases.

The other two remaining banner keys are as follows for the four colors:

Banner Borrowed Top Color, Banner Borrowed Bottom Color, Banner Overdue Top Color, Banner Overdue Bottom Color

If it becomes very popular I can then expose these options in a preference in future version. The good news is you need only change them once and they will stick around forever.

If you ever want to go back to the default colors, here are the reset commands to copy paste into Terminal.

defaults delete com.bruji.cdpedia "Image Background Color"
defaults delete com.bruji.cdpedia "Banner Coming Soon Bottom Color"
defaults delete com.bruji.cdpedia "Banner Coming Soon Top Color"
defaults delete com.bruji.cdpedia "Banner Overdue Bottom Color"
defaults delete com.bruji.cdpedia "Banner Overdue Top Color"
defaults delete com.bruji.cdpedia "Banner Borrowed Bottom Color"
defaults delete com.bruji.cdpedia "Banner Borrowed Top Color"

isNotEmpty a Short Objective-C Code Snippet

Sunday, July 29th, 2012

Today Brent Simmons improved the developer pool of reusable code by posting his code for testing if the value of an object is empty. Most programmers start down this path with NSString where for most purposes an empty string is the same as nil. From there it grows to include NSNull which JSON parser will commonly return, as well as other common objects found in collections such as NSNumber and NSDate and the collections themselves NSDictionary and NSArray.

If you take a look at his code you will notice it’s a function (same as Wil Shipley’s). Because I write almost exclusively Objective-C a function call in my code makes me pause and think. I avoid this by using categories and get to call methods instead of functions. This also avoids the issue of having to write an optimized version of the function to remember to use on NSStrings. With a category you can optimize each individual call for the specific object. So in the hope of improving that shared code pool below is my implementation. Overwhelmingly (97.63% of the time so far) I want to do something with an object when it’s not empty, so my method is reversed. Also isNotEmpty sent to a nil object will result in the correct NO value being returned.

@interface NSString (NSStringExtensions)
- (BOOL)isNotEmpty;
@end

@interface NSNull (NSNullExtensions)
- (BOOL)isNotEmpty;
@end

@interface NSNumber (NSNumberExtensions)
- (BOOL)isNotEmpty;
@end

@interface NSDate (NSDateExtensions)
- (BOOL)isNotEmpty;
@end

@interface NSArray (NSArrayExtensions)
- (BOOL)isNotEmpty;
@end

@interface NSDictionary (NSDictionaryExtensions)
- (BOOL)isNotEmpty;
@end


@implementation NSString (NSStringExtensions)
- (BOOL)isNotEmpty {
	if ([self length] > 0)
		return YES;
	return NO;
}
@end

@implementation NSNull (NSNullExtensions)
- (BOOL)isNotEmpty {
	return NO;
}
@end

@implementation NSNumber (NSNumberExtensions)
- (BOOL)isNotEmpty {
	if ([self integerValue] == 0)
		return NO;
	return YES;
}
@end

@implementation NSDate (NSDateExtensions)
- (BOOL)isNotEmpty {
	if (self != nil)
		return YES;
	return NO;
}
@end

@implementation NSArray (NSArrayExtensions)
- (BOOL)isNotEmpty {
	if ([self count])
		return YES;
	return NO;
}
@end

@implementation NSDictionary (NSDictionaryExtensions)
- (BOOL)isNotEmpty {
	if ([self count])
		return YES;
	return NO;
}
@end

I wrote these categories in 2003 and haven’t thought about them since then. I have 674 total calls to these functions in my code (how I know the exact percentage on how often I use it). Since I recently discovered the easy to use BNRTimeBlock for testing performance I ran the three implementation 10 million times and came up with the following averages after 10 runs:

Time for == King Kong
Conor's isNotEmpty:       0.165795
Brent's RSStringIsEmpty:  0.182188
Wil's isEmpty:            0.860662

Time for == (null)
Conor's isNotEmpty:       0.045048
Brent's RSStringIsEmpty:  0.039325
Wil's isEmpty:            0.041882

Time for == @""
Conor's isNotEmpty:       0.167456
Brent's RSStringIsEmpty:  0.186889
Wil's isEmpty:            0.329623

Average:                  0.224318

This shows that at .000000022 seconds per call you should be using these easy to read and maintain functions and/or methods all over your Objective-C code. Brent’s longer RSIsEmpty performs similar to Wil’s function as it includes the necessary call to respondsToSelector:. At these speeds I think the RSStringIsEmpty optimization is unnecessary except in the heaviest of loops.

I do believe my version should be renamed isSet or isFull to avoid using “not” in the method name; but although one learns a lot in 10 years, I also have been using isNotEmpty for 10 years.