macOS OSX Application Development (inspired by learning language thread)

[iancapable]

After reading the thread on learning a new language (either Java or C++), I have an interesting question...

Although I already program in all major languages, I was wondering if it would be worthwhile learning Object-C and writing apps with that? Or is it better to write OSX apps with Java? Or another language of your suggestion.

 

[bousozoku]

It's called Objective-C and it's very worthwhile to learn. It's derived idealistically from Smalltalk, another good language to learn.

If you're trying to develop just for Mac OS X, use Objective-C. If you have some idea about wanting users on other operating systems use your application, use Java or code it in C++ in a way that layers the calls to the operating system so that you can make the application more portable.

The great thing about Java is that you don't have to learn a separate group of calls for each operating system. Objective-C, on Mac OS X, has Cocoa, and it's a great application framework. There is a lot of inbuilt behaviour that makes it worthwhile to learn and makes your application open to a lot of what Mac OS X offers without a lot of extra work. The only real drawback is that it's not very portable.

 

[iancapable]

It's called Objective-C and it's very worthwhile to learn. It's derived idealistically from Smalltalk, another good language to learn.

If you're trying to develop just for Mac OS X, use Objective-C. If you have some idea about wanting users on other operating systems use your application, use Java or code it in C++ in a way that layers the calls to the operating system so that you can make the application more portable.

The great thing about Java is that you don't have to learn a separate group of calls for each operating system. Objective-C, on Mac OS X, has Cocoa, and it's a great application framework. There is a lot of inbuilt behaviour that makes it worthwhile to learn and makes your application open to a lot of what Mac OS X offers without a lot of extra work. The only real drawback is that it's not very portable.

LOL sorry about the typo, I did actually mean to type objective-c...

Yes portability is somewhat an issue, but I'm not that bothered as I think I may just stick to OSX. However the only thing that concerns me is the speed of which I can write a program.

Ho-Hum I will take a looksee anyway, have xcode so will see what I can come up with.

 

[robbieduncan]

Once you get your head around Objective-C and the Cocoa frameworks it's one of the most productive development environments out there. One man shops can produce amazing apps in a reasonably short amount of time.

My take on this is that if you want to write OSX native software then learn Obj-C/Cocoa. Don't bother with the Java bridge, it's not getting updated...

 

[Nuc]

Can someone suggest good books for Objective-C and Cocoa? I'm also interested as well.

Thanks,

Nuc

 

[Nutter]

I'd recommend starting with Steve Kochan's Programming in Objective-C, an excellent book for learning the language with little or no prior experience of C:
http://www.amazon.com/Programming-Objective-C-Stephen-Kochan/dp/0672325861

For Cocoa, Aaron Hillegass's Cocoa Programming is pretty good:
http://www.amazon.com/Cocoa-Program..._bbs_sr_1/105-6017956-5957240?ie=UTF8&s=books

I taught myself solely be reading through those two books, in that order - I'm hardly an expert now, but I know enough to be able to learn the rest as I go along, if that makes sense.

 

[HiRez]

Agree woth Nutter, those two books will give you all the foundation you need. There are other books on Cocoa that are OK but Hillegass is by far the best intro book IMO. Cocoa Programming by Scott Anguish et al. is an excellent Cocoa reference book, however it is somewhat out of date now. Still useful to have on your shelf though. Other than those you can just stick with the Apple online documentation. If you want to skip the Kochan book on Objective-C, you can get most of what you need by Apple's Objective-C PDF (but I still recommend going through the book). There's quite a bit online including documentation, sample code, and tutorials for a bunch of stuff.

 

[mduser63]

I'll add a third recommendation for the books Nutter suggested. I went through them earlier this year, and I'm close to releasing (a beta of) my first relatively complex Mac app. I didn't have much programming experience before going through those books, and I still feel like I can whip together a Cocoa app pretty quickly. NeXT was popular in certain markets precisely because NeXTStep was really good for quick development. As you may know, Cocoa is really just the current version of NeXTStep (hence the NS in front of all the built-in Cocoa classes).

 

[macfreek57]

