iPhone Developer Help

Full Version: Objective-C looks so confusing
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I wish the iPhone SDK supported Java...look at this horrendous code sample:

Code:
/***

Important:

This is sample code demonstrating API, technology or techniques in development.
Although this sample code has been reviewed for technical accuracy, it is not
final. Apple is supplying this information to help you plan for the adoption of
the technologies and programming interfaces described herein. This information
is subject to change, and software implemented based on this sample code should
be tested with final operating system software and final documentation. Newer
versions of this sample code may be provided with future seeds of the API or
technology. For information about updates to this and other developer
documentation, view the New & Updated sidebars in subsequent documentation seeds.

***/

/*

File: HelloWorldClassicAppDelegate.m
Abstract: Responsible for creating the application window at launch and
managing the UI elements that appear in that window.

Version: 1.0

Disclaimer: IMPORTANT:  This Apple software is supplied to you by
Apple Inc. ("Apple") in consideration of your agreement to the
following terms, and your use, installation, modification or
redistribution of this Apple software constitutes acceptance of these
terms.  If you do not agree with these terms, please do not use,
install, modify or redistribute this Apple software.

In consideration of your agreement to abide by the following terms, and
subject to these terms, Apple grants you a personal, non-exclusive
license, under Apple's copyrights in this original Apple software (the
"Apple Software"), to use, reproduce, modify and redistribute the Apple
Software, with or without modifications, in source and/or binary forms;
provided that if you redistribute the Apple Software in its entirety and
without modifications, you must retain this notice and the following
text and disclaimers in all such redistributions of the Apple Software.
Neither the name, trademarks, service marks or logos of Apple Inc.
may be used to endorse or promote products derived from the Apple
Software without specific prior written permission from Apple.  Except
as expressly stated in this notice, no other rights or licenses, express
or implied, are granted by Apple herein, including but not limited to
any patent rights that may be infringed by your derivative works or by
other works in which the Apple Software may be incorporated.

The Apple Software is provided by Apple on an "AS IS" basis.  APPLE
MAKES NO WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION
THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE, REGARDING THE APPLE SOFTWARE OR ITS USE AND
OPERATION ALONE OR IN COMBINATION WITH YOUR PRODUCTS.

IN NO EVENT SHALL APPLE BE LIABLE FOR ANY SPECIAL, INDIRECT, INCIDENTAL
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
INTERRUPTION) ARISING IN ANY WAY OUT OF THE USE, REPRODUCTION,
MODIFICATION AND/OR DISTRIBUTION OF THE APPLE SOFTWARE, HOWEVER CAUSED
AND WHETHER UNDER THEORY OF CONTRACT, TORT (INCLUDING NEGLIGENCE),
STRICT LIABILITY OR OTHERWISE, EVEN IF APPLE HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.

Copyright (C) 2008 Apple Inc. All Rights Reserved.

*/



#import "HelloWorldClassicAppDelegate.h"

#define TEXT_FIELD_FONT_SIZE 15.0
#define BUTTON_FONT_SIZE 16.0
#define TEXT_LABEL_FONT_SIZE 30.0
#define TEXT_FIELD_HEIGHT_MULTIPLIER 2.0    // Provide some vertical space around text fields

@implementation HelloWorldClassicAppDelegate

@synthesize window;
@synthesize contentView;
@synthesize textField;
@synthesize label;

