Apple posts developer overview of Tiger
http://developer.apple.com/macosx/tiger/index.html
Most of it is greek to me, or stuff that we more or less know already. I suppose the interesting part to me is how they frame the point of this version to developers.
As I read through the stuff, at least the stuff I think I understood, it's interesting to me to see how they use phases like "drop into" when talking about coding with Cocoa. I guess I never quite got a handle on Cocoa in the big scheme of things. I didn't realize that Cocoa objects seem to be considered lower level items, and that Apple was trying to build really high-level tools where Cocoa is touched less by developers, for general coding anyway. I've always understood that Cocoa/Obj-C was considered a relatively high-level language anyway and that frameworks were just a bunch of Cocoa objects served up buffet-style.
Are the terms "API" and "framework" interchangeable? Where does this leave Carbon? I read somewhere that Apple wants developers to (somehow) access Carbon calls through Cocoa or something like that. Is this what XCode 2 is all about, and where does that leave IB and older developer tools?
Maybe this is more interesting to someone on the outside than someone who already is familiar with this stuff.
Most of it is greek to me, or stuff that we more or less know already. I suppose the interesting part to me is how they frame the point of this version to developers.
Quote:
There's a common theme that runs through all of these new technologies in Tiger: Allowing developers to focus on writing application-specific code. You as a developer shouldn't have to reinvent the wheel to implement the features that Mac users expect. Instead, Apple is providing a set of rich frameworks that take care of many facets of application development so that you can focus on your applications and what you do best.
There's a common theme that runs through all of these new technologies in Tiger: Allowing developers to focus on writing application-specific code. You as a developer shouldn't have to reinvent the wheel to implement the features that Mac users expect. Instead, Apple is providing a set of rich frameworks that take care of many facets of application development so that you can focus on your applications and what you do best.
As I read through the stuff, at least the stuff I think I understood, it's interesting to me to see how they use phases like "drop into" when talking about coding with Cocoa. I guess I never quite got a handle on Cocoa in the big scheme of things. I didn't realize that Cocoa objects seem to be considered lower level items, and that Apple was trying to build really high-level tools where Cocoa is touched less by developers, for general coding anyway. I've always understood that Cocoa/Obj-C was considered a relatively high-level language anyway and that frameworks were just a bunch of Cocoa objects served up buffet-style.
Are the terms "API" and "framework" interchangeable? Where does this leave Carbon? I read somewhere that Apple wants developers to (somehow) access Carbon calls through Cocoa or something like that. Is this what XCode 2 is all about, and where does that leave IB and older developer tools?
Maybe this is more interesting to someone on the outside than someone who already is familiar with this stuff.
Comments
Basically, in normal programming, you call the methods that you want, when you want. To use an API, you have to call it in the right place. You control the flow of your program.
In frameworks, the framework controls the flow. Every so often it'll call parts of your code and tell it to deliver some app-specific functionality.
I'm not very good at explaining - don't know any cocoa so can't use that as an example. But it's something like that.
Amorya
APIs often cover large bodies of code called libraries. These bodies of code provide programs with tools to get some job done, and they are often shared between a lot of separate programs. This keeps people from re-inventing the wheel some of the time (although it still happens a lot), it can also make it easier to make different programs compatible (but does not in any way guarantee it).
Frameworks are a form of library that have become very popular. They are a little hard to describe directly, so I will try and do it by using the example of Cocoa's NSApplication framework:
When you create a Cocoa application using XCode you start out with a single source file with about 5 lines of code, and a few supporting files. One of those lines of code says that this object you just created is an instance of the NS-Application framework, and it has a single call that tells things to go.
Right out of the box we can compile the program as it is, and it is a fully working program, with a GUI and everything. Not a useful program, as all it does is brings up and empty window, and the only things you can do with it are: Quit and Get Info. But for all that it is a true program.
NSApplication has a lot of methods that can be used, but by default most of them don't do anything. What you do is start overriding them (replacing them with your own code) or using InterfaceBuilder to wire up the GUI to your own code. For example, if you were writing an instant messaging client and you wanted to make sure that all of your accounts were signed off before quitting, you might implement NSApplication's applicationShouldTerminate:: method. It is called whenever you quit the application. It can even respond to the event canceling the quit.
Another instance would be the NSTextView class in the AppKit framework. If you open TextEdit the area where you type text is probably one of these, as is the area in OmniWeb that I am writing this right now. By just a few clicks in InterfaceBuilder, and a few lines of code in XCode I can setup a area like this in a program that includes fonts, colors of text, has a built-in spellchecker, etc... and then I can start over-riding things in my own subclass so that I can check every time someone types a letter into that field, and remove all of the d's. I take the framework and simply replace the part I want to change.
Ok... I hope you have a handle on frameworks, as now comes an odd part. The Cocoa framework has two complete APIs: one in Java and one in Objective-C (there are also a bunch of bridges for other languages). Both of those APIs access the same functions and finally wind up executing the same code (in fact they are as similar as possible).
And in fact the Carbon API winds up accessing a lot of the same code as Cocoa. Carbon shares many of the libraries that make up the Cocoa code (and in some cases Cocoa APIs are built directly on Carbon APIs... silly but true). The POSIX libraries (think unix) also share a lot of this code.
The big deal here is that Carbon is a library, and not really a framework (although it does have some features that border on it). In comparison you don't get a lot for free like you do in Cocoa.
GCC 4 in XCode 2
While hand-tuning Velocity Engine code can get you the maximum performance from the G4 and G5 processors, now you can have GCC do the heavy lifting for you. You'll benefit from this without any extra effort, with auto-vectorization in GCC bringing anywhere between a 4X and 14X performance improvement to code that works with arrays of data.
Spotlight -- one single interface for your application to be spotlight aware...
If your application saves files in its own custom format, you'll want to expose the meta-data from those files to users on the system through Spotlight. In order to do that, you need to provide a Spotlight Importer plug-in with your application. This consists of using the Spotlight Importer template in Xcode and implementing a single function that is bundled into a plug-in for the Spotlight system.
...
The list goes on. I am so tempted to buy the 500$ membership. Only problem is that I will have to buy another system for pre-release software. I have no intention of messing up my iMac at home.
What % is the typical developer discount for hardware?
Originally posted by talksense101
Only problem is that I will have to buy another system for pre-release software. I have no intention of messing up my iMac at home.
Par?ti?tion (n) A section of storage space on a hard disk that mounts independently from other sections of the hard disk.
So, in library terms, the framework is the shelving, the "library" is actually the books, and the API is the card catalog/index (if you're old enough to remember those)? You find the books with the index, you put them on the shelf, and voila (more or less)?
So Cocoa is in a way a set of shelving, and Carbon is a bunch of books? I guess before OS X, you piled your books up in one place, and with Cocoa, you have the Carbon books and a few others genres to choose from?
The comparison with cards catalogs is ok, but I usually think of it more as a bunch of handles and levers that a program (or library or os... etc...) exposes to programmers.
Originally posted by hmurchison
Is GCC 4.0 just a renaming of GCC 3.5?
That would be my guess.
Apple's Xcode preview page mentions GCC 3.5. I'm betting it hasn't been updated since WWDC.
http://www.apple.com/macosx/tiger/xcode.html
Originally posted by hmurchison
Is GCC 4.0 just a renaming of GCC 3.5?
Yes. The post-GCC 3.4 release has recently been renamed 4.0.
Mike
I didn't understand much about that CoreData stuff either. It sounds like it takes care of a bunch of standard app features for the developer. I guess I would need a better understanding of what data objects are compared to everything else that goes into an app, and what the meachnisms are to handle them in CoreData.
iTunes is a good example of an app that has a database backend on it.
If I am to understand it well, CoreData is going to provide the means for developers to add iTunes database backend functionality to their apps without all the hard work involved. CoreData does all the hardwork for you.
Originally posted by costique
Damn, I am accepting donations, selling my soul, whatever, for either $500 or Tiger Early Start Kit account. I'm not joking.
Do you have a hot sister? or Mom?
Originally posted by Placebo
Par?ti?tion (n) A section of storage space on a hard disk that mounts independently from other sections of the hard disk.
No space. Unless I buy an external hard disk and boot OS-X from that. Hmm...
Originally posted by curiousuburb
Do you have a hot sister? or Mom?
I have myself. Want to make a deal?
Originally posted by curiousuburb
Do you have a hot sister? or Mom?
ROFL
Originally posted by talksense101
No space. Unless I buy an external hard disk and boot OS-X from that. Hmm...
Which *would* be slightly less expensive than buying a whole new rig. Then again, if you're just looking for an excuse to buy something new anyway... by our guest
Originally posted by MPMoriarty
Apparently as others who are more in touch with CoreData have explained to me is that currently developers who want to have a database backend on their applications have to code it themselves manually.
iTunes is a good example of an app that has a database backend on it.
If I am to understand it well, CoreData is going to provide the means for developers to add iTunes database backend functionality to their apps without all the hard work involved. CoreData does all the hardwork for you.
Do those "others who have explained to you" say whether Core Data gives full RDBMS/SQL functionality? I've been kicking around the idea of coding up an Access clonelike program using MySQL & a couple of helper programs, but if I could use Core Data (which would also allow the data to be searchable system-wide) that would be a much better implementation for my purposes.
Originally posted by PBG4 Dude
Do those "others who have explained to you" say whether Core Data gives full RDBMS/SQL functionality? I've been kicking around the idea of coding up an Access clonelike program using MySQL & a couple of helper programs, but if I could use Core Data (which would also allow the data to be searchable system-wide) that would be a much better implementation for my purposes.
The whole idea behind core data is to allow you to store your data without having to learn SQL or pay attention to when to save something. That means that you will not have the full range of SQL exposed... just like the full range of SQL is not easy to use using Access. SQL is a really flexible thing, and those who need that flexibility need SQL, there is no getting around that. But most programs don't need that, they just need to map relations and have a persistence layer. This is what CoreData is aimed at.
Oh... and why do you think that having your data in a CoreData file (of any type) will automatically expose your data to Spotlight? They are completely different functions, and spotlight would still need something to map all of your data to categories it understands, and that is going to be really difficult with CoreData's SQLite format... the plist/xml one is conceivable (if very difficult for complex files). So far Apple has said that Spotlight will only work on individual files, Mail.app is moving to them, and I would presume that either they are special casing Addressbook, or that it is moving to vcard separate files.
Oh... there are a bunch of Access clones already being worked on in various linux based projects... none are ready for prime time yet. Why not go work on one of those, bring it to MacOS X?