REST: A Tutorial

January 4, 2011

1. What is REST?

REST stands for Representational State Transfer. (It is sometimes spelled “ReST”.) It relies on a stateless, client-server, cacheable communications protocol — and in virtually all cases, the HTTP protocol is used.

REST is an architecture style for designing networked applications. The idea is that, rather than using complex mechanisms such as CORBA, RPC or SOAP to connect between machines, simple HTTP is used to make calls between machines.

In many ways, the World Wide Web itself, based on HTTP, can be viewed as a REST-based architecture.
RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.

REST is a lightweight alternative to mechanisms like RPC (Remote Procedure Calls) and Web Services (SOAP, WSDL, et al.). Later, we will see how much more simple REST is.

Despite being simple, REST is fully-featured; there’s basically nothing you can do in Web Services that can’t be done with a RESTful architecture.
REST is not a “standard”. There will never be a W3C recommendataion for REST, for example. And while there are REST programming frameworks, working with REST is so simple that you can often “roll your own” with standard library features in languages like Perl, Java, or C#.

2. REST as Lightweight Web Services

As a programming approach, REST is a lightweight alternative to Web Services and RPC.

Much like Web Services, a REST service is:

Platform-independent (you don’t care if the server is Unix, the client is a Mac, or anything else),
Language-independent (C# can talk to Java, etc.),
Standards-based (runs on top of HTTP), and
Can easily be used in the presence of firewalls.
Like Web Services, REST offers no built-in security features, encryption, session management, QoS guarantees, etc. But also as with Web Services, these can be added by building on top of HTTP:

For security, username/password tokens are often used.
For encryption, REST can be used on top of HTTPS (secure sockets).
… etc.
One thing that is not part of a good REST design is cookies: The “ST” in “REST” stands for “State Transfer”, and indeed, in a good REST design operations are self-contained, and each request carries with it (transfers) all the information (state) that the server needs in order to complete it.

3. How Simple is REST?

Let’s take a simple web service as an example: querying a phonebook application for the details of a given user. All we have is the user’s ID.

Using Web Services and SOAP, the request would look something like this:

<?xml version=”1.0″?>
 <soap:body pb=””&gt;
(The details are not important; this is just an example.) The entire shebang now has to be sent (using an HTTP POST request) to the server. The result is probably an XML file, but it will be embedded, as the “payload”, inside a SOAP response envelope.

And with REST? The query will probably look like this:
Note that this isn’t the request body — it’s just a URL. This URL is sent to the server using a simpler GET request, and the HTTP reply is the raw result data — not embedded inside anything, just the data you need in a way you can directly use.

It’s easy to see why Web Services are often used with libraries that create the SOAP/HTTP request and send it over, and then parse the SOAP response.
With REST, a simple network connection is all you need. You can even test the API directly, using your browser.
Still, REST libraries (for simplifying things) do exist, and we will discuss some of these later.
Note how the URL’s “method” part is not called “GetUserDetails”, but simply “UserDetails”. It is a common convention in REST design to use nouns rather than verbs to denote simple resources.

The letter analogy
A nice analogy for REST vs. SOAP is mailing a letter: with SOAP, you’re using an envelope; with REST, it’s a postcard. Postcards are easier to handle (by the receiver), waste less paper (i.e., consume less bandwidth), and have a short content. (Of course, REST requests aren’t really limited in length, esp. if they use POST rather than GET.)

But don’t carry the analogy too far: unlike letters-vs.-postcards, REST is every bit as secure as SOAP. In particular, REST can be carried over secure sockets (using the HTTPS protocol), and content can be encrypted using any mechanism you see fit. Without encryption, REST and SOAP are both insecure; with proper encryption in place, both are equally secure.

4. More Complex REST Requests

The previous section included a simple example for a REST request — with a single parameter.

REST can easily handle more complex requests, including multiple parameters. In most cases, you’ll just use HTTP GET parameters in the URL.

For example:
If you need to pass long parameters, or binary ones, you’d normally use HTTP POST requests, and include the parameters in the POST body.

As a rule, GET requests should be for read-only queries; they should not change the state of the server and its data. For creation, updating, and deleting data, use POST requests. (POST can also be used for read-only queries, as noted above, when complex parameters are required.)

In a way, this web page (like most others) can be viewed as offering services via a REST API; you use a GET request to read data, and a POST request to post a comment — where more and longer parameters are required.
While REST services might use XML in their responses (as one way of organizing structured data), REST requests rarely use XML. As shown above, in most cases, request parameters are simple, and there is no need for the overhead of XML.

One advantage of using XML is type safety. However, in a stateless system like REST, you should always verify the validity of your input, XML or otherwise!

5. REST Server Responses

A server response in REST is often an XML file; for exmaple,

 <part id=”3322″>
  <name>ACME Boomerang</name>
   Used by Coyote in <i>Zoom at the Top</i>, 1962
  <price currency=”usd” quantity=”1″>17.32</price>
 <part id=”783″>
  <name>ACME Dehydrated Boulders</name>
   Used by Coyote in <i>Scrambled Aches</i>, 1957
  <price currency=”usd” quantity=”pack”>19.95</price>
However, other formats can also be used; unlike SOAP services, REST is not bound to XML in any way. Possible formats include CSV (comma-separated values) and JSON (JavaScript Object Notation).

Each format has its own advantages and disadvantages. XML is easy to expand (clients should ignore unfamiliar fields) and is type-safe; CSV is more compact; and JSON is trivial to parse in JavaScript clients (and easy to parse in other languages, too).

One option is not acceptable as a REST response format, except in very specific cases: HTML, or any other format which is meant for human consumption and is not easily processed by clients. The specific exception is, of course, when the REST service is documented to return a human-readable document; and when viewing the entire WWW as a RESTful application, we find that HTML is in fact the most common REST response format…

6. Real REST Examples

Here’s a very partial list of service providers that use a REST API. Note that some of them also support a WSDL (Web Services) API, in addition, so you can pick which to use; but in most cases, when both alternatives are available, REST calls are easier to create, the results are easier to parse and use, and it’s also less resource-heavy on your system.

So without further ado, some REST services:

The famous Twitter API is all REST.
Yahoo! offer most of their services using REST. This includes
Search API,
… and just about any other.
Flickr, offer several REST services, e.g., for their S3 storage solution (see Chapter 6),
Atom is a RESTful alternative to RSS.
(This is far from an exhaustive list.)

Here’s a simple example: the following URL sends a REST request to Yahoo!’s web-search service: Click it, and observe the XML results, ready to be used directly, not wrapped in an SOAP “envelope” or other noise.

This REST request includes two parameters: “appid”, used by Yahoo! to specify your application, and “query”, which is the actual search query.
If you plan to make actual use of Yahoo!’s web-search service, make sure you create your own appid. See the documentation for details.

7. AJAX and REST

AJAX is a popular web development technique that makes web pages interactive using JavaScript.

In AJAX, requests are sent to the server using XMLHttpRequest objects. The response is used by the JavaScript code to dynamically change the current page.

In many ways, AJAX applications follow the REST design principles. Each XMLHttpRequest can be viewed as a REST service request, sent using GET. And the response is often in JSON, a popular response format for REST. (See REST Server Responses, above.)

To make your AJAX application truly RESTful, follow the standard REST design principles (discussed later). You will find that most of them contribute to a good design, even if you don’t think of your architecture in terms of REST.

A later section provides code samples for issuing HTTP requests in JavaScript, but if you’ve done any AJAX programming, you are already familiar with all that.

8. REST Architecture Components

Key components of a REST architecture:

Resources, which are identified by logical URLs. Both state and functionality are represented using resources.
The logical URLs imply that the resources are universally addressable by other parts of the system.
Resources are the key element of a true RESTful design, as opposed to “methods” or “services” used in RPC and SOAP Web Services, respectively. You do not issue a “getProductName” and then a “getProductPrice” RPC calls in REST; rather, you view the product data as a resource — and this resource should contain all the required information (or links to it).
A web of resources, meaning that a single resource should not be overwhelmingly large and contain too fine-grained details. Whenever relevant, a resource should contain links to additional information — just as in web pages.
The system has a client-server, but of course one component’s server can be another component’s client.
There is no connection state; interaction is stateless (although the servers and resources can of course be stateful). Each new request should carry all the information required to complete it, and must not rely on previous interactions with the same client.
Resources should be cachable whenever possible (with an expiration date/time). The protocol must allow the server to explicitly specify which resources may be cached, and for how long.
Since HTTP is universally used as the REST protocol, the HTTP cache-control headers are used for this purpose.
Cilents must respect the server’s cache specification for each resource.
Proxy servers can be used as part of the architecture, to improve performance and scalability. Any standard HTTP proxy can be used.
Note that your application can use REST services (as a client) without being a REST architecture by itself; e.g., a single-machine, non-REST program can access 3rd-party REST services.

9. REST Design Guidelines

Some soft guidelines for designing a REST architecture:

Do not use “physical” URLs. A physical URL points at something physical — e.g., an XML file: “;. A logical URL does not imply a physical file: “;.
Sure, even with the .xml extension, the content could be dynamically generated. But it should be “humanly visible” that the URL is logical and not physical.
Queries should not return an overload of data. If needed, provide a paging mechanism. For example, a “product list” GET request should return the first n products (e.g., the first 10), with next/prev links.
Even though the REST response can be anything, make sure it’s well documented, and do not change the output format lightly (since it will break existing clients).
Remember, even if the output is human-readable, your clients aren’t human users.
If the output is in XML, make sure you document it with a schema or a DTD.
Rather than letting clients construct URLs for additional actions, include the actual URLs with REST responses. For example, a “product list” request could return an ID per product, and the specification says that you should use to get additional details. That’s bad design. Rather, the response should include the actual URL with each item:, etc.
Yes, this means that the output is larger. But it also means that you can easily direct clients to new URLs as needed, without requiring a change in client code.
GET access requests should never cause a state change. Anything that changes the server state should be a POST request (or other HTTP verbs, such as DELETE).

10. ROA vs. SOA, REST vs. SOAP

ROA (REST Oriented Architecture) is just a fancy name for a SOA (Service Based Architecture) using REST services.

The main advantage of SOAP-based SOA over ROA is the more mature tool support; however, this could change over time. Another SOA advantages include the type-safety of XML requests (for responses, ROA can also use XML if the developers desire it).

The main advantage of ROA is ease of implementation, agility of the design, and the lightweight approach to things. In a way, SOA and SOAP is for people in business suits; that’s what you’ll find used in the banking and finance industries. Conversely, somebody that needs something up-and-running quickly, with good performance and low overhead, is often better off using REST and ROA.

For example, when explaining why they chose REST over SOAP, Yahoo! people write that they “believe REST has a lower barrier to entry, is easier to use than SOAP, and is entirely sufficient for [Yahoo’s] services” (Yahoo! Developer Network FAQ, as of February 2008). This is true not only of REST vs. SOAP but also of ROA vs. SOA in general.

Another advantage of REST lies with performance: with better cache support, lightweight requests and responses, and easier response parsing, REST allows for nimbler clients and servers, and reduces network traffic, too.

As REST matures, expect it to become better understood and more popular even in more conservative industries.

A few words on hype vs. reality. In the comments below, I’ve linked to Pete Lacey’s excellent criticism of SOAP, “The S Stands for Simple”. And here’s another one, by Alex Bell, published in Communications of the ACM (vol. 51, no. 10, October ’08): “DOA with SOA”.

11. Documenting REST Services: WSDL and WADL

WSDL, a W3C recommendation, is the Web Services Description Language. It is commonly used to spell out in detail the services offered by a SOAP server. While WSDL is flexible in service binding options (for example, services can be offered via SMTP mail servers), it did not originally support HTTP operations other than GET and POST. Since REST services often use other HTTP verbs, such as PUT and DELETE, WSDL was a poor choice for documenting REST services.

With version 2.0, WSDL supports all HTTP verbs and it is now considered to be an acceptable method of documenting REST services.

The second alternative is WADL, the Web Application Description Language. WADL is championed by Sun Microsystems. Like the rest of REST, WADL is lightweight, easier to understand and easier to write than WSDL. In some respects, it is not as flexible as WSDL (no binding to SMTP servers), but it is sufficient for any REST service and much less verbose.

Here is a fragment from a WADL specification, describing Amazon’s “Item Search” service:

<method name=”GET” id=”ItemSearch”>
  <param name=”Service” style=”query”
  <param name=”Version” style=”query” fixed=”2005-07-26″/>
  <param name=”Operation” style=”query” fixed=”ItemSearch”/>
  <param name=”SubscriptionId” style=”query”
   type=”xsd:string” required=”true”/>
  <param name=”SearchIndex” style=”query”
   type=”aws:SearchIndexType” required=”true”>
    <option value=”Books”/>
    <option value=”DVD”/>
    <option value=”Music”/>
  <param name=”Keywords” style=”query”
   type=”aws:KeywordList” required=”true”/>
  <param name=”ResponseGroup” style=”query”
   type=”aws:ResponseGroupType” repeating=”true”>
    <option value=”Small”/>
    <option value=”Medium”/>
    <option value=”Large”/>
    <option value=”Images”/>
  <representation mediaType=”text/xml”
As you can see, for format is mostly self-explanatory, and it enriches REST with such goodies as type safety using XML schema types.

The entire document is only about 10 lines longer than this fragment (including XML namespace specifications, importing schema grammers, etc.) and can be found in the WADL specification.
For another real-world WADL document, check out the W3C Unicorn project’s specification of the CSS validator service.
Some REST advocates, however, find even the lightweight WADL to be an overkill. And indeed, most REST services are documented by no more than a textual description (a human-readable HTML file).

Tags: ,

Understanding and Analyzing iPhone OS Application Crash Reports

December 30, 2010

This post contains essential information for developers who wish to receive and process crash reports for their iPhone OS applications.

1.Report Types
3.Acquiring Crash Reports
4.The Xcode Organizer

1.Report Types

There are four distinct kinds of crash reports. They are:

i)Application crash: possibly the most common kind of report, this is generated when execution is halted due to bad memory access, an exception or some other programming error.

