Back in the old days (1990's) when I was using Microsoft Foundation Classes (MFC) in Visual C++, I was introduced to the concept of document-based vs. form-based applications. MFC had (and still has) three types of applications: Multiple Document, Single Document, and Dialog-based. The first two types are variation of what in general is called document-based application where you can open an existing document or create a new one. The framework provides programmers with base classes for Document (application data) and View (user interface). Dialog-based or form-based applications on the other hand have a dialog box (or a form) as their main interface although they still may open files, and there is no framework imposed separation between data and UI. In MFC dialog-based application where easier to make than document-based ones, especially because it was easier to define the program in terms of a series of event-handlers responding to UI objects on the form. Visual C# made creation of dialog-based (now called forms) even easier and got rid of document-based application style (you can still make them if you want but have to create the document class yourself). Cocoa does provide similar option. Default application in Xcode is a "form-based" one, but you may select the document-based option and some classes will be added to your code to support document-based architecture.
Just like I didn't like document-based applications in Visual C++, I didn't like them in Xcode. In fact I disliked them even more because they are harder to use and more confusing than their VC++ version). After a short try, I decided to not work with the document-based applications. If you are interested in learning about them, check this page as your starting point:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Documents/Tasks/ImplementingDocApp.html
Now let's focus on the form-based applications and basic GUI and 2D graphics programming with Cocoa. Here are the basic things you need to know:
1- Cocoa and .NET provide more or less similar functionality for creating basic GUI and 2D graphics apps, but Cocoa classes are slightly more complicated to use. As for the IDE, Xcode is A LOT more complicated to use than Visual Studio. Also Objective-C as the programming language is not as convenient as C# for typical C/C++ programmers.
2- Once you create a default form-based Cocoa application, you have a NSApplicationDelegate class made for you. This can be your starting point to add variables and event-handlers. It already has a member that points to your application window.
3- You design your form (user interface) in Interface Builder that can be launched by double-clicking on your xib or nib file in Xcode. In IB, from the Library add the UI objects to your form. Save and go back to Xcode.
4- You add two important things to your AppDelegate class: member variables representing UI objects and methods for UI event handlers. variables representing a UI objet have the type IBOutlet and the method IBAction. You don't need to specify the exact type of the object. Cocoa uses dynamic types. Here is an example:
=======
//TestAppDelegate.h
=======
#import
@interface TestAppDelegate : NSObject
NSWindow *window; //added automatically
IBOutlet id textView; //outlet for text view
IBOutlet id customView; //outlet for custom view showing images
IBOutlet id textfield; //outlet for a simple text field
}
- (IBAction) clearText: sender; //method for clearing the text view
- (IBAction) setView: sender; //set custom view properties
@property (assign) IBOutlet NSWindow *window;
@end
=======
//TestAppDelegate.m
=======
#import "TestAppDelegate.h"
@implementation TestAppDelegate
@synthesize window;
- (void)applicationDidFinishLaunching:(NSNotification *)aNotification
{
// Insert code here to initialize your application
}
//////////
// This is the part where we implement the methods we added
//
- (IBAction) clearText: sender
{
[textView setString: @" "];
}
- (IBAction) setView: sender
{
//some code here
}
@end
5- Once you add the code in Xcode and UI objects in IB, you go back to IB and link the UI objects to the code. This is done by holding down the Control key and dragging item A (source) to item B (target). For member variables, source is the AppDelegate object in the IB Documents window, and taget is the UI object on the form. For event handlers, source is the UI object and target is the AppDelegate. In both case, once you drop, you get a list of options (class members that you want to use).
6- Instead of using the automatically-added AppDelegate class, you may create a new class based on NSObject and do the exact same thing with that.
7- Another thing that you can do is to add classes to extend existing Cocoa classes. For example we created a new class derived from NSView to control our custom views and make them draw images. It already had some default methods and we added our code to the drawRect method (see previous postings). We can also add member variables and new methods:
=======
TstView.h
=======
#import
@interface TstView : NSView
{
int x; //new variables
}
- (id) setx; //new method
@end
8- Once you have added a new class, you need to go back to IB, select the UI object, and select the new class for it.
9- Finally you use classes like NSPoint, NSColor, and NSImage to do 2D graphics as discussed before and generally in your drawRect method. See previous posts for details.
Hopefully this quick review gave you the chance to learn a little bit about Cocoa programming. It was a good learning experience for me. Although I didn't find any of the two systems significantly superior to the other in terms of functionality, I found the Windows programming frameworks and tools more convenient and effective. Of course I'm not done yet. My next step is to try 3D programming and also test and compare some operations in common 3D programs.
I'LL BE BACK!
No comments:
Post a Comment