IPhone & J2ME APPLICATION DEVELOPER: Iphone Numeric sorting

IPhone & J2ME APPLICATION DEVELOPER: Iphone Numeric sorting

Iphone Numeric sorting

Iphone Numeric sorting For Array objects

NSArray *unsortedArray = [NSArray arrayWithObjects:@"Hello", @"4", @"Hi", @"5", @"2", @"10", @"1", nil];
NSArray *sortedArray = [unsortedArray sortedArrayUsingComparator:^(id firstObject, id secondObject) {
    return [((NSString *)firstObject) compare:((NSString *)secondObject) options:NSNumericSearch];
}];

http://stackoverflow.com/questions/4588542/sorting-nsarray-which-many-contain-number 

Iphone Numeric sorting string For Array objects

http://stackoverflow.com/questions/3230286/sort-an-array-with-numeric-strings

iphone basic question

http://www.otierney.net/objective-c.html#inheritance

http://www.google.co.in/#hl=en&q=id+in+objective-c&aq=f&aqi=&aql=&oq=&gs_rfai=&fp=bc4921db69ff5ed7

http://en.wikipedia.org/wiki/Objective-C#Interfaces_and_implementations

http://en.wikipedia.org/wiki/Cocoa_(API)

http://www.google.co.in/#hl=en&q=what+is+ns+in+objective-c&aq=9m&aqi=g8g-m2&aql=&oq=ns+in+&gs_rfai=&fp=bc4921db69ff5ed7

Model-view-controller

The Smalltalk teams at Xerox PARC eventually settled on a design philosophy that led to easy development and high code reuse. Known as "model-view-controller" (MVC), the concept breaks an application into three sets of interacting object classes. Model classes represent raw data, such as documents, settings files, or objects in memory. Views are, as the name implies, visual representations of the data in the model. Controller classes contain logic which links the models to their views, and maintains state to keep them synchronized.

Cocoa's design is a strict application of MVC principles. Under OpenStep, most of the classes provided were either high-level View classes (in AppKit) or one of a number of relatively low-level model classes like NSString. Compared to similar MVC systems, OpenStep lacked a strong model layer. There was no stock class which represented a "document," for instance. During the transition to Cocoa, the model layer was expanded greatly, introducing a number of pre-rolled classes to provide functionality common to desktop applications.

In Mac OS X 10.3, Apple introduced the NSController family of classes, which provide predefined behavior for the controller layer. These classes are considered part of the Cocoa Bindings system, which also makes extensive use of protocols such as Key-Value Observing and Key-Value Binding. The term 'binding' refers to a relationship between two objects, often between a view and a controller. Bindings allow the developer to focus more on declarative relationships rather than orchestrating fine-grained behavior.

With the arrival of Mac OS X 10.4, Apple extended this foundation further by introducing the Core Data framework, which standardizes change tracking and persistence in the model layer. In effect, the framework greatly simplifies the process of making changes to application data, undoing changes (if necessary), saving data to disk, and reading it back in.

By providing framework support for all three MVC layers, Apple's goal is to reduce the amount of boilerplate or "glue" code that developers have to write, freeing up resources to spend time on application-specific features.

Main frameworks

Cocoa consists primarily of two Objective-C object libraries called frameworks. Frameworks are functionally similar to shared libraries, a compiled object that can be dynamically loaded into a program's address space at runtime, but frameworks add associated resources, header files, and documentation.

Foundation Kit, or more commonly simply Foundation, first appeared in OpenStep. On Mac OS X, it is based on Core Foundation. Foundation is a generic object-oriented library providing string and value manipulation, containers and iteration, distributed computing, run loops, and other functions that are not directly tied to the graphical user interface. The "NS" prefix, used for all classes and constants in the framework, comes from Cocoa's NeXTSTEP heritage.

Application Kit or AppKit is directly descended from the original NeXTSTEP Application Kit. It contains code with which programs can create and interact with graphical user interfaces. AppKit is built on top of Foundation, and uses the same "NS" prefix.

A key part of the Cocoa architecture is its comprehensive views model. This is organized along conventional lines for an application framework, but is based on the PDF drawing model provided by Quartz. This allows creation of custom drawing content using PostScript-like drawing commands, which also allows automatic printer support and so forth. Since the Cocoa framework manages all the clipping, scrolling, scaling and other chores of drawing graphics, the programmer is freed from implementing basic infrastructure and can concentrate only on the unique aspects of an application's content.

Memory Management concept in objective-c

•Memory Management◦Up until now I've kind of dodged memory management in Objective-C. Sure you can call dealloc on an object, but what happens if the object contains pointers to other objects? One has to be concerned about freeing the memory of those objects as well. Also how does the Foundation framework manage memory when you create classes from it? This will all be explained.

◦Note: everything up until this point has been properly memory managed, incase you're wondering.

◦Retain and Release