ii)Low memory: occurs when the application has been killed by the system because there wasn’t enough memory to satisfy the application’s demands. The format of this report differs from the others in that there are no stack traces for the application threads. Rather than be concerned about what part of your code was executing at the time of termination, you should investigate your memory usage patterns and your responses to low memory warnings. Memory usage of each process is reported in terms of number of memory pages, which as of this writing are 4KB each.

iii)User force-quit: distinguished by exception code 0xdeadfa11. Force quits occur when the user holds down the home button for six seconds. It’s reasonable to assume the user has done this because the application has become unresponsive, but it’s not guaranteed – force-quit will work on any application.

iv)Watchdog timeout: distinguished by exception code 0x8badf00d. Timeouts occur when an application takes too long to launch, terminate, or respond to system events.

Except for the low memory crash logs, these logs contain stack traces for each thread at the time of termination. The next section discusses those traces.


The most interesting part of a crash report is the stack trace of your application at the time execution halted. This trace is similar to what you would see when stopping execution in the debugger, except that you are not given the method or function names, known as symbols. Instead, you have hexadecimal addresses and executable code – your application or system frameworks – to which they refer. You need to map these addresses to symbols. Unlike crash logs from Mac OS X, iPhone OS logs do not contain symbol information when they’re written out. You have to symbolicate iPhone OS logs before you can analyze them.