also, as I understand it, OS X programs written in Objective-C should typically run faster and more efficiently than OS X programs written in Java (unless maybe you don't know what you are doing with memory management). Like Apple always illustrates with those layered diagrams of the operating system (with Darwin at the bottom), Java operates at the very top layer, needing to "interface" it's way down to execute. Java programs need the OS X JVM to interface with OS frameworks, whereas Objective-C programs can access them directly.
I think. Isn't that about how it works?

 

[bousozoku]

also, as I understand it, OS X programs written in Objective-C should typically run faster and more efficiently than OS X programs written in Java (unless maybe you don't know what you are doing with memory management). Like Apple always illustrates with those layered diagrams of the operating system (with Darwin at the bottom), Java operates at the very top layer, needing to "interface" it's way down to execute. Java programs need the OS X JVM to interface with OS frameworks, whereas Objective-C programs can access them directly.
I think. Isn't that about how it works?

It's pretty much that way.

Java applications can be very speedy and Apple has worked hard to integrate them into Mac OS X. Of course, any native code should run faster than byte code that has to be interpreted to run.

Considering that most interactive applications are waiting for user input a lot, I'm not sure it matters so much but it's obvious with certain applications that they're extremely responsive.

Java applications are at the mercy of the JVM and even the most responsive applications can momentarily stall while waiting for some portion of the JVM to load to execute the code. If you're short on free memory, you might end up waiting longer than with a native code application.

The only trouble with native applications is that the Apple-supplied compilers really aren't commercial quality.

 

[jhande]

I'd recommend starting with Steve Kochan's Programming in Objective-C, an excellent book for learning the language with little or no prior experience of C:
http://www.amazon.com/Programming-Objective-C-Stephen-Kochan/dp/0672325861

For Cocoa, Aaron Hillegass's Cocoa Programming is pretty good:
http://www.amazon.com/Cocoa-Program..._bbs_sr_1/105-6017956-5957240?ie=UTF8&s=books

Ditto on both books. I actually took delivery of them last week, and coming from a procedural background, Kochan's is especially helpful. I would recommend reading in the order Nutter listed, and do all the exercises.

However, with Kochan's book, make sure you read the errata and notes on his site. Some of the errors threw me a bit.

 

[bronxbomber92]

Also, about the issue with portablility, you can use GNUStep for the Linux environment. There's a short chapter at the end of Cocoa Pogramming. It says that it is qute hassle though, so... It's your choice

http://www.gnustep.org/

 

[Cromulent]

Also, about the issue with portablility, you can use GNUStep for the Linux environment. There's a short chapter at the end of Cocoa Pogramming. It says that it is qute hassle though, so... It's your choice

http://www.gnustep.org/

Clarification on the chapter in the book : http://www.gnustep.org/resources/BookClarifications.html

 

[Nutter]

However, with Kochan's book, make sure you read the errata and notes on his site. Some of the errors threw me a bit.

Also, in the Hillegass book, Chapters 27 and 30 (covering Interface Builder Palettes and frameworks) have been rendered obsolete by recent versions of XCode and Interface Builder. An updated version of this material can be found here.

With regards to Java, it's important not to confuse the Java Cocoa API with pure Java run using the JVM. Java Cocoa is much the same as Objective-C Cocoa, although I suppose it might be slower, and as has been said it's all but deprecated these days. (Anyone using it??)

Pure Java is a lot different, and definitely a lot slower, if it's a fair comparison. I suppose the "V" in "JVM" is there for a reason...

 

[Nutter]

The only trouble with native applications is that the Apple-supplied compilers really aren't commercial quality.

What makes you say that? I thought GCC was supposed to be quite good. Why would Apple be using a sub-par compiler, given that it's used to compile most of the OS?

 

[bousozoku]

What makes you say that? I thought GCC was supposed to be quite good. Why would Apple be using a sub-par compiler, given that it's used to compile most of the OS?

Apple's gcc stands alone, in many ways, because they don't cooperate with the rest of the groups that contribute to gcc. I would say from experience that Borland and Metrowerks both have better production compilers for C and C++.

The Metrowerks Objective-C compiler was in its infancy when Apple transitioned to Intel but it was probably as good as Apple's version of the gcc Objective-C compiler is now, simply because Metrowerks is extremely good at code generation.

Apple is using gcc because, like many things in Mac OS X, they take what's free and use it to further their cause. They had their own, very fast compilers for C and C++ prior to buying NeXT so they know how to build good compilers but it's cheaper this way.

 

[iancapable]

It's pretty much that way.
Java applications can be very speedy and Apple has worked hard to integrate them into Mac OS X. Of course, any native code should run faster than byte code that has to be interpreted to run.

This is not very accurate. Java is not an interpreted language, it is a managed language which is based on bytecode that is converted to native machine code "Just In Time" using a special JIT (Just In Time) compiler built into the JVM.

The JVM gives you a huge amount of flexibility as you can compile java code into byte code on the fly and do some other cool tricks.

Java is not by any means slow these days. Sure it may take a fraction longer to start up than a native app... But once running I have written programs that are faster than many C++ apps I write (and I'm a performance based developer, so I know how to optimize my C++).

Otherwise you are right in the point that Java would have a hard time competing with a native OSX application due to the native stuff having good integration with Cocoa. However Java has the benifit of being 100% cross platform and you can hit two birds with one stone as the saying goes!

 

[bousozoku]

This is not very accurate. Java is not an interpreted language, it is a managed language which is based on bytecode that is converted to native machine code "Just In Time" using a special JIT (Just In Time) compiler built into the JVM.

The JVM gives you a huge amount of flexibility as you can compile java code into byte code on the fly and do some other cool tricks.

Java is not by any means slow these days. Sure it may take a fraction longer to start up than a native app... But once running I have written programs that are faster than many C++ apps I write (and I'm a performance based developer, so I know how to optimize my C++).

Otherwise you are right in the point that Java would have a hard time competing with a native OSX application due to the native stuff having good integration with Cocoa. However Java has the benifit of being 100% cross platform and you can hit two birds with one stone as the saying goes!

Sure, and it also doesn't allow the use of pointers. It's all in the semantics. Call it what you want, but the code is translated in order to be useful.

I have several Java applications and, if you have nothing else running and sufficient memory, things are more than reasonably fast. If you have other things running and/or not enough RAM, things become less than reasonable for the Java applications. The JVM takes a lot of memory and frequently ends up requesting a lot of the virtual memory system. I really believe in the Java only type of machine because the JVM is at its best then.

 

[iancapable]

Sure, and it also doesn't allow the use of pointers. It's all in the semantics. Call it what you want, but the code is translated in order to be useful.

I have several Java applications and, if you have nothing else running and sufficient memory, things are more than reasonably fast. If you have other things running and/or not enough RAM, things become less than reasonable for the Java applications. The JVM takes a lot of memory and frequently ends up requesting a lot of the virtual memory system. I really believe in the Java only type of machine because the JVM is at its best then.

You can fine tune your JVM so that the memory management is much better... However I agree that the JVM does use too much memory! Hopefully now that Java is GPL we'll be able to use GCJ for all our apps (considering GCJ can convert non-native java apps to native java apps without need for source code).

 

[bousozoku]

You can fine tune your JVM so that the memory management is much better... However I agree that the JVM does use too much memory! Hopefully now that Java is GPL we'll be able to use GCJ for all our apps (considering GCJ can convert non-native java apps to native java apps without need for source code).

I've used native code compilers in the early days of Java and they certainly provided a boost. Of course, you get into the other side where it's no longer portable and that's a discussion that's best left alone. Of course, you wouldn't need source code since the byte code is practically source code anyway. Semantics.

 

[iancapable]

I've used native code compilers in the early days of Java and they certainly provided a boost. Of course, you get into the other side where it's no longer portable and that's a discussion that's best left alone. Of course, you wouldn't need source code since the byte code is practically source code anyway. Semantics.

Well cross platform can be maintained the same way as a c++ program. Just compile it on each architecture you want to support

Anyway that's moot! I'll give Obj-C a try soon enough!

 

[Willis]

I've made a number generator from the cocoa programming book, and as I was playing around, I was able to change the "__MyCompanyName__" section and the menus from saying "New application" to "RandomApp". Only thing is though, when I compile for release, it goes back to the default.

Is there a proper way to doing this? bit stuck really. Im just playing at the moment so I have an understanding how things work.

 

[slooksterPSV]

I also recommend the books Nutter recommended. I bought those to learn OS X programming and I went through them easy and fast. Objective-C is awesome when working with classes because:
1 - you don't have public variables only private
2 - you can only access private variables through a getter function
3 - you have to have a setter function to set the variable properties... can I post code? YAY!

#import <stdio.h>
#import <Foundation/NSString.h>
#import <Foundation/NSAutoreleasePool.h>

@interface NSObject : Square
{
 float width;
 float height;
 NSString *name;
}
-(void) setWidth:(float);
-(void) setHeight:(float);
-(void) setName:(NSString *);
-(float) getWidth;
-(float) getHeight;
-(NSString *)getName;
@end

@implementation Square
-(void)setWidth:(float)x
{
 width = x;
}

-(void)setHeight:(float)y
{
 height = y;
}

-(void)setName:(NSString *)nm
{
 nm = [nm copy];
 [name release];
 name = nm;
}

-(float)getWidth
{
 return width;
}

-(float)getHeight
{
 return height;
}

-(NSString *)getName
{
 return name;
}
@end

int main()
{
 NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
 Square *sq;
 [sq setWidth:10.0];
 [sq setHeight:5.3];
 [sq setName:@"Rectangle"];
 NSLog(@"%@'s width is %.2f and height is %.2f.\n", [sq getName], [sq getWidth], [sq getHeight]);
 [pool release];
 return 0;
}

The output would be:

[some information here] - Rectangle's width is 10 and height is 5.3.
|

The | at the end is a cursor.

Now that may be an impractical use, but that's a start, there's a lot in that app that the book won't cover till chapter 23 I think, but its awesome. See how I had to access the values of the class and set them? Don't worry what I did with the NSString * you'll learn that soon enough when you get the books.