- (void)addControlsToContentView:(UIImageView *)aContentView
{    
    CGRect contentFrame = aContentView.frame;

    // Create a button using an image as the background.
    // Use the desired background image's size as the button's size
    UIImage *buttonBackground = [UIImage imageNamed:@"Button.png"];
    CGRect buttonFrame = CGRectMake(0.0, 0.0, buttonBackground.size.width, buttonBackground.size.height);
    UIButton *button = [[UIButton alloc] initWithFrame:buttonFrame];

    [button setTitle:@"Hello" forStates:UIControlStateNormal];    
    button.font = [UIFont boldSystemFontOfSize:BUTTON_FONT_SIZE];

    // Center the text on the button, considering the button's shadow
    button.contentHorizontalAlignment = UIControlContentHorizontalAlignmentCenter;
    button.contentVerticalAlignment = UIControlContentVerticalAlignmentCenter;
    button.titleEdgeInsets = UIEdgeInsetsMake(-2.0, 0.0, 2.0, 0.0);   //Create inset for the shadow below
    
    // Set the background image on the button
    [button setBackgroundImage:buttonBackground forStates:UIControlStateNormal];
    [button addTarget:self action:@selector(hello:) forControlEvents:UIControlEventTouchUpInside];  //hello: is sent when the button is touched
    
    // Position the button centered horizontally in the contentView
    button.center = CGPointMake(aContentView.center.x, aContentView.center.y-52);
    [aContentView addSubview:button];
    [button release];
    
    // Create a text field to type into
    CGFloat textFieldWidth = contentFrame.size.width * 0.72;
    // and set the origin based on centering the view
    CGFloat textFieldOriginX = (contentFrame.size.width - textFieldWidth) / 2.0;
    CGFloat leftMargin = 20.0;
    CGRect textFieldFrame = CGRectMake(textFieldOriginX, leftMargin, textFieldWidth, TEXT_FIELD_FONT_SIZE * TEXT_FIELD_HEIGHT_MULTIPLIER);
    UITextField *aTextField = [[UITextField alloc] initWithFrame:textFieldFrame];
    aTextField.borderStyle = UITextFieldBorderStyleRounded;
    aTextField.font = [UIFont systemFontOfSize:TEXT_FIELD_FONT_SIZE];
    aTextField.contentVerticalAlignment = UIControlContentVerticalAlignmentCenter;
    aTextField.placeholder = @"Your name";
    aTextField.keyboardType = UIKeyboardTypeAlphabet;
    self.textField = aTextField;
    [aTextField release];
    [aContentView addSubview: self.textField];
    
    // Create a label for greeting output. Dimensions are based on the input field sizing
    leftMargin = 90.0;
    CGRect labelFrame = CGRectMake(textFieldOriginX, leftMargin, textFieldWidth, TEXT_LABEL_FONT_SIZE * TEXT_FIELD_HEIGHT_MULTIPLIER);
    UILabel *aLabel = [[UILabel alloc] initWithFrame:labelFrame];
    aLabel.font = [UIFont systemFontOfSize:TEXT_LABEL_FONT_SIZE];
    // Create a slightly muted green color
    aLabel.textColor = [UIColor colorWithRed:0.22 green:0.54 blue:0.41 alpha:1.0];
    aLabel.textAlignment = UITextAlignmentCenter;
    self.label = aLabel;
    [aLabel release];
    [aContentView addSubview: self.label];
}

//This method is invoked when the Hello button is touched
- (void)hello:(id)sender
{
    [self.textField resignFirstResponder];
    NSString *nameString = self.textField.text;
    if ([nameString length] == 0) {    //Nothing was typed
        nameString = @"World";
    }
    NSString *greeting = [NSString stringWithFormat:@"Hello %@!", nameString];

    self.label.text = greeting;
}

- (void)dealloc
{
    [contentView release];
    [window release];
    [textField release];
    [label release];
    [super dealloc];
}

#pragma mark -
#pragma mark UIApplication delegate method

- (void)applicationDidFinishLaunching:(UIApplication *)application
{
    // Set up the window and content view
    CGRect screenRect = [[UIScreen mainScreen] bounds];
    self.window = [[[UIWindow alloc] initWithFrame:screenRect] autorelease];
    
    // Add the image as the background view
    UIImageView *anImageView = [[UIImageView alloc] initWithFrame:[[UIScreen mainScreen] applicationFrame]];
    anImageView.image = [UIImage imageNamed:@"Background.png"];
    self.contentView = anImageView;
    [anImageView release];
    [self.window addSubview: self.contentView];
    [self addControlsToContentView: self.contentView];
    
    // Show the window
    [self.window makeKeyAndVisible];
}

@end

Java would be much nicer. Objective-C is an uphill struggle because of the awkward syntax. Takes a little time before your brain is rewired to read it without a hitch.

Regarding the example -- woah, bad example. IMHO they should have created something a little bit less intense.

Good luck,
Richard
Yea I would love a iPhone Java Development.