Symbolication – resolving stack trace addresses to source code methods and lines – requires the application binary that was uploaded to the App Store and the .dSYM file that was generated when that binary was built. This must be an exact match – otherwise, the report cannot be fully symbolicated. It is essential that you keep each build distributed to users (regardless of the details of that distribution) with its .dSYM file. See The Xcode Organizer for information on how Xcode can help you manage this.

IMPORTANT: You must keep both the application binary and the .dSYM file in order to be able to fully symbolicate crash reports. You should archive these files for every build that you submit to iTunes Connect. The .dSYM and application binary are specifically tied together on a per-build-basis, and subsequent builds, even from the same source files, will not interoperate with files from other builds. If you use the Build and Archive command as discussed in The Xcode Organizer then they will be placed in a suitable location automatically. Otherwise any location searchable by Spotlight (such as your home directory) is fine.
Given a crash report, the matching binary, and its .dSYM file, symbolication is easy. The Xcode Organizer window has a section specifically for Device Logs, and dragging a crash report to this window will symbolicate the crash report and display the results.

3.Acquiring Crash Reports

iTunesConnect service — a web site that iPhone developers use to manage their published applications — has a separate area that will list all the synced crash reports from the application users.

However, not all of the crashes appear there, or are slow to appear. Thus, if you have a desperate problem with someone’s application, it’s a good idea to pick these up and send them to a developer.

