Application Development Part 2: Let there be light!

Okay, so 12 days since my last post on this and sporadically working on the CD burning functionality of our application and finally, breakthroughs are coming. Not so much breakthroughs in functionality, but breakthroughs in understanding application programming.

Over the past 12 days I have read through the basics of C, which are really similar to other scripting languages such as JavaScript and ActionScript...

Now, I know some people would give me hell, but I mean similar as in loops, variables, if statements, functions, switch cases, arrays, and some other basics. Things I assume are the same in all languages.

... and I've been going through page after page of Apple documentation, on a post later we will talk about how this documentation is not meant to help newbies, on different standard functions, DRDevice class and framework, and Objective-C standards. Up until Monday night, nothing was working or making sense. But on Monday night I found one of the key differences between Application programming and the other programming I've done. Frameworks!!!

Those logical bastards! So it seems that not only do you have to define what framework classes you need in your document, but you have to attach them to your project so they get compiled. Who would of thought? Not me, but Chris did. Of course.

So to recap, let's cover some of the biggest differences between application and web programming. *All this relates to working with xCode.

1) Frameworks!
All standard, non-custom, functions you use in a language are stored in a framework that much be called at top of your document and attached to your project file. This is a very robust feature of app dev that allows you to develop, purchase, or use free frameworks to do things to be used continuously throughout the application. Saving programming time, program size, and just do things that you don't know how to program.

2) The H and M files
Okay, so in application development, it's recommended to do no major functionality in your H file, but rather put it all in your M file that you then must include your H file into.

#import "AppControl.h"

3) Declaring your classes/functions.
So now you have two files, what does the H file do? It declares all the functions of that M file so when the app goes to be compiled it knows how to allocate resources. So if I'm going to have a function:

-(float)returnConvert:(int)value1:(int)value2
{
float math;
math = value1 * value2;
return math;
}

I have to declare it in my H file first:

-(float)returnConvert:(int)value1:(int)value2;

4) Declaring how to talk to your interface
The H file also declares all your outlets and actions between your interface and functions. These are very useful. One simple line of code creates a variable for talking to your interface element. Other then that, you can't just talk to your element for it will not know the name of the element you want to talk to. So the real thing it does is creates a variable instance with a unique name so you can send commands to the one element of that name.

5) Thoughtful programming
Everything must be thought out when you develop an application. There are very little opportunities to do things on the fly when you're deep into the functionality. If you do not declare your variable properly, your app will shutdown or just suck all your computer's resources until the computer crashes.

6) Interacting with the interface
Each interface element, NSTextField, has it's outlet methods, declared in H, that sends values and other commands to the element. These methods can change depending on what you are trying to send.

Example:
If I want to send a variable to a NSTextField that is an (int) I must use the setIntValue method. If I am sending an NSString to the NSTextField I must use the setStringValue method.

Conclusion
I have made progress to start understanding application programming. I have begun my CD Burning script at the logical step of finding what CD burners are available, this functionality is working. Now I must take my array of burners, read their NSDirectory information and return their names. Then I need to be able to pick one and get use their NSDirectory to get their location, call the Device manager to request control, allow for building a list of files to burn, sending that list to the media, testing to see if media is inserted and burnable, and a suite of other features.

Step 1 done, step 215 I'm coming for you!