My few complaints about Objective-C...why rewrite the way you call a method? Why do we need to use [...]. Whatever happened to just Object.method(). After a while you get used to it, but then there is Memory Management issues. What modern language requires me to deal with Memory Management?

The thing about it is that it's harder for people with no Objective-C experience, but for people who have been developing Mac OS apps for a while this is an easy transition.

Felix

richard Wrote:
Java would be much nicer. Objective-C is an uphill struggle because of the awkward syntax. Takes a little time before your brain is rewired to read it without a hitch.

Regarding the example -- woah, bad example. IMHO they should have created something a little bit less intense.

Good luck,
Richard

Objective-C 2.0 has automatic garbage collection. It's turned off by default. You can enable it in the project settings. Without garbage collection we still have the autorelease pool which I think is still pretty neat.

I'm a big fan of the bracket notation because when I see code like this:

Code:
[myColor changeColorWithRed:5 green:2 blue:6 alpha: 1];


I know what each parameter is without having to look up the documentation. This is harder to do with Java-style method calls. It's still possible, and Cocoajava used a format like this:

Code:
myColor.changeColorWithRedGreenBlueAlpha(5, 2, 6, 1);


I agree with richard that their "Hello, World" is intense. I thought the whole point of "Hello, World" was to show that a program can be executed. They would do better to make "Hello, World" without input, something along the lines of:

Code:
NSLog(@"Hello, World!");


--Jason

felixk Wrote:
Yea I would love a iPhone Java Development.

My few complaints about Objective-C...why rewrite the way you call a method? Why do we need to use [...]. Whatever happened to just Object.method(). After a while you get used to it, but then there is Memory Management issues. What modern language requires me to deal with Memory Management?

The thing about it is that it's harder for people with no Objective-C experience, but for people who have been developing Mac OS apps for a while this is an easy transition.

Felix

richard Wrote:
Java would be much nicer. Objective-C is an uphill struggle because of the awkward syntax. Takes a little time before your brain is rewired to read it without a hitch.

Regarding the example -- woah, bad example. IMHO they should have created something a little bit less intense.

Good luck,
Richard

Hi

I do agree with you now that the bracket notation is nice. After coding for a while you get used to it.

As for Garbage Collection...there is no Automatic GC for the iPhone Sad

"iPhone OS does not support memory management using the garbage collection feature that is in Mac OS X v10.5 and later."

Felix

jasonsikes Wrote:
Objective-C 2.0 has automatic garbage collection. It's turned off by default. You can enable it in the project settings. Without garbage collection we still have the autorelease pool which I think is still pretty neat.

I'm a big fan of the bracket notation because when I see code like this:

Code:
[myColor changeColorWithRed:5 green:2 blue:6 alpha: 1];


I know what each parameter is without having to look up the documentation. This is harder to do with Java-style method calls. It's still possible, and Cocoajava used a format like this:

Code:
myColor.changeColorWithRedGreenBlueAlpha(5, 2, 6, 1);


I agree with richard that their "Hello, World" is intense. I thought the whole point of "Hello, World" was to show that a program can be executed. They would do better to make "Hello, World" without input, something along the lines of:

Code:
NSLog(@"Hello, World!");


--Jason

felixk Wrote:
Yea I would love a iPhone Java Development.

My few complaints about Objective-C...why rewrite the way you call a method? Why do we need to use [...]. Whatever happened to just Object.method(). After a while you get used to it, but then there is Memory Management issues. What modern language requires me to deal with Memory Management?

The thing about it is that it's harder for people with no Objective-C experience, but for people who have been developing Mac OS apps for a while this is an easy transition.

Felix

richard Wrote:
Java would be much nicer. Objective-C is an uphill struggle because of the awkward syntax. Takes a little time before your brain is rewired to read it without a hitch.

Regarding the example -- woah, bad example. IMHO they should have created something a little bit less intense.

Good luck,
Richard

Hi!

Indeed there is no automatic garbage collection, but we still have semiautomatic GC. You have to know when to use retain and release, and when you're making temporary objects you don't need to use retain or release at all.