Here’s how, in three major operations systems: Mac OS X, Windows Vista / Windows 7 and for Windows XP.

iTunes sync

Application crash logs are transferred to your computer each time you do a sync with the device, in the iTunes. Thus, first step is to sync with iTunes:

Sync the iPhone or iPod Touch through iTunes

Mac OS X

On the Mac, crash logs are kept at:

where ~ is your Home folder. Here’s an example:

Crash logs on the Mac OS X. Device name is “iPhone AV” here
There’s the .crash file and .plist file – archive them both and send to a developer. Actually, pick all the files you find there that have the name of the problematic application.

Windows Vista / Windows 7

Files are located here:

C:\Users\<USERNAME>\AppData\Roaming\Apple computer\Logs\CrashReporter/MobileDevice/<DEVICE_NAME>
AppData folder is hidden by default, so here’s how to access it. Get into your personal folder:

User folder, with Vista folder path
Now click on the folder (address) bar which will change the display into Windows folder path and add \AppData to it, then click Enter.

When clicked, the address bar changes into regular Windows folder path
This will then show the folder contents. From here, you can follow the path above until you get to the crash logs.

For Windows 7, follow the same procedure.

Windows XP

Location is here:

C:\Documents and Settings\<USERNAME>\Application Data\Apple computer\Logs\CrashReporter/<DEVICE_NAME>
<USERNAME> is your login username. Application Data folder is usually hidden by default, so you need to reveal it in the same way as in Vista — by typing in and pressing Enter.