■Retain and release are two methods inherited from any object that has NSObject as a parent. Each object has an internal counter that can be used to keep track of the number references an object has. So if you have 3 referneces, you don't want to dealloc yourself. However once you reach 0, you should dealloc yourself. [object retain] increments the counter by 1 (which starts at 1) and [object release] decrements it by 1. If the [object release] invocation causes the count to reach 0, dealloc is then called.

■Fraction.m
...
-(void) dealloc {
printf( "Deallocing fraction\n" );
[super dealloc];
}


...■Based on an example in "Programming in Objective-C," Copyright © 2004 by Sams Publishing. Used with permission


■main.m
#import "Fraction.h"
#import

int main( int argc, const char *argv[] ) {
Fraction *frac1 = [[Fraction alloc] init];
Fraction *frac2 = [[Fraction alloc] init];

// print current counts
printf( "Fraction 1 retain count: %i\n", [frac1 retainCount] );
printf( "Fraction 2 retain count: %i\n", [frac2 retainCount] );

// increment them
[frac1 retain]; // 2
[frac1 retain]; // 3
[frac2 retain]; // 2

// print current counts
printf( "Fraction 1 retain count: %i\n", [frac1 retainCount] );
printf( "Fraction 2 retain count: %i\n", [frac2 retainCount] );

// decrement
[frac1 release]; // 2
[frac2 release]; // 1

// print current counts
printf( "Fraction 1 retain count: %i\n", [frac1 retainCount] );
printf( "Fraction 2 retain count: %i\n", [frac2 retainCount] );

// release them until they dealloc themselves
[frac1 release]; // 1
[frac1 release]; // 0
[frac2 release]; // 0
}

■output
Fraction 1 retain count: 1
Fraction 2 retain count: 1
Fraction 1 retain count: 3
Fraction 2 retain count: 2
Fraction 1 retain count: 2
Fraction 2 retain count: 1
Deallocing fraction
Deallocing fraction

■The retain calls increment the counter. The release calls decrement it. One can get the count as an int by calling [obj retainCount]. Once the retainCount reaches 0, both objects dealloc themselves and you can see this when both print out "Deallocing fraction."

◦Dealloc

■When your object contains other objects, you must free them whenever you yourself dealloc. One of the nice advantages to Objective-C is you can pass messages to nil, so there isn't a lot of error checking to release an object.

■Based on an example in "Programming in Objective-C," Copyright © 2004 by Sams Publishing. Used with permission

■AddressCard.h
#import
#import

@interface AddressCard: NSObject {
NSString *first;
NSString *last;
NSString *email;
}

-(AddressCard*) initWithFirst: (NSString*) f
last: (NSString*) l
email: (NSString*) e;
-(NSString*) first;
-(NSString*) last;
-(NSString*) email;
-(void) setFirst: (NSString*) f;
-(void) setLast: (NSString*) l;
-(void) setEmail: (NSString*) e;
-(void) setFirst: (NSString*) f
last: (NSString*) l
email: (NSString*) e;
-(void) setFirst: (NSString*) f last: (NSString*) l;
-(void) print;
@end

■AddressCard.m
#import "AddressCard.h"
#import

@implementation AddressCard
-(AddressCard*) initWithFirst: (NSString*) f
last: (NSString*) l
email: (NSString*) e {
self = [super init];

if ( self ) {
[self setFirst: f last: l email: e];
}

return self;
}

-(NSString*) first {
return first;
}

-(NSString*) last {
return last;
}

-(NSString*) email {
return email;
}

-(void) setFirst: (NSString*) f {
[f retain];
[first release];
first = f;
}

-(void) setLast: (NSString*) l {
[l retain];
[last release];
last = l;
}

-(void) setEmail: (NSString*) e {
[e retain];
[email release];
email = e;
}

-(void) setFirst: (NSString*) f
last: (NSString*) l
email: (NSString*) e {
[self setFirst: f];
[self setLast: l];
[self setEmail: e];
}

-(void) setFirst: (NSString*) f last: (NSString*) l {
[self setFirst: f];
[self setLast: l];
}

-(void) print {
printf( "%s %s <%s>", [first cString],
[last cString],
[email cString] );
}

-(void) dealloc {
[first release];
[last release];
[email release];

[super dealloc];
}
@end■main.m
#import "AddressCard.h"
#import
#import

int main( int argc, const char *argv[] ) {
NSString *first =[[NSString alloc] initWithCString: "Tom"];
NSString *last = [[NSString alloc] initWithCString: "Jones"];
NSString *email = [[NSString alloc] initWithCString: "tom@jones.com"];
AddressCard *tom = [[AddressCard alloc] initWithFirst: first
last: last
email: email];

// we're done with the strings, so we must dealloc them
[first release];
[last release];
[email release];

// print to show the retain count
printf( "Retain count: %i\n", [[tom first] retainCount] );
[tom print];
printf( "\n" );

// free memory
[tom release];

return 0;
}

■output
Retain count: 1
Tom Jones

■This example shows not only how to make a dealloc method, as shown in AddressCard.m, but one way to do member variables.