I have been using semiautomatic GC for so long that the iPhone's lack of it is a nonissue for me. It's actually quite easy once you get the hang of it. Cocoa has these three rules:

  1. Every retain needs a release.
  2. Every object created with some form of init (e.g. [NSString initWithString:] ) has a built-in retain and needs a release.
  3. Objects created any other way (e.g. [NSString stringWithString:] ) do not need a release.


I agree that it's a lot easier to write applications when you don't have to spend as much time worrying about the underlying mechanics, but in the big scheme of things, I consider the lack of automatic GC to be small. But I'm weird; I consider the lack of namespaces to be a plus. Tongue

I don't think the GC limitation will last on the iPhone. I imagine somebody at Apple said, "Having automatic GC will cost us performance-wise; let's leave it out." But most of us programmers will keep asking for it until they relent. Also, Android having automatic GC may help our cause.

Having said that, though, I still think it's easier to develop applications using Cocoa than it is using Java, even when you take the GC issue into consideration. (For the record, I base my opinion on having taken one Java class, and running about halfway through a J2EE book. My Java experience is by no means comprehensive.)

--Jason

felixk Wrote:
Hi

I do agree with you now that the bracket notation is nice. After coding for a while you get used to it.

As for Garbage Collection...there is no Automatic GC for the iPhone Sad

"iPhone OS does not support memory management using the garbage collection feature that is in Mac OS X v10.5 and later."

Felix

Hey Jason,

Thanks for that information, that was very helpful.

It's not a huge deal to me that GC isn't available. It's just sometimes I forget to clean up because I come from a Java background. I've done a lot of J2ME and J2EE work and I never have to think about memory management.

I'm sure with a little more time with Objective-C it will become second nature.

I assume you come from a Mac OS X development background? I envy you because most of the Apps you've written for Mac OS X can be somewhat easily ported to an iPhone seeing how most of the code will remain the same.

Have you developed anything interesting for the iPhone yet?

Felix

jasonsikes Wrote:
Hi!

Indeed there is no automatic garbage collection, but we still have semiautomatic GC. You have to know when to use retain and release, and when you're making temporary objects you don't need to use retain or release at all.

I have been using semiautomatic GC for so long that the iPhone's lack of it is a nonissue for me. It's actually quite easy once you get the hang of it. Cocoa has these three rules:

  1. Every retain needs a release.
  2. Every object created with some form of init (e.g. [NSString initWithString:] ) has a built-in retain and needs a release.
  3. Objects created any other way (e.g. [NSString stringWithString:] ) do not need a release.


I agree that it's a lot easier to write applications when you don't have to spend as much time worrying about the underlying mechanics, but in the big scheme of things, I consider the lack of automatic GC to be small. But I'm weird; I consider the lack of namespaces to be a plus. Tongue

I don't think the GC limitation will last on the iPhone. I imagine somebody at Apple said, "Having automatic GC will cost us performance-wise; let's leave it out." But most of us programmers will keep asking for it until they relent. Also, Android having automatic GC may help our cause.

Having said that, though, I still think it's easier to develop applications using Cocoa than it is using Java, even when you take the GC issue into consideration. (For the record, I base my opinion on having taken one Java class, and running about halfway through a J2EE book. My Java experience is by no means comprehensive.)

--Jason

felixk Wrote:
Hi

I do agree with you now that the bracket notation is nice. After coding for a while you get used to it.

As for Garbage Collection...there is no Automatic GC for the iPhone Sad

"iPhone OS does not support memory management using the garbage collection feature that is in Mac OS X v10.5 and later."

Felix

I personally can barely stand ObjectiveC. I find it hard to read, ugly, and massively repetitive.

1) Memory management is LAME! I understand memory management. That doesn't mean I'm even remotely interested in doing it. Yes ObjectiveC has GC, in MacOS, but not on the iPhone, making it irrelevant for me in concluding that ObjectiveC was a poor language choice for the phone. And while I'm not necessarily hindered by not knowing memory management, there will be hundreds and hundreds of developers out there from the interpreted language world who don't know it, leading to crappy code. I expect memory errors will become as commonplace amongst 3rd party apps as bluescreens on a Windows ME box running AOL. This has been my experience with SDK so far...if I leave a memory error in there, it hangs my entire system.