4.The Xcode Organizer

The Xcode Organizer allows you to easily manage many development needs related to iPhone OS development, and managing crash reports is no exception. By default the Xcode Organizer will display and symbolicate all crash reports that it finds either on devices or already downloaded by iTunes. These crash reports are available organized by device or as a whole. To see crash reports by device, select that device and then select the Device Logs tab. To see all crash reports that Xcode has obtained, select the Device Logs entry under iPhone Development. To add crash reports to the listing, drag them into the listing.

Xcode will automatically symbolicate all crash reports that it encounters, but in order to do so it must have the .dSYM and application binary that produced the crash report.

Xcode 3.2.2 introduces the “Build and Archive” command to aid in this process. When you use the Build and Archive command, Xcode will gather the application binary and the .dSYM containing symbol information together and store them in a location in your home folder. You can find all of your archived applications in the Xcode Organizer under the Archived Applications section. Xcode will automatically search archived applications when symbolicating crash reports, and you can submit archived applications directly to iTunes Connect ensuring that the application and .dSYM that you have archived match what you release.

Macworld Boston 1997-The Microsoft Deal

July 23, 2010

Here we see Steve Jobs & the almost bankrupt at the time Apple Computer making a temporary deal with Bill Gates & Microsoft. The crowd was not too happy about it.

 Its the funniest Steve Jobs keynote I have watched. In it he announced his new partnership with Microsoft and then goes and tells everyone how Internet Explorer was going to be the default browser on the Mac. What I found funny is the Apple crowd, everyone was like booing and screaming out “Noooo!!”, I can only imagine how fucked up the experience must have been to them back then.

Blogged with the Flock Browser

Tags: ,

Leopard Technology Overview

June 18, 2008

Leopard is the sixth major version of Mac OS X and it will be the most advanced and powerful version yet. For users, it is full of new features and elegant user experience improvements that will make it a joy to use. For developers, things get even better. Leopard contains a cornucopia of cutting-edge new frameworks, streamlined developer tools, new application technologies, and strong system-level foundations. No matter what kind of developer we are, there’s something new in the system that will feel tailor made just for us.

An Operating System Designed for Innovation

The goal in adding so many new developer technologies into Leopard is to make it easier for us to create compelling, rich, and amazing new applications. Once upon a time, a great application was defined by the functionality it provided. Then, over time, the ease of use of an application became important—it wasn’t enough just to get the job done, it had to be easy to do so. In the last few years, the bar has been raised again. Now, a truly great application isn’t just defined by its features and how easy it is to use them, it’s also defined by how enjoyable it is to use.

By taking advantage of the technologies in Leopard, we can add that extra level of detail that makes our applications not just useful, but highly desirable. We can give them that “wow” factor that will bring our customers back to our application again and again.

Getting to Know the Leopard Technologies

These articles will take a deep look at Xcode, Objective-C 2.0, Core Animation, Image Kit, Instruments, and much more.

I’m starting the series with a broad overview of more than two dozen new and enhanced technologies, tools and APIs that are in Leopard.

Developer Tools

As a developer, the first thing we should do when we install Leopard is take a look at the new developer tools. We are in for a real treat. Apple has put a lot of time and effort into improving Xcode and Interface Builder so that it’s easier to create and maintain large projects. They didn’t stop there, however. In Leopard, Apple introduced the entirely new Instruments and Dashcode tools. Instruments will let us take a look at how our application runs like we’ve never been able to before. Dashcode lets us build Dashboard widgets in no time flat.

Xcode 3.0

Xcode is Apple’s Integrated Development Environment (IDE) for creating any code for Mac OS X. It’s the centerpiece application of our workday. Because it’s such an important part of the development process, Apple spent a lot of time making the latest version of Xcode streamlined and faster, in order to make us more productive. The first place we can notice Xcode’s improvements is in the text editor. Code folding, scope highlighting, and iChat-like message bubbles that clearly mark build warnings and errors as well as breakpoints, are some of the key editing enhancements.


To help us access documentation while we work, the new Research Assistant gives us a heads-up display of relevant information about symbols in our code in a convenient, small panel. If we need more information, we can simply click for more detail and the full documentation window will open. And, to help us experiment with our code, Project Snapshot lets us record the state of our project and snap back to that state at any point in the future. This lets us quickly try out an idea without having to check things back into our projects source code repository.

Interface Builder 3.0

