NSCopying Protocol

@protocol NSCopying
– (id) copyWithZone: (NSZone *) zone;
@end

If you adopt NSCopying, your object knows how to make copies of itself:
@interface Vehicle: NSObject<NSCopying>
{
NSColor* color;
}
// methods…
@end


-(id) copyWithZone: (NSZone *)zone {
     Vehicle * vehicleCopy = [[[self class] allocWithZone: zone] initWithColor: color];
     return vehicleCopy;
}

@interface Car: Vehicle // Car includes the <NSCopying> protocol
{
    float drivingForce;
}
// methods…
@end


// Need to implement copyWithZone, though.
// Make sure Car’s drivingForce instance variable is copied.
-(id) copyWithZone: (NSZone *)zone {
     Car * vehicleCopy = [super copyWithZone: zone];
     [vehicleCopy setDrivingForce: drivingForce];
     return vehicleCopy;
}


http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/
Protocols/NSCopying_Protocol/Reference/Reference.html



Convenience constructor

//laborious
NSNumber* zero_a = [[NSNumber alloc] initWithFloat:0.0f];

[zero_a release];

//handier
NSNumber* zero_b = [NSNumber numberWithFloat:0.0f];

//no need of release



//The Vehicle class
@interface Vehicle : NSObject
{
NSColor* color;
}
-(void) setColor:(NSColor*)color;
+(id) vehicleWithColor:(NSColor*)color;     //convenience constructor
@end





//bad convenience constructor
+(Vehicle*) vehicleWithColor:(NSColor*)color
{
//the value of “self” should not change here
self = [[self alloc] init]; // ERROR !
[self setColor:color];
return [self autorelease];
}


//Almost perfect constructor
+(id) vehicleWithColor:(NSColor*)color
{
id newInstance = [[Vehicle alloc] init]; // OK, but ignores potential sub-classes
[newInstance setColor:color];
return [newInstance autorelease];
}

@implementation Vehicle
+(id) vehicleWithColor:(NSColor*)color
{
id newInstance = [[[self class] alloc] init]; // PERFECT, the class is
                                                                              // dynamically identified
[newInstance setColor:color];
return [newInstance autorelease];
}
@end


@interface Car : Vehicle {…}
@end

//produces a (red) car
id car = [Car vehicleWithColor:[NSColor redColor]];

Autorelease

In C++


Point2D& Point2D::operator+(const Point2D & other)
{
     Point2D result(0.0f, 0.0f);
     result.v[0] = v[0] + other.v[0];
     result.v[1] = v[1] + other.v[1];
     return result;
} //ERROR – it results in a dangling reference because the local object is destructed prior to the return of the function



Point2D& Point2D::operator+(const Point2D & other)
{
     Point2D * result = new Point2D();
     result.v[0] = v[0] + other.v[0];
     result.v[1] = v[1] + other.v[1];
     return result;
} //ERROR – it results in memory leakage because nobody will delete the created object



Point2D Point2D::operator+ (const Point2D &other)
{
     Point2D result(0.0f, 0.0f);
     result.v[0] = v[0] + other.v[0];
     result.v[1] = v[1] + other.v[1];
     return result;
} // CORRECT – it returns a local class object by value
Point2D&
Point2D::operator+= (const Point2D &other)
{
     v[0] += other.v[0];
     v[1] += other.v[1];
     return *this;
} // CORRECT – it returns a self by reference




In Objective-C


-(Point2D*) add:(Point2D*)p1 and:(Point2D*)p2
{
     Point2D* result = [[Point2D alloc] initWithX:([p1 getX] + [p2 getX])
                                             andY:([p1 getY] + [p2 getY])];
     return result;
}
//ERROR : the function performs “alloc”, so, it is creating
//an object with a reference counter of 1. According
//to the rule, it should destroy the object.
//This can lead to a memory leak when summing three points :
[calculator add:[calculator add:p1 and:p2] and:p3];
//The result of the first addition is anonymous
//and nobody can release it. It is a memory leak.


-(Point2D*) add:(Point2D*)p1 and:(Point2D*)p2
{
     return [[Point2D alloc] initWithX:([p1 getX] + [p2 getX])
                                  andY:([p1 getY] + [p2 getY])];
}
//ERROR : This is exactly the same code as above. The fact that
//no intermediate variable is used does not change anything.


-(Point2D*) add:(Point2D*)p1 and:(Point2D*)p2
{
     Point2D* result = [[Point2D alloc] initWithX:([p1 getX] + [p2 getX])
                                             andY:([p1 getY] + [p2 getY])];
     [result release];
     return result;
}
//ERROR : obviously, it is nonsense to destroy the object after creating it



-(Point2D*) add:(Point2D*)p1 and:(Point2D*)p2
{
     Point2D* result = [[Point2D alloc] initWithX:([p1 getX] + [p2 getX])
                                             andY:([p1 getY] + [p2 getY])];
     [result autorelease];
     return result; //a shorter writing is “return [result autorelease]”
}
//CORRECT : “result” will be automatically released later,
//after being used in the calling code

Group term project assignment1


Design of Portable Multimedia Devices


– “iPad application” modification


Fall 2011
Kyoung Shin Park
September 29, 2011


 


Group term project assignment – “iPad restaurant menu order application” Modification  (10 points)

The goal of this group term project assignment is to experiment with the possibilities in iPad restaurant menu order application modification, and to understand the process of designing application functions, as separate from creating the application “assets” or technology.


Your modified iPad application scenario is expected to be completed, and it should be in some way dedicated to new and engaging.