2) Bracket syntax is lame. It is hard to read. It is hard to write. I'm REALLY used to object.method(param1, param2). That makes sense. Every other language has this. Even object.method(param1:value1, param2:value2) would have been a better syntax. But [object methodParam1:value1 param2:value2] makes little sense, and does nothing but confuse me.

3) On the subject of bracket syntax. Why must I repetatively type in my parameter names? This is MASSIVELY annoying. When I read code, parameter names ought to be relatively obvious (I shy away from ever using more than 2 or 3 params). If they are not, I have Jump to definition, which even XCode has. In Visual Studio (the absolute best IDE I've ever used), I can simply mouse over a param to read its name, as well as a description left by its author. Thus I have full code readability, with no added cost. Would have been a much better way to address this problem (and would save many, many cases of carpal tunnel).

4) Preprocessor should be banned. It is only occasionally useful for things like multi-platform conditional compilation. Encoding constants with it should be a sin. See Scott Meyers' Effective C++.

5) C based stuff is going to scare the majority of the web-centric crowd away. Lots of otherwise good ideas will not be attempted due to the high starting cost of moving into such a complex space.

Another problem makes this even harder:

Apple's documentation is the pits! THE PITS! Some of their code in their documentation does not compile...and not because it is out of date, but because it is actually not valid code. It is difficult to navigate (though admittedly, I have not found a documentation set (with the possible exception of Rails' documentation) which is better...MSDN for comparison is just as much of a mess), and assumes a lot. No troubleshooting or common pitfalls are provided, and what few examples there are are sparse, poorly done, not well explained, and often do not adhere to Apple's own style guidelines. Admittedly you all are trying to help this problem, and I will try to answer questions I can as I discover the answers myself, but no community forum can ever take the place of good vendor docs.

A considerably better choice would have been Java, though Apple is arguably right in avoiding it at all costs-java itself has plenty of language issues, and anything to do with Sun should be regarded as working with the devil.

But there are other, better choices as well. I for one would have suggested Ruby, which is clean, elegant, and simple to understand. True C++ would have worked, but would have been a harder solution for everybody.

Farther out, but potentially more interesting would have been emerging but yet unexplored languages. My personal suggestion in this category is D, which looks interesting (a cleaned up version of C++), but has never been seriously adopted. Also neat would be ISO C# (I am a C#.Net programmer, so I will freely admit to bias), though I can understand why Apple would avoid that.

Anyways, we are stuck with what we are stuck with. Apple has never been a company to go too far outside of the box (they are great, of course, at refining ideas already in the box), and so it's no surprise that they don't this time. If they could just clean up their docs and get some better samples, we'd all be in a much better position!

And now it's off to figure out why MySQL still will not run correctly on this Mac...why is this so much harder than on my Windows box? OSX was supposed to 'Just Work'?

AbstractApproach Wrote:
I personally can barely stand ObjectiveC. I find it hard to read, ugly, and massively repetitive.


I don't know about repetitive. It certainly is verbose.

I don't find it hard to read or ugly at all. YMMCertainlyV.

AbstractApproach Wrote:
1) Memory management is LAME! I understand memory management. That doesn't mean I'm even remotely interested in doing it. Yes ObjectiveC has GC, in MacOS, but not on the iPhone, making it irrelevant for me in concluding that ObjectiveC was a poor language choice for the phone. And while I'm not necessarily hindered by not knowing memory management, there will be hundreds and hundreds of developers out there from the interpreted language world who don't know it, leading to crappy code. I expect memory errors will become as commonplace amongst 3rd party apps as bluescreens on a Windows ME box running AOL. This has been my experience with SDK so far...if I leave a memory error in there, it hangs my entire system.


I honestly wish that Apple include a higher level scripting language in the iPhone, preferably Ruby or Python. For some programmers memory management is second nature. For others it can be a source of annoyance.

AbstractApproach Wrote:
2) Bracket syntax is lame. It is hard to read. It is hard to write. I'm REALLY used to object.method(param1, param2). That makes sense. Every other language has this. Even object.method(param1:value1, param2:value2) would have been a better syntax. But [object methodParam1:value1 param2:value2] makes little sense, and does nothing but confuse me.