■The order of the 3 operations in each set method is very important. Lets say you'return passing a parameter of yourself to one of your methods (a bit of an odd example, but this can happen). If you release first, THEN retain you will destruct yourself! That's why you should always 1) retain 2) release 3) set the value.

■Normally one wouldn't initialize variables with C strings because they don't support unicode. The next example, with NSAutoreleasePool shows the proper way to do strings and initializing.

■This is just one way of handling member variable memory management. One way to handle this is to create copies inside your set methods.

◦Autorelease Pool

■When you want to start doing more programming using NSString and other Foundation framework classes you need a more flexible system. This system is using Autorelease pools.

■When developing Mac Cocoa applications, the auto release pool is setup automatically for you.

■Based on an example in "Programming in Objective-C," Copyright © 2004 by Sams Publishing. Used with permission

■main.m
#import
#import
#import

int main( int argc, const char *argv[] ) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
NSString *str1 = @"constant string";
NSString *str2 = [NSString stringWithString: @"string managed by the pool"];
NSString *str3 = [[NSString alloc] initWithString: @"self managed string"];

// print the strings
printf( "%s retain count: %x\n", [str1 cString], [str1 retainCount] );
printf( "%s retain count: %x\n", [str2 cString], [str2 retainCount] );
printf( "%s retain count: %x\n", [str3 cString], [str3 retainCount] );

// free memory
[str3 release];

// free pool
[pool release];
return 0;
}

■output
constant string retain count: ffffffff
string managed by the pool retain count: 1
self managed string retain count: 1

■If you run this you'll notice a few things. One is that the retainCount of str1 is ffffffff.

■The other is, I only release str3, yet this program is memory management perfect. The reason is the first constant string is added to the autorelease pool automatically. The other string is made using stringWithString. This method creates a string that is owned by NSString class, which also puts it in the auto release pool.

■It's important to remember, for proper memory management, that convience methods like [NSString stringWithString: @"String"] use autorelease pools, but alloc methods like [[NSString alloc] initWithString: @"String"] do not use autorelease pools for managing memory.

■There are two ways to manage memory in Objective-C: 1) retain and release or 2) retain and release/autorelease.

■For each retain, there must be one release OR one autorelease.

■The following example shows what I mean by this
■Based on an example in "Programming in Objective-C," Copyright © 2004 by Sams Publishing. Used with permission
■Fraction.h
...
+(Fraction*) fractionWithNumerator: (int) n denominator: (int) d;
...
■Fraction.m
...
+(Fraction*) fractionWithNumerator: (int) n denominator: (int) d {
Fraction *ret = [[Fraction alloc] initWithNumerator: n denominator: d];
[ret autorelease];

return ret;
}
...■main.m
#import
#import "Fraction.h"
#import

int main( int argc, const char *argv[] ) {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
Fraction *frac1 = [Fraction fractionWithNumerator: 2 denominator: 5];
Fraction *frac2 = [Fraction fractionWithNumerator: 1 denominator: 3];

// print frac 1
printf( "Fraction 1: " );
[frac1 print];
printf( "\n" );

// print frac 2
printf( "Fraction 2: " );
[frac2 print];
printf( "\n" );

// this causes a segmentation fault
//[frac1 release];

// release the pool and all objects in it
[pool release];
return 0;
}

■output
Fraction 1: 2/5
Fraction 2: 1/3

■In this example, the method is a class level method. After the object is created, autorelease is called on it. Inside the body of the main method, I never call release on the object.

■The reason this works is because: for every retain, one release or autorelease must be called. The object's retain count starts out as 1, and I called autorelease on it once. This means 1 - 1 = 0. Once the autorelease pool is released, it counts the autorelease calls on all objects and decrements them with [obj release] with the same number of times autorelease was called per object.

■As the comment says, uncommenting that line causes a segment fault. Since autorelease was already called on the object, calling release on it, and then releasing the autorelease pool would attempt to call dealloc on an object that is nil, which is not valid. The end math is 1 (creation) - 1 (release) - 1 (autorelease) = -1.

■Auto release pools can be dynamically created for large amounts of temporary objects. All one must do is create a pool, perform any large chunk of code that creates lots of temporary objects, then release the pool. As you may wonder, it this means it is possible to have more than one auto release pool at a time.

Memory management

One feature of the Cocoa environment is its facility for managing dynamically allocated memory. Cocoa's NSObject class, from which most classes, both vendor and user, are derived, implements a reference counting scheme for memory management. Objects derived from the NSObject root class respond to a retain and a release message and keep a retain count which can be queried by sending a retainCount message. A newly allocated object created with alloc or copy has a retain count of one. Sending that object a retain message increments the retain count, while sending it a release message decrements the retain count. When an object's retain count reaches zero, it is deallocated similar to a C++ destructor. dealloc is not guaranteed to be invoked. This reference counting approach is very similar to that of Microsoft's COM, which features the IUnknown interface. IUnknown provides equivalents to retain and release in the form of AddRef and Release.