Interface Builder is the intuitive, easy-to-use tool for creating and editing user interface resources files (nib files). These files represent a set of interface objects and their relationships, as well as their connections to our application’s logic. In Leopard, Interface Builder has been thoroughly modernized and updated, both to support the new interface technologies in Leopard as well as to make the applications we develop easier than ever to build.


In addition to laying out our user interface, Interface Builder now lets us add impressive Core Animation-based behaviors to our application, such as the iChat sliding list view or Keynote-style transitions, in a matter of minutes. And it even has features that improve the ability to see differences between versions of our interface. It also comes with a new Interface Builder Kit API for plug-in developers.


Instruments is a brand-new, timeline-based performance visualization tool that gives us the ability to see how our application works like we’ve never been able to do before. It lets me watch CPU, disk I/O, memory usage, garbage collection, events, and more in the form of graphs tied to time.

For example, we can track UI events in real-time and see how they affect I/O activity and CPU load at the same time. And, once the data has been collected, we can scan back and forth through our application’s run and see exactly what occurred, and when.


Instruments builds on top of the open source DTrace utility. DTrace is a comprehensive command-line monitoring utility that can probe almost any aspect of system performance. It comes with a large set of tools that cover most general aspects of system performance, including both kernel and user code, with near-zero overhead. If there is an aspect of the system that we want to track that isn’t already supported, we can create our own tool using the D programming language.


Dashcode is Apple’s new Dashboard widget development environment. It offers a built-in debugger and all the text editing features of a professional IDE. We can set and view breakpoints as well as track our widget’s execution through its JavaScript source code.

Dashcode is geared for all levels of widget developers. We can start out with a prebuilt template and modify it to our needs, or get deep into the JavaScript, CSS, and HTML that defines all the aspects of how a widget looks and works.

Application Technologies

Leopard brings a multitude of improvements and additions to the Cocoa application framework set. The most visible of these is the new Core Animation framework which makes creating compelling interfaces much easier. Not as obvious, but no less important is the addition of garbage collection to Objective-C, new graphical controls, and 64-bit capabilities up the entire Cocoa stack from the BSD core system up to graphics, sound and networking. In addition, Leopard brings a factor of ten increase in the performance of Core Data.

Core Animation

Core Animation is a Cocoa framework for creating animated, composited, and dynamic user interfaces with a simple and approachable programming model. The fluid animations it creates are enabled by Quartz, OpenGL, and Core Image, yet it exposes a familiar NSView-style hierarchy that mirrors that of the Application Kit view architecture. Many of the new user-level features in Leopard, such as Spaces and Time Machine, utilize Core Animation to perform their user interface transitions.


Using Core Animation, our application can effortlessly provide a cinematic user experience to our users. We’ll be able to smoothly move user interface elements around the screen, fade them in and out, and add effects with just a few lines of code. In addition to Quartz and Core Image, we can also leverage Core Video and Quartz Composer to achieve a wide range of visual results. We can direct Core Animation from either code or by using Interface Builder.

Objective-C 2.0

Objective-C is an ANSI C compatible language with dynamic object-oriented extensions. It combines the power of Smalltalk-style message passing with the performance and native system-level access of C. From the start, the abilities of Obj-C have fueled the power of the Cocoa framework. Now in Leopard, the Objective-C runtime has been updated to include a thoroughly modern and high performance garbage collection system, making memory management a thing of the past.

Also new in Objective-C 2.0 are a set of syntax improvements, including property accessors and fast enumeration. These improvements bring the language up-to-date with the expectations of today’s programmers. And, since Objective-C 2.0 is compatible with existing Objective-C source, we can adopt it at our own pace.

iChat Integration

Instant messaging has become an essential tool for users to communicate and collaborate. In Leopard, the ability to collaborate has been taken to a new level. In an iChat session, users will be able to use iChat Theatre to present data from another application, such as iPhoto or Keynote, as part of a video conference. The applications we create will also be able to integrate with iChat in the same way using the Instant Messaging framework via the Core Video and Core Audio APIs. Once integrated, the Instant Messaging framework will automatically compress the content, using the H.264 codec, and send it across the network to the remote user’s display.

Another new feature in the Instant Messaging framework is the ability to manage presence. This means that our application can query the iChat status of the user, indicating whether they are available or busy and what their status message is, as well as manipulate it. As well, it will give access to the buddy list. If we are building an application which allows users to collaborate on content, we could use the APIs to notify users when their friends or co-workers were online.

Resolution Independence