The Objective-C way of method calls makes more sense to me. Consider that the Objective-C language (just the language, mind you) takes half of a day to learn, like Java. Now supposing you've learned the language and you are now reading someone else's code you come across a method call like this:

Code:
myColor.changeColor(5,2,6,1);

Just from reading the context you know what 'myColor' is, and you know that 'changeColor' means we are changing the color, but what does the '5,2,6,1' mean? You can look it up in the documentation, but that takes time and it interrupts your flow.

Here's the same thing in Objective-C:

Code:
[myColor changeColorWithRed:5 green:2 blue:6 alpha: 1];

To be honest I think it's still a little hard to read. I prefer to see Objective-C code like this:

Code:
[myColor changeColorWithRed: 5
                      green: 2
                       blue: 6
                      alpha: 1];

I often see a mix of the two styles. But I digress. My point is that now you know what the parameters mean without resorting to the documentation.

AbstractApproach Wrote:
3) On the subject of bracket syntax. Why must I repetatively type in my parameter names? This is MASSIVELY annoying. When I read code, parameter names ought to be relatively obvious (I shy away from ever using more than 2 or 3 params). If they are not, I have Jump to definition, which even XCode has. In Visual Studio (the absolute best IDE I've ever used), I can simply mouse over a param to read its name, as well as a description left by its author. Thus I have full code readability, with no added cost. Would have been a much better way to address this problem (and would save many, many cases of carpal tunnel).

a) parameter names: see above
b) Jump to definition, while necessary sometimes, interrupts your flow when your reading. (I've been on a "don't interrupt my flow" crusade lately. Liberal use of Jump to Definition is like reading something that says "see page 112" and on page 112: "see page 434" page 434: "see pages 112 and Chapter 31".) It's nice to see a method call and know what it means without having to resort to reading its definition. This is what self-documenting code is all about.
c) I've heard many good things about the latest version of Visual Studio from Windows programmer friends who had gripes about the previous versions. I still prefer my code to be self-documenting.
d) I don't think a little verbosity is going to cause anyone carpel tunnel. You and I are more likely to get carpel tunnel from these long-winded posts. Big Grin

AbstractApproach Wrote:
4) Preprocessor should be banned. It is only occasionally useful for things like multi-platform conditional compilation. Encoding constants with it should be a sin. See Scott Meyers' Effective C++.

Meyers and Stroustrup have several issues with #define. Using it to create an inline function can be bad; I never do this. Using it to define a constant is only bad if the compiler reports an error at a line where the constant is used. Since the line numbers are reported with the error and I know what a preprocessor does, this is not an issue for me.
As long as we are griping about the C preprocessor, however, I would prefer using the import style that we see in just about every other language, but since Objective-C and C++ are supersets of C we are bound to C's convention of using #include and linking.

AbstractApproach Wrote:
5) C based stuff is going to scare the majority of the web-centric crowd away. Lots of otherwise good ideas will not be attempted due to the high starting cost of moving into such a complex space.

C is not that complex. If you understand C# then you already know all kinds of things that directly translate to C. For those who want to stay web-centric, they already have the tools to write iPhone web apps. Otherwise, if someone has a good idea for an iPhone native app then they can learn Cocoa/Objective-C or hire someone who knows.

AbstractApproach Wrote:
Another problem makes this even harder:

Apple's documentation is the pits! THE PITS! Some of their code in their documentation does not compile...and not because it is out of date, but because it is actually not valid code.

Oh. Kay.
I have not had that problem. I have seen sample code give warnings because methods have been deprecated. Aside from that Apple's documentation is not that good for absolute beginners (see below).

