Objective-C and Cocoa is the predominate language/framework on the OS X operating system, but it is fairly uncommon otherwise. One way to enable an application written in this language to communicate with applications written for other platforms is via the universal XML. Marcus Zarra walks you through constructing, transmitting, and deconstructing an XML document using Objective-C and Cocoa.
Cocoa: Working with XML
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
showing that Objective-C plus Cocoa are one of the best team available for application programming.
This is a concise/efficient article for those who want to discover how easy the job can be done using Objective-C/Cocoa. I only hope the GNUstep team ( http://www.gnustep.org ) will add the missing classes into their frameworks…
Some would say that Objective-C lost the battle of OO programming, yes it’s true, it lost a batttle but did not lost the war. Smalltalk descendant such as Objective-c or io are great OO languages offering simple yet powerful mechanisms to help programmers in their task
Edited 2006-05-22 09:45
Why is this one of the best team for application programming?
In all honesty java is less cryptic and without OS dependant tasks, it really is “write once run everywhere”.
“Why is this one of the best team for application programming?”
Just have a try….
“In all honesty java is less cryptic and without OS dependant tasks”
Lol, that’s why Objective-c is said to be a “self-documented” language and that application written using objective-C can run on windows, linux, mac os X, *BSD… and almost any architecture supported by these OSes…
“write once run everywhere”.”
I love mythology too but I don’t believe in Santa Claus any more sorry…
it really is “write once run everywhere”.
Yea… until you need to access a files permissions or determine the amount of physical memory on the box then the write once run everywhere goes to hell. Jave STILL has lots of short comings for its age.
This is true of _ANY_ language that targets a virtual machine, as opposed to targeting a specific computer or OS. For instance, C# is one of these languages. It targets the .NET CLR. It can also be used with the MONO .NET runtime. As long as you stay with the runtime features, you app can run on any OS that supports the runtime environment. However, if you need to access OS specific information, you may have to leave the managed world and call unmanaged code. For instance, to get a list of SQL Server in my .NET app, I had to use SQL-DMO objects, which is COM based. I had to make native calls, just like Java allows JNI calls. Obviously, these type of operations are not neutral. Eventually, many of these kinds of operations can be abstracted and added to the runtime or supporting libraries. This happens in Java when new features are added. For instance, instead of calling out to platform-specific code to poll serial ports, eventually native java libraries are added to do this (unfortunately, this is a bad example, because it doesn’t work very well!).
This is true of _ANY_ language that targets a virtual machine, as opposed to targeting a specific computer or OS. For instance, C# is one of these languages. It targets the .NET CLR. It can also be used with the MONO .NET runtime. As long as you stay with the runtime features, you app can run on any OS that supports the runtime environment. However, if you need to access OS specific information, you may have to leave the managed world and call unmanaged code. For instance, to get a list of SQL Server in my .NET app, I had to use SQL-DMO objects, which is COM based. I had to make native calls, just like Java allows JNI calls. Obviously, these type of operations are not neutral. Eventually, many of these kinds of operations can be abstracted and added to the runtime or supporting libraries. This happens in Java when new features are added. For instance, instead of calling out to platform-specific code to poll serial ports, eventually native java libraries are added to do this (unfortunately, this is a bad example, because it doesn’t work very well!).
Correct me if I’m wrong but all OS’s have files, file permisions and physical memory. Why was this left out of Java?
What exactly do you mean by file permissions? If you’re talking about setting read/write/execute stuff, have a look at http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html
As for physical memory, why do you need to know the amount of physical memory? How many applications actually need to know the amount of installed physical memory? Java tries to make memory management completely transparent to the programmer, thus it really makes no sense to provide a facility for gauging the amount of physical memory present.
Nevertheless, if you are interested in knowing the amount of physical memory, there is nothing stoping you from parsing the contents of /proc/meminfo if you’re on Linux or calling some related system function if you’re on some other system.
What exactly do you mean by file permissions?
Actually, I want to know group, user and other etc. I don’t think the link you provided allows for this. Permissions for a file should simply be in the java.io.File object. Just like the setLastModified() method is…
As for physical memory, why do you need to know the amount of physical memory?
We have a process that calulates the number of threads to run based on the number of cpu’s and the amount of available memory for processing. Sometimes we need to launch more jvms due to the 4 gig process limit (on Solaris) so the process needs to know physical memory limits.
Nevertheless, if you are interested in knowing the amount of physical memory, there is nothing stoping you from parsing the contents of /proc/meminfo if you’re on Linux or calling some related system function if you’re on some other system.
Hmm… not very portable but like I said all OS’s have memory and Java has no means to access the amount of physical memory. While using meminfo may work on Linux it won’t on Solaris or Windows. What if they change the format of the output to meminfo in the next version of Linux. It breaks my code and I get the support calls. Now if java just added this in the Runtime class it really wouldn’t be an issue.