The old assumption that displays are 72dpi has been rendered obsolete by advances in display technology. Macs now ship with displays that sport native resolutions of 100dpi or better. Furthermore, the number of pixels per inch will continue to increase dramatically over the next few years. This will make displays crisper and smoother, but it also means that interfaces that are pixel-based will shrink to the point of being unusable. The solution is to remove the 72dpi assumption that has been the norm. In Leopard, the system will be able to draw user interface elements using a scale factor. This will let the user interface maintain the same physical size while gaining resolution and crispness from high dpi displays.

The introduction of resolution independence may mean that there is work that we’ll need to do in order to make our application look as good as possible. For modern Cocoa applications, most of the work will center around raster-based resources. For older applications that use QuickDraw, more work will be required to replace QuickDraw-based calls with Quartz ones.

Calendar Store

The Calendar Store framework provides access to a user’s iCal calendar data. Using the framework, we can fetch calendars, events, and tasks from iCal’s data storage. This allows our application to work with the same data as iCal, Mail, and any other application that a manager uses to interact with their schedule and to-do items.

Graphics & Media

Each release of Mac OS X builds on and expands the capabilities of QuickTime, Quartz, OpenGL, and Core Audio, and Leopard is no exception. The Graphics & Media frameworks in Leopard enable all of the higher-level application technologies, and expand them in new and exciting ways.

Image Kit

Image Kit is a new and robust Cocoa-based framework powered by Core Image and Core Animation. It makes available powerful imaging services that can be easily incorporated into our application. It provides functionality for finding, browsing, and viewing images in a collection. We can rearrange images in a group view as well as rotate individual images. Image Kit also provides a gateway for browsing, previewing, and setting Core Image filters on an image.

OpenGL Improvements

OpenGL is the industry-standard API for developing portable, interactive 2D and 3D applications. Mac OS X has supported OpenGL from the outset and in Leopard it adds pixel buffer objects, color managed texture images in the sRGB color space, and improvements in the shader programming API.

Leopard also provides a dramatic increase in OpenGL performance by offloading CPU-based processing onto another thread which can then run on a separate CPU core feeding the GPU. This can increase, or in some cases, approach double the performance of OpenGL-based applications.

QuickTime Improvements

Working with video using QuickTime has long been a strength of Mac OS X. Now, it’s as easy to build video capture into our application as it is to work with pre-recorded video. By using the QTKit Capture API, we can capture video from an iSight, USB (VDC) and FireWire (IIDC) devices, and DV cameras. The API even lets us output to multiple outputs.

QuickTime’s plumbing has received significant upgrades in Leopard. There have been significant enhancements in handling the H.264 encoding. And QuickTime now supports 64-bit. Note that the functionality for 64-bit QuickTime is only provided via the QTKit framework. The C-based QuickTime API is supported in 32-bit mode.

Picture Taker Panel

Mac OS X has used images in many applications for a while. For example, when we first set up Mac OS X, it will take our picture if we have a camera built-in or attached. Leopard exposes the ability to take a user’s picture to any application using the Picture Taker Panel. It will handle all the details of whether a user has a camera built-in or plugged in as well as providing a flash. In short, we can open the Picture Taker Panel and, once the user is satisfied with their picture, our application will be handed a picture return value.

OS Foundations

The heart of Mac OS X, the Open Source Mach- and BSD-based UNIX layer known as Darwin, continues to see improvements in Leopard. The latest Mac hardware brings more processing power, more cores, and more memory than ever before. The kernel in Leopard has been updated to take advantage of this new hardware.

Leopard certainly won’t be UNIX in name only. Apple will submit Leopard and Leopard Server to The Open Group for certification against the UNIX ‘03 product standard.

64-bit Support in Leopard

First implemented at the UNIX level in Tiger, Leopard brings 64-bit support to the Mac OS X application level. We can create 64-bit applications that can address extremely large data sets, up to 128TB using the current Intel-based CPUs. The 64-bit model used in Mac OS X is known as LP64 and is the same model used by other 64-bit UNIX systems from Sun and SGI as well as 64-bit Linux.

And there’s more: the 64-bit support in Mac OS X maintains the ability to run current 32-bit applications. On Intel processors, 64-bit applications have an increased number of CPU registers available in 64-bit mode, and they may run faster than their 32-bit counterparts.

Information Technology

Mac OS X and Mac OS X Server provide a rich set of features and enable a rich set of solutions. Each version of Mac OS X Server has made impressive leaps in functionality while offering easy to use management tools. Leopard provides the most powerful version of Server, built on a host of open source products and tools that make it a server for anyone from sysadmins to IT managers to developers maintaining a lab of test and development Macs.