AbstractApproach Wrote:
It is difficult to navigate (though admittedly, I have not found a documentation set (with the possible exception of Rails' documentation) which is better...MSDN for comparison is just as much of a mess), and assumes a lot. No troubleshooting or common pitfalls are provided, and what few examples there are are sparse, poorly done, not well explained, and often do not adhere to Apple's own style guidelines. Admittedly you all are trying to help this problem, and I will try to answer questions I can as I discover the answers myself, but no community forum can ever take the place of good vendor docs.

I've never used C#, but I believe that if you already understand C#, then you know enough to understand Cocoa Programming for Mac OS X by Aaron Hillegass. If you want to learn Cocoa, do this before you look at any of Apple's documentation. There are Cocoa books for beginners endorsed by Apple; avoid them. Do everything in the Hillegass book, including the challenges. Then, when you've finished, do all of the challenges again. After that you will be ready for Apple's documentation, and you will see that it isn't that confusing.

Write your own small programs. My favorite when I'm learning a new language is to write a number-guessing game.

AbstractApproach Wrote:
A considerably better choice would have been Java, though Apple is arguably right in avoiding it at all costs-java itself has plenty of language issues, and anything to do with Sun should be regarded as working with the devil.

Agreed. I once wrote a number-guessing game for Java. It took me 20 lines of code, and (I think) I had to use 3 or 4 classes just to get a number from the user.
After that I lost interest in Java.

AbstractApproach Wrote:
But there are other, better choices as well. I for one would have suggested Ruby, which is clean, elegant, and simple to understand. True C++ would have worked, but would have been a harder solution for everybody.

Cocoa needs Objective-C. If you really wanted C++ then I believe you can use Objective-C++. (You'd still need some Objective-C methods and method calls, though.)
There is Cocoa-Ruby and Cocoa-Python available on OSX. Maybe we can get Apple to make one or both of those available for the iPhone.

AbstractApproach Wrote:
Farther out, but potentially more interesting would have been emerging but yet unexplored languages. My personal suggestion in this category is D, which looks interesting (a cleaned up version of C++), but has never been seriously adopted. Also neat would be ISO C# (I am a C#.Net programmer, so I will freely admit to bias), though I can understand why Apple would avoid that.

D will become more adopted over time. I don't know if it will completely overtake C++.
The only way, I think, that we'll see Cocoa for C# or D is if Apple does the same thing it did with C++. We'd have Objective-C# or Objective-D. Considering how long it took Apple to give us Objective-C++ I'd say that Objective-C# and Objective-D are far in the future.

AbstractApproach Wrote:
Anyways, we are stuck with what we are stuck with. Apple has never been a company to go too far outside of the box (they are great, of course, at refining ideas already in the box), and so it's no surprise that they don't this time. If they could just clean up their docs and get some better samples, we'd all be in a much better position!

And now it's off to figure out why MySQL still will not run correctly on this Mac...why is this so much harder than on my Windows box? OSX was supposed to 'Just Work'?

A recent release of the MySQL installer for OS X has something broken in the startup script. (By the way, if you develop MySQL or the MySQL for OS X Installation package, I love you.) I installed it on my machine, but the startup control panel widget doesn't work right. Every version I've installed before has worked just fine. I haven't downloaded the latest, yet, to see if it's fixed because I'm OK with running safe_mysqld on the command line and I'm only using it in my dev environment.

Otherwise, MySQL on OS X usually "just works".

felixk Wrote:
Hey Jason,

Thanks for that information, that was very helpful.

It's not a huge deal to me that GC isn't available. It's just sometimes I forget to clean up because I come from a Java background. I've done a lot of J2ME and J2EE work and I never have to think about memory management.

I'm sure with a little more time with Objective-C it will become second nature.

I assume you come from a Mac OS X development background? I envy you because most of the Apps you've written for Mac OS X can be somewhat easily ported to an iPhone seeing how most of the code will remain the same.

Have you developed anything interesting for the iPhone yet?

Felix

Hi, Felix.
First off. Sorry that it took me so long to reply. I signed up for the email notification on this thread, and then gmail though it was spam. When I rescued it from my spam folder it was so far down my list of new mail that it got lost.

I haven't written anything for the iPhone, yet. Right now I'm working on a ham radio application for OS X that I will port to the iPhone when I get it finished on the OS X side. I don't think it will be interesting to anyone outside of the ham community.

My experience in Objective-C and Cocoa started when I was working in biology. In academia you can use whatever tools are at your disposal. OS X had just come out, and I had heard good things about Objective-C. So I learned and used Cocoa for a few things. (I also used Perl because there was BioPerl and because there were other biologists who had very little programming background.)

As far as I can tell from my limited experience with Java, it is similar to Objective-C (once you get past the syntax).

Pages: 1 2
Reference URL's