Apple posts developer overview of Tiger

Posted:
in macOS edited January 2014
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.



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.



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.
«1

Comments

  • Reply 1 of 23
    amoryaamorya Posts: 1,103member
    Framework == "Don't call us, we'll call you."



    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
  • Reply 2 of 23
    An API (application program interface) is a listing of all of the function calls that a program makes available for programmers to use. If a programmer has created a cat program the API might have entries like: meow, scratch_furniture, and befuddle_owner. In the case of an operating system like MacOS X, there are a lot of APIs that cover a lot of different sections of the OS.



    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.
  • Reply 3 of 23
    Yummy!



    GCC 4 in XCode 2

    Quote:

    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...



    Quote:

    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?
  • Reply 4 of 23
    hmurchisonhmurchison Posts: 12,419member
    Is GCC 4.0 just a renaming of GCC 3.5?
  • Reply 5 of 23
    placeboplacebo Posts: 5,767member
    Quote:

    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.



  • Reply 6 of 23
    buonrottobuonrotto Posts: 6,368member
    Gracias, Karl.



    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?
  • Reply 7 of 23
    I am not sure that your metaphor is useful in this case. Frameworks are a type of library... they are just arranged in a way that they provide basic functionality by themselves and you add or replace the behaviors in them. In computer science speak frameworks are very object oriented libraries that contain base classes. The can also get very large (called umbrella frameworks) and often contain or access many traditional libraries.



    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.
  • Reply 8 of 23
    mcqmcq Posts: 1,543member
    Quote:

    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
  • Reply 9 of 23
    chuckerchucker Posts: 5,089member
    Quote:

    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.
  • Reply 10 of 23
    Apple finally went into a little more detail about CoreData. Although I don't understand a thing they said. I wish they could provide a nice example of how an application developed using CoreData would benefit more compared to one developed without using CoreData.



    Mike
  • Reply 11 of 23
    buonrottobuonrotto Posts: 6,368member
    Thanks, karl. So frameworks are a certain kind of library, and an API helps you get what you want from them.



    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.
  • Reply 12 of 23
    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.
  • Reply 13 of 23
    costiquecostique Posts: 1,084member
    Damn, I am accepting donations, selling my soul, whatever, for either $500 or Tiger Early Start Kit account. I'm not joking.
  • Reply 14 of 23
    Quote:

    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?
  • Reply 15 of 23
    Quote:

    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...
  • Reply 16 of 23
    costiquecostique Posts: 1,084member
    Quote:

    Originally posted by curiousuburb

    Do you have a hot sister? or Mom?



    I have myself. Want to make a deal?
  • Reply 17 of 23
    zozo Posts: 3,117member
    Quote:

    Originally posted by curiousuburb

    Do you have a hot sister? or Mom?



    ROFL
  • Reply 18 of 23
    zozo Posts: 3,117member
    Quote:

    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
  • Reply 19 of 23
    pbg4 dudepbg4 dude Posts: 1,611member
    Quote:

    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.
  • Reply 20 of 23
    Quote:

    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?
Sign In or Register to comment.