Best of all, Leopard Server is a superset of Leopard. That means it uses the same kernel and supports the same 64-bit capabilities. Building on top of Leopard’s 64-bit frameworks, all of the services in Leopard Server are 64-bit enabled. This means that they will be able to take advantage of massive amounts of memory as well as enjoy performance increases on Intel-based 64-bit processors.

Open Directory 4

Leopard Server ships with an updated version of Open Directory that supports LDAP proxying, cross-domain authorization, cascading replication, and replica sets. It even supports RADIUS authentication for AirPort base stations deployed across our office or campus.

Calendaring Server

The Darwin Calendar Server allows users to collaboratively share calendars across an organization. It provides a shared location to store their schedules and sync them between machines. It also allows users to send each other invitations to events. Implemented using the CalDAV protocol, it supports multiple calendaring clients, including Leopard’s iCal, Mozilla’s Sunbird, OSAF’s Chandler, and Microsoft Outlook.

Ruby on Rails

Leopard Server features a built-in installation of the powerful and productive Ruby on Rails web application framework. Ruby on Rails is a full stack framework optimized for sustainable productivity. Leopard Server will ship with Mongrel for simplified development and deployment of web-based applications.

Pretty Basic Mac Stuff

January 20, 2008

If you have ever looked at your Mac’s root directory and wondered what some of those other directories are for, you’re probably not alone. Mac OS got a whole lot more complex with the advent of OS X, adapting a unix file structure that is largely unfamiliar to Mac OS 9 and Windows users. So just what is /System, /Library, /usr, and all the others for anyway? Here’s a brief explanation of each directory as found in Mac OS X.

By default, if you look in the root of your Mac’s hard disk you’ll see some unfamiliar sounding directories. From the command line, you will see even more if you type ls /. Explained in no particular order:- Directory followed by the Description

/Applications Self explanatory, this is where your Mac’s applications are kept
/Developer The Developer directory appears only if you have installed Apple’s Developer Tools, and no surprise, contains developer related tools, documentation, and files.
/Library Shared libraries, files necessary for the operating system to function properly, including settings, preferences, and other necessities (note: you also have a Libraries folder in your home directory, which holds files specific to that user).
/Network largely self explanatory, network related devices, servers, libraries, etc
/System System related files, libraries, preferences, critical for the proper function of Mac OS X
/Users All user accounts on the machine and their accompanying unique files, settings, etc. Much like /home in Linux
/Volumes Mounted devices and volumes, either virtual or real, such as hard disks, CD’s, DVD’s, DMG mounts, etc
/ Root directory, present on virtually all UNIX based file systems. Parent directory of all other files
/bin Essential common binaries, holds files and programs needed to boot the operating system and run properly
/etc Machine local system configuration, holds administrative, configuration, and other system files
/dev Device files, all files that represent peripheral devices including keyboards, mice, trackpads, etc
/usr Second major hierarchy, includes subdirectories that contain information, configuration files, and other essentials used by the operating system
/sbin Essential system binaries, contains utilities for system administration
/tmp Temporary files, caches, etc
/var Variable data, contains files whose contents change as the operating system runs

Blogged with Flock


A new approach to classifying bugs

January 20, 2008

Got an interesting mail so thought Id share it with eone.

Developers always have an issue with QA classifying bugs – The general trend has been to classify an issue based on how much of functionality a particular bug blocks/prevents the user from accessing. But consider this new approach – Though it made us go nuts initially with almost all minor bugs suddenly getting promoted to blockers, I feel it’s a very interesting approach – Let me know what you think.

Trivial – Not likely to Business/Power user bump into it, because it requires some prior and rather technical configuration or high level technical background. So in general until now, if a particular key combination(keyboard short cut) crashed the app, QA would consider it a blocker. But with this approach the QA would need to look at what is the probability of someone using that key combination, and if it is rare it would only be a trivial issue!

Minor – Not likely to Business/Power user bump into it, because it requires medium technical background.

Major – Business/Power user with little technical background might bump into it after several hours of interacting with the tool.

Critical – Business/Power user with no technical background at all, might bump into it after a few hours session with the tool.

Blocker – Very likely that Business/Power user with no technical background at all, will bump into it in the first couple of hours with the tool. So, until now you might consider a ‘spelling mistake’ on the front page to be a minor issue, but with this approach it becomes a blocker!!!!

A complete turn around – but for the marketing team it means they can sell the product better! What do you think?

Blogged with Flock


Locking the Screen on a Mac

January 20, 2008

Applications–> Utilities–>Keychain Access


Check – Show Status in Menu Bar

The Lock icon shows up on the system menu bar.

Blogged with Flock