Cocoa

Hands on tutorial to NSDateComponents

Posted in Cocoa on July 5th, 2010 by Christian – Be the first to comment

Calculating dates is quite a hard thing to do. You need to keep in mind that adding or subtracting days (or months, hours, …) to a date can lead to changing months or even years: Getting the date of “two days before the first of January” leads to substract a year and a month from the current date, the result is the 29th of December a year before. You even need to keep leap years in mind.

But there are tools in Cocoa that takes all the heavy stuff off of calculating dates: the NSDate, NSCalendar and NSDateComponents classes. There are (at minimum) two things you can do using NSDateComponents: get components of a date and calculate new dates by changing components.

Getting Date Components

Getting date components of a given NSDate is very easy using NSDateComponents:

-(int)month:(NSDate*)date {
NSDateComponents *comps = [[NSCalendar currentCalendar] components:NSMonthCalendarUnit
fromDate:date];
return comps.month;
}

To access components of a given NSDate we are using NSCalendar to get a group of components of it. Here we are interested in the month. So at first we are asking NSCalendar for the NSMonthCalendarUnit of our given date.

After that we can access the specified units from the NSDateComponent. What’s important to know is that accessing units we didn’t specify on components:fromDate won’t give the correct values but more or less random values.

You can also use NSDateComponents to get a date that only contains the values for given components. For example you can get a NSDate that contains the beginning of the day without hours, minutes, seconds, etc.:


NSDate *date = [NSDate date];
NSDateComponents *comps = [[NSCalendar currentCalendar] components:(NSYearCalendarUnit | NSMonthCalendarUnit | NSDayCalendarUnit)
fromDate:date];
NSDate *beginningOfDay = [[NSCalendar currentCalendar] dateFromComponents:comps];

Calculating New Dates

To calculate new dates from a given date, you can configure a NSDateComponents instance as an offset to a date:

-(NSDate *)previousMonth:(NSDate*)date {
NSDateComponents *comps = [[NSDateComponents alloc] init];
[comps setMonth:-1];
NSCalendar *cal = [NSCalendar currentCalendar];
NSDate *date = [cal dateByAddingComponents:comps toDate:date options:0];
[comps release];
return date;
}

At first we instantiate a NSDateComponent and configure it with the offsets we want to add to the NSDate. In this example we want to calculate the date a month before today so we set the month to -1.

After that we create a new NSDate by adding the components to the given date.

Summary

NSDateComponents provides some really great functionality for creating dates with only requested components and to calculate dates as offsets from a given date. The class ensures that the calculated date is valid.

For my projects I created a NSDate category that provides some convenient methods to get date components and calculated dates.

Using Xcodes build system for iPhone + iPad projects

Posted in Cocoa, iPad, iPhone on April 8th, 2010 by Christian – Be the first to comment

My iPhone app iVocabulary will be available for the iPad as a separate application, not as a universal app. This is because the iPad version should be a First Class application not a scaled-up “Economy” app (as mentioned here). There will be many classes that are shared between both applications and therefore I build the apps from one Xcode project.

To distinguish between the devices in code, Apple advises to use something like this:
#if __IPHONE_OS_VERSION_MAX_ALLOWED >= 30200
MyIPadViewController* vc;
// Create the iPad view controller
#else
MyIPhoneViewController* vc;
// Create the iPhone view controller
#endif

But this can get very tedious and error prone. If you’ve got classes that are mostly the same for both devices but differ in some methods, the Xcode build system comes to the rescue.

Lets assume your AppDelegate differs in one method that initializes a viewcontroller differently for both devices. You can build that method and surround both code blocks with the structure above. But there is a better way: You create two categories for your class: AppDelegate+iPhone and AppDelegate+iPad:

/// file AppDelegate.h
@interface AppDelegate {
MentionedViewController *_viewController;
}
- (void)initMentionedViewController;
@end

/// file AppDelegate.m
@implementation AppDelegate
- (void) applicationDidFinishLaunching {
...
[self initMentionedViewController];
}
@end

/// file AppDelegate+iPhone.m
@implementation AppDelegate (iPhone)
- (void) initMentionedViewController {
... do special iPhone stuff here ...
}
@end

/// file AppDelegate+iPad.m
@implementation AppDelegate (iPad)
- (void) initMentionedViewController {
... do special iPad stuff here ...
}
@end

The important part is to define the targets of the categories .m-Files via the targets tab in the info screen:

Screenshot Xcode Targets

Xcode "Targets" tab

During the build, the Xcode build system includes the correct file and the other one will be left out. This way you get the same result as if you used the #if-constructs but with much cleaner and more transparent code.

ProVoc Cocoa style

Posted in Cocoa, ProVoc on April 4th, 2010 by Christian – Be the first to comment

While improving ProVoc for the next iVocabulary version (to add synchronization) I am currently refactoring the looks of ProVoc to look a lot more mature and Cocoa like.

Here is a small example (labels are German):

Screenshot ProVoc Cocoa-Style

Screenshot ProVoc Cocoa-Style

Cross Compile ProVoc with Cocotron?

Posted in Cocoa, Cocotron, ProVoc on March 25th, 2010 by Christian – 1 Comment

To build a vocabulary editor for Windows I considered building one in Java as the only option. But then I found the project Cocotron. Cocotron is an implementation of Cocoa for Windows and Linux (and could also be ported to other plattforms). It is easily integrated to Xcode so that you can build the Windows version of your application with few clicks.

For building Cocotron you need to install some tools. These are downloaded and installed with few steps that are well documented on the Cocotron website. The navigation is not always clear on that website but you can find your way through it. The website itself is also coded in Objective-C and compiled for Linux using Cocotron.

After you installed the needed tools you can checkout (or download) and compile Cocotron. For me the Cocoa project was all I had to build since it references some of the other needed packages. With the build process the library gets installed into the Developer folder.

The next step is to add a new target to your existing (or new) project. You can easily do so by copying an existing Mac OS target and clean up and adapt the build settings. That process is also well documented on the Cocotron website but it take some trial and error for me to find out if I did all I need. As soon as you don’t get any low level errors from gcc you can start porting your application. Depending on the complexity of your application it may use some parts of Cocoa that are not implemented in Cocotron by now.

For ProVoc the last part was not easy and is not finished by now. I added many #ifdef _WIN32 and #ifndef __APPLE__ to the code to disable unimplemented parts and it builds without errors (but with many warnings). ProVoc starts on Windows but there still seem to be some problems as it hangs shortly after starting. You can also debug your application on Windows using Insight-GDB what I started to do at last.

As soon as I find some free time I will continue trying to get ProVoc run on Windows and I will post my findings here.