First, your application modification will be built on one of the known applications you surveyed (e.g. iPad Menus, MeuPad, iMenu, SmartCellar, etc) or traditional restaurant menu order system to be modified so that it benefits from iPad mobile service. 


Summit the report (3~5 page) & present the modification in class on Oct 6th, 2011.


Requirements:


-New results must be devised – they can be completely new, or substantial changes to the existing application functions.


-The modification must make use of iPad “assets”.


-Not all the existing application’s parts need to be used.


-Slight introduction of new materials (e.g. more items, different items).


-The functions must be clear and complete, so that a stranger will be able to take them as is and use your new application (include the target audience, number of players, and an estimate of the playing time)


-Notes on the application focus, development and testing – any issues that were revealed during testing; in particular, think about “is the application easy to use?”

Properties

nonatomic
– By default, access to the property is protected by guards that prevent multiple threads from interfering with each other. Normally this is not a problem, and one would specify nonatomic because it is faster.
-nonatomic will make no protection against multiple threads

retain/copy/assign
– retain increases the retain count and asserts ownership of the object
– copy creates a new variable with a new pointer and a retain count of 1
– assign just assigns, and it ithe default

readwrite/readonly
– readonly is used when only the getter will be declared
– the default is readwrite

// Person.h 헤더 파일
@interface Person : NSObject
{
     NSString * name;
     int age;
     BOOL enable;
     UIImage * image;
}
@property int age;
@property (nonatomic, copy) NSString * name;
@property (readonly, assign) BOOL enable;
@property (nonatomic, retain) UIImage * image;
//  위의 정의(declaration)는 아래의 getter/setter 정의를 생성해준다
// – (int) age;
// – (void) setAge: (int) newValue;
// – (NSString *) name;
// – (void) setName: (NSString *) newValue;
// – (BOOL) enable;
// – (UIImage *) image;
// – (void) setImage: (UIImage *) newValue;
@end

// Person.m 구현 파일
@implementation Person
@synthesize age;
@synthesize name;
@synthesize enable;
//  위의 코드는 아래의 getter/setter 코드를 생성해준다
// – (int) age {
//      return age;
// }
// – (void) setAge: (int) newValue {
//     age = newValue;
// }
// value 객체 (NSString, NSInteger와 같은)가 함수의 인자로 전달되거나
// 함수로부터 반환될 때, 객체자체보다는 일반적으로 복사본(copy)를 사용한다.

// – (NSString *) name {
//     return name;
// }
// – (void) setName: (NSString *) newValue {
//     if (name != newValue) {
//          [name release];
//          name = [newValue copy];
//     }
// }
// – (BOOL) enable {
//      return enable;
// }
// image 에 새로운 객체를 설정하면, 그 새로운 객체에 retain 을 한번 호출해 준다.
// 이는 외부에서 그 객체를 release 하더라도 객체가 메모리 해제되지 않도록
// 유지하기 위함이다.
// – (UIImage *) image {
//     return image;
// }
// – (void) setImage: (UIImage *) newValue {
//     if (image != newValue) {
//          [image release];
//          image = [newValue retain];
//     }
// }

-(id) init {
   // …. 중간생략
}
@end


Collection

Collector 클래스
<variables>
     NSMutableDictionary *counts
     double minimumAllowedNumber
     double maximumAllowedNumber
<methods>
     -collect
<properties>
     totalStringCount
     totalNumberCount
     capitalizedStringCount
     NSSet *strings
     NSSet *numbers
     minimumAllowedNumber
     maximumAllowedNumber

CollectionViewController 클래스
<variables>
     totalStringCountLabel
     totalNumberCountLabel
     capitalizedStringsCountLabel
     uniqueStringsCountLabel
     uniqueNumbersCountLabel
     Collector *model
<methods>
    -collect
<properties>
     totalStringCountLabel
     totalNumberCountLabel
     capitalizedStringsCountLabel
     uniqueStringsCountLabel
     uniqueNumbersCountLabel

CollectionViewController.xib사용자 삽입 이미지

6531386710.zipgrab a source code here.

Fundamental Design Patterns

Fundamental Design Patterns
http://developer.apple.com/library/mac/#documentation/General/Conceptual/
Mac101/Articles/02_DesignPatterns.html#//apple_ref/doc/uid/TP40010611-CH3-SW3


Use of the Model-View-Controller (MVC) design pattern ensures that the objects you create now can be reused or updated easily in future versions of your application. http://developer.apple.com/library/mac/#documentation/General/Conceptual/DevPedia-CocoaCore/MVC.html#//apple_ref/doc/uid/TP40008195-CH32

The delegation design pattern allows you to change the runtime behavior of an object without subclassing. Delegation is a pattern where one object sends messages to another object—specified as its delegate—to ask for input or to notify the it that an event is occurring.
http://developer.apple.com/library/mac/#documentation/General/Conceptual/DevPedia-CocoaCore/Delegation.html#//apple_ref/doc/uid/TP40008195-CH14

Controls use the target-action design pattern to notify your application of user interactions. Target-Action is a design pattern in which an object holds the information necessary to send a message to another object when an event occurs.
http://developer.apple.com/library/mac/#documentation/General/Conceptual/Devpedia-CocoaApp/TargetAction.html#//apple_ref/doc/uid/TP40009071-CH3

Other Design Patterns
http://developer.apple.com/library/mac/#documentation/General/Conceptual/
MOSXAppProgrammingGuide/CoreAppDesign/CoreAppDesign.html#//
apple_ref/doc/uid/TP40010543-CH3-SW1



http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/
CocoaFundamentals/CocoaDesignPatterns/CocoaDesignPatterns.html#//
apple_ref/doc/uid/TP40002974-CH6-SW6