Sample Code is always welcome. Better: ADP
Sample Code is always welcome. Better: ADP
- Subject: Sample Code is always welcome. Better: ADP
- From: Lorenzo <email@hidden>
- Date: Fri, 23 May 2003 19:27:24 +0200
Hi Chris,
yes, you are right, and today I found the time to speak about this matter.
Sometimes I feel that there should be a shortest and more elegant way to
write code. The problem is to found the *way" to the information. I know, a
person working in the *informatic* environment should never say that his
problem is to find the *information*.
I use to read the documentation, and in some cases it is very easy to
understand and it covers all the questions a developer can do to himself
about the new APIs. Sometimes, I have to say, it's very hard to understand
how a new technology works. Sometimes a given API has no sense if not
connected to a different API of a different framework. So a developer cannot
understand the meaning of the API if there is not sample code explaining the
use of the API.
I would like to say that Apple engineers made a great job with Cocoaa,
Project Builder and Interface Builder. They semplify the life 10, 20, 30
times (!) than the old frameworks and tools... What I would like to find
more within the documentation is:
*** Sample Code, massive and complete sample code ****
More than the link to the Framework, Classes, Parent Classes, I think it
should be *fantastic* if *EACH* API could be accomplished with a link to
several and complete (with .m and .h and .nib files) samples code explaining
the "interaction between the current API and other APIs". And the samples
code should be leveled progressively. I think you too sometimes found poor
sample code or heavy sample code. For a new in facts, understanding heavy
sample code is a nightmare, a great loss of time.
Another good idea could be a *sample code bank* for ADC members, where every
ADC member Cocoa user can put his samples in. The current ADC Cocoa sample
code bank is not so full of samples code...
Another idea could be a database within Project Builder like:
To do this? Do this! e.g.
The developer writes: "Mount Volume" - Return.
PB replies with a list of APIs and link to samples code like:
To mount an afp remote volume you should do this
To mount a smb remote volume you should do this
To mount a webdav remote volume you should do this
To mount a locale volume you should do this
To mount a diskImage volume you should do this...
And subcases like:
You can retrive the volume information in order to use them later
to mount the volume, this way... 1, 2, 3... samples code
If you want to use a password follow these rules...
And last: Warning to the following cases! They can cause crashes:
If you try to mount a volume without FTP connection...
so you should Ping the remote address this way...
------------------------------
I think that any good software/harware/tool should be always accomplished by
a complete user manual... (elementary and always working concept).
And I would pay money to get such a support tool like this. I should call
this tool "ADP", that is: Apple Developer's Paradise.
More than the WYSIWYG it should be WYNIWYG. "N" means "Need".
Currently any developer new on a given matter should discover it all by
himself, spending time discovering bugs, traps, collecting the info he needs
from many various sources like ADC web site, mamasam, this list, friends,
google, university archives,... and try, try, try.
Just to be clear enough,
what I am not requiring here is Apple writes my code instead of doing that
by myself(.) And I am sure that very soon Apple will pay more attention to
this matter. They use to improve everything every time...
Best Regards
--
Lorenzo
email: email@hidden
>
Date: Thu, 22 May 2003 17:56:25 -0400
>
Subject: Re: objectForKey crashes for string formats
>
From: Chris Hanson <email@hidden>
>
To: email@hidden
>
>
On Thursday, May 22, 2003, at 03:22 PM, Lorenzo wrote:
>
> Instead this is so short... Fine, very very fine.
>
>
One of the cool things about Cocoa: Generally, if you find you're
>
writing a lot of code and beating your head against a wall to solve a
>
problem, there's another way that's fast and elegant to do it.
>
>
This isn't the case with all problems, unfortunately (like my problem
>
isolating input from a keyboard-simulating USB device from actual
>
keyboard input) but it's a useful heuristic. If nothing else, you
>
could wind up spending a couple hours reading documentation that will
>
wind up being useful on another project down the line, or for answering
>
others' questions.
>
>
-- Chris
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.