Google Mac Blog

Upload Your Photos, Download Your Albums

2009-06-18T09:46:00.000-07:00

By Greg Robbins, Software Engineer

In December, the Picasa Web Albums Uploader added support for downloading a photo album to your Mac. We've recently updated the Uploader to include the ability to download all photos from all albums in your account. To start the download, sign in to your account with the Picasa Web Albums Uploader application and select the Existing Album tab. Holding down the Mac's Option key will change the title of the Download Album button to Download All. Then one click will bring all of your albums home.

This update also improves reliability of the uploader's iPhoto export plug-in. The uploader typically keeps itself up-to-date, but you can also get the latest version, 1.3.1, from the download page. Please let us know how it works for you in the Mac Uploader area of the Picasa Help forum.

Introducing Google Quick Search Box

2009-06-09T13:55:00.000-07:00

When most people think of Google, search comes to mind – and rightly so! Hundreds of millions of people have come to know and love Google.com as their starting point for searching the Internet. About 2 years ago, we introduced Google Desktop to extend Google search capabilities to your Mac and, earlier this year, we launched a developer preview of the next evolution of search outside the browser. Today, we're officially releasing this technology to all users as the Google Quick Search Box (or QSB for short).

With Google Quick Search Box you can search for information from just about anywhere. As you type, suggestions will appear that match your query, ranging from applications and local files on your computer, to web search and navigational suggestions, to items from your browser history and contacts - and the types of results you can get will only grow over time! Check out the screenshot below for an example of the types of blended results you might see.

Once you've found the result you want, we wanted you to be able to DO something with it. To find out what you can do, select a result and press the tab key or the right arrow on the keyboard. Some examples of actions include instant messaging friends, playing a song, or emailing a URL. Just like the data you can search over, the list of actions you can perform will grow over time!

The quickest way to launch the Google Quick Search Box is by pushing Control + spacebar at the same time (Google Desktop devotees will still be able to press Command twice to summon the box). If you prefer another keyboard shortcut to summon the Google QSB, you can change it in the Preferences panel.

As you use the Google Quick Search Box more, it will learn which results you are likely to want. The goal here is that we get you to what you're looking for as quickly as possible. In the above example, if you chose Google Calendar, the next time you search for "cal", Google QSB will reorder the results so that you don't have to arrow down to your desired choice. Instead, you can just type "cal" and press enter.

Last, but definitely not least, the Google Quick Search Box is extensible. This means that anyone can create a plug-in that enables the QSB to search over additional data or perform more actions on results. As an example, we really enjoy the Twitter plug-in . After enabling that bad boy, we can send tweets right from the QSB and then do a Google search right after!

The Google QSB has allowed us to do our daily tasks faster. If you want to give it a try to see it speed up your day, visit www.google.com/quicksearchbox/.

If you're a Google Desktop user and you want to gain this functionality, you can learn more about Google QSB and see how to upgrade in this help center article.

And please, let us know what you think!

Posted by Ryan Tabone and Karen Grünberg, Product Managers

Mac OS X Spelunking in PowerPC and x86 Assembly, part 2

2009-06-04T11:53:00.000-07:00

By Avi Drissman, Google Chrome Team

(Note: this is another of our occasional extra-geeky technical posts. If this isn't your thing, don't worry; our usual non-technical stuff will be back soon.)

Welcome back. In our last post we went through a simple function that made calls to other functions, and touched on stack frames and parameter passing. This time let's talk about a different function. We'll focus less on the things we've seen, and more on some more advanced actions that this function does.

UpdateDockTitle

PowerPC

<+0>: mflr    r0               // save linkage
<+4>: stmw    r28,-16(r1)      // stash r28, r29, r30, r31
<+8>: mr      r30,r3           // save r3 (WindowData)
<+12>: bcl-    20,4*cr7+so,0x928d2bd4 <+16>
<+16>: mflr    r31            // get ip in r31

Whoa... what?

Short story: <+12> is an unconditional branch-and-link.

Long story: On the PowerPC, instructions like bge, etc. are just aliases to a more primitive branch instruction, bc (branch conditional). In this case, the first parameter is 20 (0b10100), which indicates “branch always”. Since it's always going to branch, the second parameter doesn't matter, so it was set to all 1 bits (which translates to 4*cr7+so).

Why do this? Because we're going to need to access some PC-relative data, and the PowerPC chip has no PC-relative addressing mode. And the register move instructions can't access the PC register. Therefore we cheat in a way by taking an unconditional jump to the next address. Since it's a branch and link, the link register is filled with the next address (in this case, that equals the address just jumped to) which can be moved to a normal register.

Why branch-conditional with a condition “branch always”? The b opcode only provides absolute addressing. Only bc has relative addressing.

<+20>: stw     r0,8(r1)
<+24>: stwu    r1,-80(r1)     // make stack frame
<+28>: addis   r28,r31,3533
<+32>: bl      0x928d2c50 <_Z15GetTitleForDockP10WindowData>
<+36>: lbz     r0,-3364(r28)  // haul initialization boolean into r0

This is where intuition comes in. We're hauling in some random byte from a PC-relative address. (lbz is load byte and zero, which loads one byte from memory and clears the high bits.) What's byte sized? A Boolean (the Carbon type; GCC makes C++ bools 4 bytes). Why a Boolean? Probably a flag. And with the value of the byte gating the call to RegisterAsDockClientPriv, it's a safe bet that it's an initialization flag.

<+40>: mr      r29,r3         // stash new title into r29
<+44>: cmpwi   cr7,r0,0       // was initialized?
<+48>: bne-    cr7,0x928d2c04 <+64> // if so, skip
<+52>: bl      0x9287f864 <_Z24RegisterAsDockClientPrivv> // else initialize
<+56>: li      r0,1           // and set flag
<+60>: stb     r0,-3364(r28)  //   as being intialized
<+64>: mr      r3,r30
<+68>: mr      r4,r29
<+72>: bl      0x928d2c68 <SyncPlatformWindowTitle> // call with (WindowData, new title)
<+76>: lwz     r0,344(r30)    // pull (WindowData + 344)
<+80>: andis.  r2,r0,64       // and pull a flag bit out of it (minimized?)

More intuition here. r30 contains a pointer to the WindowData class instance, and we're accessing some word 344 bytes in. We don't care about the destination register (we don't touch r2 again this function) but don't miss the name of the opcode: “andis.” Remember that the period means to update cr0.

Once again, this is obviously a flag (bit-sized this time). But what does it mean? Context tells us that we only call CoreDockSetItemTitle when it's set. Thus, it's a safe guess that this is the is-minimized flag.

<+84>: beq-    0x928d2c38 <+116> // if not minimized, skip this step
<+88>: addi    r1,r1,80
<+92>: lwz     r3,196(r30) // load WID

How do I know that WindowData+196 is the CoreGraphics WID (CGWindowID; see CGWindow.h)? I used Quartz Debug to look at the window list for a sample app. The app only had one window, and the listed WID matched.

<+96>: mr      r4,r29 // load new title
<+100>: lwz     r0,8(r1)
<+104>: lmw     r28,-16(r1) // tear down stack frame
<+108>: mtlr    r0
<+112>: b       0x92b58ce4 <dyld_stub_CoreDockSetItemTitle>

Note that we're tearing down the stack frame twice. In this case we're tail calling CoreDockSetItemTitle so that it's as if our caller called them directly. This is equivalent to the code return CoreDockSetItemTitle(wid, newTitle). Note from the setup of r3 and r4 that we can deduce the parameter types. Can we figure out the return type, though? Not really. The calling code ignores it, so we can ignore it too.

<+116>: addi    r1,r1,80
<+120>: li      r3,0
<+124>: lwz     r0,8(r1)
<+128>: lmw     r28,-16(r1)
<+132>: mtlr    r0
<+136>: blr

x86

<+0>: push   %ebp                   // make stack frame
<+1>: mov    %esp,%ebp
<+3>: sub    $0x28,%esp
<+6>: mov    %ebx,-0xc(%ebp)        // save %ebx
<+9>: call   0x92e4bbe4 <+14>
<+14>: pop    %ebx                 // IP > %ebx

We're doing the same trick here to get the PC into a register and I'm a bit stumped as to why. From what I know, the x86 has PC-relative addressing, and surely there's got to be a better way to get the PC into a normal register. Right?

<+15>: mov    %esi,-0x8(%ebp)      // save %esi
<+18>: mov    0x8(%ebp),%esi       // WindowData > %esi
<+21>: mov    %edi,-0x4(%ebp)      // save %edi

This almost looks like it was compiled by a different compiler. In the previous function, edi and esi are pushed, and then the stack pointer dropped. Here, we create the stack space and then move the contents of three registers (edi, esi, and ebx). I suspect that things change once we also have to save ebx, though I don't know why.

<+24>: mov    %esi,%eax            // %esi (WindowData) > %eax
<+26>: call   0x92e4bc40 <_Z15GetTitleForDockP10WindowData>

Whoa. If we're calling a function we need to set the parameter via stack-relative addressing off esp. What's going on here?

The point of an ABI is that it's a documented way for functions to call each other. But if a function, say GetTitleForDock(WindowData*), is a short one that's not public and is only used under controlled circumstances, why worry about setting up the stack? In this particular case, GetTitleForDock happens to be a nine-instruction routine. Not worth the hassle of a stack frame, so it's reasonable to pass in the one parameter in eax.

<+31>: cmpb   $0x0,0xd51a36c(%ebx) // test initialization boolean
<+38>: mov    %eax,%edi            // window title > %edi
<+40>: jne    0x92e4bc0c <+54> // if initialized, skip
<+42>: call   0x92df9fe0 <_Z24RegisterAsDockClientPrivv> // else initialize
<+47>: movb   $0x1,0xd51a36c(%ebx) // and set flag as being initialized
<+54>: mov    %edi,0x4(%esp)       // new title (param 2)
<+58>: mov    %esi,(%esp)          // WindowData (param 1)
<+61>: call   0x92e4bc52 <SyncPlatformWindowTitle>
<+66>: xor    %eax,%eax            // clear %eax (noErr?)
<+68>: testb  $0x2,0x159(%esi)     // test flag (WindowData + 0x159) (minimized?)
<+75>: je     0x92e4bc35 <+95> // if not minimized, skip this step
<+77>: mov    %edi,0x4(%esp)       // new title (param 2)
<+81>: mov    0xc4(%esi),%eax      // (WindowData + 0xC4) WID
<+87>: mov    %eax,(%esp)          // (param 1)
<+90>: call   0xa0a52ad1 <dyld_stub_CoreDockSetItemTitle>
<+95>: mov    -0xc(%ebp),%ebx
<+98>: mov    -0x8(%ebp),%esi
<+101>: mov    -0x4(%ebp),%edi
<+104>: leave
<+105>: ret

Conclusion

Poking around in assembly isn't usually something you do every day. But whether you need it for debugging your own code or exploring someone else's, it's a skill that is definitely worth learning. PowerPC and x86 processors might have had a bit of a different history, but the code that's generated for either is certainly not as intractable as some suggest.

Where to go from here? Look around some more. Use otool -tV to dump binaries and see what they do. Use nm to see which symbols are exported from frameworks and watch how they work.

Go exploring, and have fun.

(Thanks to my editor, Scott Knaster, and to David Shayer, whose introductory session on PowerPC assembly at the legendary MacHack conference started me on this path.)

Google Chrome, Sandboxing, and Mac OS X

2009-06-02T10:28:00.000-07:00

By Scott Knaster, Google Mac Team

Interested in news about Google Chrome for Mac OS X? Google Chrome for the Mac is coming along fine, and for the technically inclined, Jeremy Moskovich of the Google Chrome team has written a blog post explaining how the developers implemented sandboxing, an important Google Chrome feature. To find out more, please check out Jeremy's post.

Mac OS X Spelunking in PowerPC and x86 Assembly, part 1

2009-05-26T16:11:00.000-07:00

By Avi Drissman, Google Chrome Team

(Note: this is one of our occasional extra-geeky technical posts. If this isn't your thing, don't worry; our usual non-technical stuff will be back soon.)

If you're a programmer, there are many reasons why you might want to go exploring the inner workings of Mac OS X. You might want to learn how how Apple achieves interesting effects. Or perhaps you're just curious about how things work. (We're all adults here, so I won't lecture you about the dangers of using private or undocumented interfaces in your apps.)

In any case, though, you need to know how to read assembly, either PowerPC (if you have an older Mac) or x86 (if you have anything recent). While there are good resources available to learn about reading PowerPC assembly for exploration, there are fewer about x86. Despite the present and future of the Mac being x86, it seems like people have lots of anxiety about having to work with it.

I think the problem is not a lack of documentation on x86 assembly, but a surfeit of it. Most of it is Windows- or DOS-centric, usually with syntax that doesn't apply (Intel syntax vs the AT&T syntax that GCC uses), and with the aim of teaching how to write it. But reading x86 assembly really isn't that hard. If all you want to do is learn how to read the code generated by GCC, it's probably just as easy as PowerPC.

The other day I was investigating how window minimization and window titles work. While exploring, I took notes of my discoveries. Let's touch on two functions, in both PowerPC and x86 flavors.

Before we begin, I'm going to assume that you're comfortable with assembly in general (though not necessarily with any particular one). If you have the latest developer tools, launch Shark (in /Developer/Applications/Performance Tools) and in the Help menu you can access various ISA references. In addition, Apple has ABI documentation for both the PowerPC and x86. I'm going to go over each function twice (once for PowerPC and once for x86); feel free to skim the PowerPC version if you're accustomed to it. And finally, this is only for the 32-bit version of each platform; things change even more with 64 bits.

SetWindowTitleWithCFString

The trail always begins with a public call that uses the SPI that you want to figure out. In this case, I chose SetWindowTitleWithCFString because it has to somehow set the title of a window even if it's minimized. I went with Carbon because sometimes the dynamic nature of Objective-C with Cocoa makes tracing code harder.

PowerPC

<+0>: mflr    r0          // save linkage
<+4>: stmw    r30,-8(r1)  // stash r30, r31
<+8>: mr      r30,r4      // save r4 (new title)
<+12>: stw     r0,8(r1)    // make stack frame
<+16>: stwu    r1,-80(r1)  // make stack frame

This is the prologue of the function. The PowerPC doesn't have a dedicated stack pointer (convention is to use r1 for that), so the common way of implementing branches by pushing the PC onto the stack doesn't work. Instead, the PowerPC has a link register and a command bl to branch and put the old PC value into the link register. Thus, almost every function starts with mflr r0, to pull the old PC into a usable register. Then in <+4> we save off some registers that we're going to smash. Every function needs scratch registers to hold local variables, and usually the high-numbered registers are used. The stmw (store multiple words) instruction is useful for ditching many high registers on the stack. Then in <+12> we drop the old PC onto the stack and allocate 80 bytes on the stack.

A note on parameter passing. Integer-sized parameters (the only kind we'll be dealing with today) are passed into a function starting with r3 and going up through the registers. Return values are returned in r3. So we see that in <+8> we stick away the pointer to the new name in r30 (whose previous value was stored on the stack earlier).

<+20>: bl      0x92881384 <_Z13GetWindowDataP15OpaqueWindowPtr>
<+24>: li      r0,-5600    // errInvalidWindowRef
<+28>: cmpwi   cr7,r3,0    // if no window data, bail
<+32>: beq-    cr7,0x928d2ae0 <+60>
<+36>: cmpwi   cr7,r30,0   // if no string to set, bail
<+40>: li      r0,-50      // paramErr
<+44>: beq-    cr7,0x928d2ae0 <+60>
<+48>: mr      r4,r30

This is where we must start making inferences as to what the code is doing. Fortunately, we have the symbols so it's not too hard. We see that we use the WindowRef as a parameter to a C++ function GetWindowData(OpaqueWindowPtr), as the WindowRef was passed in as r3 and r3 wasn't altered before the call. In addition, note that the function return value, being in r3, will overwrite the WindowRef value which wasn't saved in a high register. That's fine, as the WindowRef was just an index into a table and won't be needed further.

At this point we run some checks. We compare both r3 and r30 to zero, and if either are zero we jump to the end with r0 set to the appropriate error code. (The end of the function will move r0 into r3 for return.)

The PowerPC condition register has eight condition sets. Why are we using cr7 here? Probably because cr7 is volatile and we can get away with not saving/restoring it.

<+52>: bl      0x928d2af8 <_ZN10WindowData14SetTitleCommonEPK10__CFString>
<+56>: li      r0,0        // return noErr
<+60>: addi    r1,r1,80    // tear down stack frame and return
<+64>: mr      r3,r0
<+68>: lwz     r0,8(r1)
<+72>: lmw     r30,-8(r1)
<+76>: mtlr    r0
<+80>: blr

The rest is pretty simple. We call a member function WindowData::SetTitleCommon(CFString*), and then do common tear down. We restore the stack pointer, put the return value into r3, restore the registers, move the old PC back into the link register, and branch to the link register (blr), returning us to our caller.

x86

The PowerPC register file is really easy: r0, r1, r2 ... r31. x86 has fewer registers and they've historically had different roles (accumulator, base, source index, destination index, and so on). Seriously, forget about that. There are eight registers you care about. eax, ebx, ecx, edx, esi, and edi are all general-purpose registers. esp is the stack pointer. ebp is the frame pointer. That's it.

PowerPC assembly reads right-to-left (except for stores). x86 AT&T syntax in general reads left-to-right.

<+0>: push   %ebp             // make stack frame
<+1>: mov    %esp,%ebp        // make stack frame
<+3>: push   %esi             // stash %esi
<+4>: sub    $0x14,%esp       // make stack frame

x86 is stack-based. Parameters to a function are put at the top of the stack, and the rightmost parameters have the highest addresses. To execute the function, the call instruction was used. This instruction pushes the PC onto the stack, so even before we hit <+0> the parameters are four bytes above the stack pointer. In <+0> we save off the old stack frame value and in <+1> we establish our stack frame. At this point ebp is fixed for the entire function. In <+3> we save the old values of registers we're going to use, and in <+4> we allocate space on the stack.

This is a perfect example of an ideal stack frame. ebp is the frame pointer. It points (to the stack) at the old frame pointer. ebp+4 is the PC of the function that called us. ebp+8 is the first parameter passed in, ebp+12 is the second, etc. Immediately below ebp are the values saved from the registers, which will be restored before the return. And below that is a bunch of stack space used for either register spillage or calling subsequent functions. One interesting note is that rarely are parameters pushed onto the stack for a call. The stack pointer doesn't move once we make it past the prologue. We just set the memory right above esp (the stack pointer) and make the call.

<+7>: mov    0x8(%ebp),%eax   // get WindowRef in %eax
<+10>: mov    0xc(%ebp),%esi   // get new title in %esi

The parameters are passed on the stack. Since fiddling in memory is slow, we pull the values into registers. It's actually pretty analogous to how things go in PowerPC. There, lower registers like r3 are reused for parameter passing so important values are kept in the high registers. On x86 the parameters go on the stack and values are kept in registers when possible. Why eax and esi? Why not?

<+13>: mov    %eax,(%esp)      // put WindowRef on the stack
<+16>: call   0x92dfb8f6 <_Z13GetWindowDataP15OpaqueWindowPtr>

With the PowerPC, you can tell how many parameters a function has by seeing how many registers starting with r3 are loaded. Here, we just look at the register indirect addressing with esp.

<+21>: mov    %eax,%edx        // stick WindowData into %edx
<+23>: mov    $0xffffea20,%eax // errInvalidWindowRef
<+28>: test   %edx,%edx        // if no window data, bail
<+30>: je     0x92e4bb04 <+54>
<+32>: test   %esi,%esi        // if no string to set, bail
<+34>: mov    $0xffce,%ax      // paramErr
<+38>: je     0x92e4bb04 <+54>

Return values come back from functions in eax, but otherwise this is pretty much the same. The only thing of interest to note is the clever use of the peculiar register structure. In <+23> the constant 0xffffea20 is loaded into eax. But on <+34> the constant 0xffce is loaded in ax. But since ax is just an alias for the lower 16 bits of eax, the upper half of the word is left as 0xffff and we get the full constant 0xffffffce in eax. Why do this? Because loading a 32 bit constant takes 5 bytes while loading a 16 bit constant only takes 4.

<+40>: mov    %esi,0x4(%esp)   // load new title as param 2
<+44>: mov    %edx,(%esp)      // load WindowData as param 1
<+47>: call   0x92e4bb0c <_ZN10WindowData14SetTitleCommonEPK10__CFString>
<+52>: xor    %eax,%eax        // return noErr

Same stuff as before. The one note is the zeroing of eax with an xor. Just a fancy trick as the generated code is faster and smaller than the equivalent mov $0x0,%eax.

<+54>: add    $0x14,%esp       // tear down stack frame and return
<+57>: pop    %esi
<+58>: leave
<+59>: ret
<+60>: nop
<+61>: nop

The mirror image of the stack frame creation.

That's one function down and one left to go. Next time, we'll take a look at a function that behaves a little differently than this one did.

Google Spreadsheets power gFlashPro Flashcards for iPhone

2009-05-23T15:28:00.000-07:00

Guest post by Mike MacDonald, Founder and CTO, gWhiz LLC

gFlashPro, the first offering in the iPhone App Store from our company, gWhiz, is a popular mobile flashcards application used by students of all ages to study on the go. Google Spreadsheets provide a key element of the gFlashPro architecture.

To create a gFlashPro flashcard set, students or teachers open up a new Google Spreadsheet and put questions in the first column, and answers (including multiple choice) in the adjacent columns. Meta-data (set description, search tags, runtime options, and so on) isn't required, but can be entered into a separate worksheet as simple key-value pairs. Then, on the iPhone or iPod touch, from within gFlashPro, users are given a list of the available flashcard sets (i.e., spreadsheets) for easy download. Alternatively, they can select flashcard sets from our catalog: a searchable repository of thousands of shared flashcard sets covering virtually any subject.

Once selected, the card set (spreadsheet) is downloaded into gFlashPro and presented to the user for mobile study and quizzing.

A few reasons we chose to use Google Spreadsheets:

We didn't want to have to write our own server-side flashcard creation code. If we "rolled our own", it would have been code that we'd need to maintain going forward. Using Google Spreadsheets allowed us to leverage the strength of Google's development team, the many built-in functions (e.g., importing .xls), and in the future, Google Gadgets.
Google's server infrastructure reliability is far better than anything we could possibly afford.
User authentication is handled by Google. While this is not a huge problem, it's just one more thing that our small development team doesn't need to deal with.

And a few lessons learned:

There are document limits for each account. In our case, the number and storage of documents is distributed across many thousands of users. Having a shared document in your account doesn't count against that limit.
While the Objective-C libraries for connecting to Google Docs are incredibly powerful, they are also fairly heavyweight for content-heavy apps like ours. We found that flashcard sets with more than 300 rows would blow out memory on the iPhone because of the substantial number of objects being created for each spreadsheet cell. One alternative we're considering in another application is to write our own XML parser to exclusively process spreadsheet data coming from Google.

Any questions? Just email us at info@gwhizmobile.com.

Updated Gmail and Calendar for iPhone

2009-04-07T10:56:00.000-07:00

Today I'm happy to announce that we've updated Gmail and Calendar for the iPhone. We've completely re-architected the code so you get more consistent performance, refreshed the user interface so it's easier to perform batch actions, and most importantly, laid the foundation which will allow us to iterate quickly and provide you with performance improvements and new features in the future.

To find out more about how you can get all the Gmail goodies, like threaded conversations, search, starring and labels, all on your iPhone, head on over to the Google Mobile Blog. Or, if you're convinced and want to try it out now, go to gmail.com on your iPhone. Click the Calendar link at the top to access Google Calendar. Please note that only iPhone OS 2.2.1 or higher is supported. We're rolling out this release over the next few days, so if you don't see the updated user interface, check back soon.

Posted by Deng-Kai Chen, Google Mobile

Using Google APIs in an iPhone App

2009-03-25T17:20:00.000-07:00

Guest post by Tom Saxton, Idle Loop Software Design

In September, my small software company shipped our first iPhone app, a grocery list program called Grocophile. One of the most common requests from our users was the ability to exchange data over the Internet. Greg Robbins of Google's Mac team suggested that the Google Docs API might be useful, so I jumped in and took a look.

This turned out to be a great way to give our users access to free Internet storage, letting them back up their data and share it across multiple devices. To return the favor, I'd like to share my experience: the learning process, getting the code working on the iPhone, and how I found what I needed from what Google generously provides.

Greg helped me get started by pointing out some online resources. I started with the Objective-C library's overview slideshow. Then I read the Objective-C client introduction, which explains how to get the Google Data APIs library into an iPhone Xcode project. Finally, I downloaded the library sources.

There's a sample app that you'll get with the sources that shows how to talk to Google Docs. The file of interest is DocsSampleWindowController. Start by looking at the two methods "uploadFileAtPath:" and "saveSelectedDocumentToPath:", as those demonstrate how to upload and download files, respectively.

The code is part of a Mac OS X Cocoa app, so it has some Mac-specific code intermingled with the GData code. To bring it into an iPhone project, I trimmed out the Mac user interface stuff, and defined a class and a protocol to create code that should work from any Mac or iPhone application.

The library requires several steps to upload or download a file. First, you create a service object that encodes the user agent that identifies your application, along with the username and password for the account you want to access. Then use that object to request a document list feed, which is the list of documents in the user's account.

Retrieving the document list feed both validates the account credentials and captures information you'll need to either upload or download files. The feed contains the URL for downloading each document. To download, you can use any http call such as NSURLConnection or the library's GDataHTTPFetcher. The feed also has the URL for uploading new document entries.

The networking operations are asynchronous, so my encapsulating object has methods for starting an upload or download, then uses an Objective-C protocol to inform the controlling object of the progress and status at completion.

I've been calling these document objects files, but Google Docs isn't a file system. It's much more like a web publishing system: a collection of objects with associated metadata including title, creation and modification dates, and so on.

The first difference from a file system that I encountered is that you can have multiple different files with the same name. So, if you just upload a new version of a file the same way you uploaded it the first time, you'll get a second document with that same name. To avoid that, search for the document entry with the title that you want to upload to. You can then request an update operation instead of an insert.

The second issue I discovered is that much like when you post to a blog, what you upload can get transformed to match the type of document that is holding the data. When you download the same object, you get something different than what you uploaded. For example, I uploaded a plain text document (specified by MIME type "text/plain"), but when I downloaded that same object I found the text wrapped in a bunch of HTML that makes it display well on the Google Docs web page. Our app's files are UTF-8 XML files created by NSKeyedArchiver. Google Docs fails if you try to specify a MIME type of "text/xml" and totally mangles the document contents if you specify "text/plain". That is not a big surprise because there's not currently a way to specify that the text is encoded UTF-8, and the content gets stuffed into an XML file for the journey to the server.

I solved this issue by converting my files into a plain ASCII encoding, wrapping that in HTML which explains that the file our users see in the Google Docs web page is a Grocophile data file and isn't user editable, and uploading that as "text/html". When I download this file, the HTML does pick up a bunch of Google additions, but it's a simple matter to scan the file to find my encoded document contents.

Different apps will have different needs for storing their documents. If your app can store and retrieve its data in text, HTML or a spreadsheet, then Google Docs will work well for you. Grocophile's data is basically a relational database with a series of tables and joins keyed off of UUIDs. I could represent the data in text, but it would be fragile and not appropriate for end-user editing. Even though our data won't be editable within Google Docs, there's still plenty of value in being able to back up, restore and merge data sets from Grocophile.

To help out other Mac and iPhone developers, I've published my code for using the library in an iPhone application as an open source project. If you have any questions, or suggestions for improvement, please contact me at idleloop.com.

Health and Vigor in a Google Data APIs Library Update

2009-03-17T12:22:00.000-07:00

Posted by Greg Robbins, Software Engineer

If there's a hole in my memory, it's right where the date of my last tetanus shot should be stored. Luckily, Google Health promises to help us keep track of the many medical details in our lives that would otherwise be lost. But stored information only matters if it's accessible when and where we need it. Independent developer Ford Parsons' application Health Cloud provides access to health profiles quickly and conveniently, for iPhone owners anywhere.

Health Cloud is the first released app to use the Google Data APIs Objective-C Client Library's new support for the Google Health Data API. The recent version 1.7 release of the library also offers a variety of performance and memory improvements for iPhone and Mac developers. It still provides easy access to Google Docs, Picasa Web Albums, YouTube, and many other Google services.

If you have an iPhone or an iPod Touch, you can download Health Cloud today to keep your Google Health account handy. Or if you're a Mac or iPhone developer, check out the Google Data APIs Objective-C Client Library open-source project page for an introduction to adding Google services to your products.

What's New for iPhone

2009-02-17T15:11:00.000-08:00

By Jason Toff, Google Mac Team

Over the past few weeks, a number of enhancements have been made to Google's offerings for the iPhone. We wanted to highlight some of those improvements here.

Google Sync Beta
Google Sync allows you to get your Gmail Contacts and Google Calendar events to your phone. Once you set up Sync on your phone, it will automatically begin synchronizing your address book and calendar in the background, over-the-air, so you can attend to other tasks. Sync uses push technology so any changes or additions to your calendar or contacts are reflected on your device in minutes.

Learn more on the Google Mobile blog or try Sync at m.google.com/sync.

Tasks
Tasks lets you easily create and manage to-do lists in Gmail and on your iPhone. While on the go, you can view tasks, add tasks, and mark them as completed. These changes are automatically reflected in Gmail. Using your iPhone, you can also add, edit, and delete entire lists.

Learn more on the Gmail blog or get started with tasks at gmail.com/tasks.

Google Book Search
Over 1.5 million public domain books in the US (and over half a million outside the US) are now available for perusing on your iPhone. You can search for a title, author, or subject. Or you can browse the list of "Featured books" and various categories like business, the classics, travel, and more.

Learn more on the Google Book Search blog or start reading at http://books.google.com/m.

Edit Docs
Last week, we launched new capabilities to Google Docs for your iPhone that allow you to add new rows, edit existing cells, sort by columns, and filter by terms. Now you don't have to wait until you get to your computer to update a spreadsheet.

Learn more on the Google Docs blog or start editing at m.google.com/docs.

Search Without Effort: The Quick Search Box

2009-01-12T18:00:00.000-08:00

By Nicholas Jitkoff and Dave MacLachlan, Google Mac Team

One of our goals at Google is to make your search experience as fluid as possible. While much of our work is focused on Google.com, we're trying to make it just as easy to search outside your browser.

For the last year, we have been working on a new, open-source quick search box. Today, we are releasing our first developer preview for the Mac.

This Mac version is much more experimental than its iPhone sibling, Google Mobile App, and through it you will be able to see many of the areas we are exploring: contextual search, actions, and extensibility. It is by no means feature-complete, but is a very good indication of things to come.

If you are interested in participating in our experiment, head over to the Google Code site and give it a try. We are eager to involve users in the development process and will be posting new builds frequently. Over the coming months we'll be posting a few articles about the architecture and interaction we are exploring, and we look forward to your feedback.

YouTube Upload Booth

2009-01-09T11:58:00.000-08:00

By Jason Toff, Google Mac Team

In addition to the Earth Surfer application, our Macworld booth also features a YouTube Upload Booth this year. Several famed YouTubers stopped in the booth and used Quick Capture to upload their videos to the web. For instance...

Ijustine jumped in the moment she saw it.

Chris Pirillo had some..ahem..difficulties at first but was able to make it work.

And there were many more excited people ready to try it out! Check out the video below to hear more about the YouTube booth:

Surf Through Google Earth

2009-01-08T14:39:00.000-08:00

By Jason Toff, Google Mac Team

This year for Macworld a Google engineer, David Phillip Oster, wrote a fun application that allows you to surf through Google earth. Watch the video below and read more about it on the Google Lat Long blog.

Macworld Has Arrived

2009-01-06T11:05:00.000-08:00

By Jason Toff, Google Mac Team

After months of anticipation, Macworld is finally here! We put the finishing touches on our booth yesterday and look forward to visits from many of the expected 40,000+ attendees.

More than 100 Googlers across several teams-- including Picasa, Mobile, Geo, & YouTube-- will be staffing our booth throughout the four days of the expo (from now until Jan. 9). We have plenty in store for our booth and plan to update this blog regularly-- so stay tuned.

If you're planning to attend, we hope you'll stop by to say hello! And for those of you who can't make it or aren't in the area, we invite you to visit google.com/macworld to explore Google's offerings for Mac and the iPhone.

Picasa's Macworld Debut

2009-01-05T14:15:00.000-08:00

By Stuart Morgan, Software Engineer

Last year we had a blast at Macworld demonstrating all our Mac products, but as Mac users, we also know that the best part of Macworld is new product announcements. This year, we're getting in the spirit by making a little announcement of our own: we're happy to say that Picasa, Google's photo management software, will be joining the ranks of the free Mac OS X applications from Google!

If you've never tried Picasa before, it's a program that helps you manage, edit, and share your photo collection. It works especially well with Picasa Web Albums, Google's free photo-sharing site, so it can help you manage the photo albums you've shared online with friends and family as well as the photos on your computer. In addition to photo editing tools, the Picasa client includes features like automatic web sync, fast and simple sharing, collage making, and simple movie editing. And on the web side, Picasa Web Albums offers unique features like name tags, which help you automatically organize your photo collection based on the faces in each picture.

You'll notice that Picasa for Mac is still in Google Labs and has a "beta" label attached—a few minor features like geotagging and webcam capture aren't functional yet, and we plan to sand and polish some parts of the user interface to make sure Picasa feels right at home on Mac OS X. Still, we think you'll find plenty to like in this first beta, and we're excited to get this release out into the hands of the Mac community at this year's Macworld! We're looking forward to making Picasa for the Mac even better, and to hearing what you think — Picasa engineers will be at the Google booth's demo stations throughout Macworld, and we always listen to the feedback on our Help Forum.

There's plenty more to say about Picasa on the Mac, so check out the video below, swing by the Google Photos blog to learn more and download a copy to play with—and of course, come see us at Macworld!

One Week Until Macworld

2008-12-29T14:00:00.000-08:00

By Jason Toff, Google Mac Team

With one week until the start of Macworld, we wanted to give you a glimpse of what to expect at Google's booth.

At any given time, there will be plenty of Googlers at our booth available to answer questions about any Google software made for Mac or iPhone. Demo stations will be placed throughout the booth so that attendees can try out Google software on their own, and in many cases, talk to the people who helped create that software.

Additionally, there will be larger presentations in the booth each day covering specific topics in more depth. Our goal is to make these presentations as interactive as possible, so we are hoping for feedback from Macworld attendees in the booth on the topics they'd like to see discussed.

We are very excited about Macworld and hope that you'll stop by our booth if you're in the area!

Google at Macworld Expo

2008-12-08T16:37:00.000-08:00

By Jason Toff, Google Mac Team

I'm thrilled to officially announce Google's presence at the upcoming Macworld Expo (taking place January 5-9, 2009). We had a great time last year (see picture of our booth below), and we're excited to share our range of offerings for Mac and iPhone with everyone who can make it this year.

With exactly one month to go, we are busy preparing fun demonstrations for the 50,000+ expected Macworld attendees. Stay tuned in the coming weeks for previews of what to expect this time.

And if you'd like to come see us and don't yet have a pass to Macworld, use this link and code for 20% off the Expo Hall pass.

Bringing Your Photos Home

2008-12-08T14:34:00.000-08:00

By Greg Robbins, Software Engineer

The Picasa Web Albums Uploader makes it easy to share your photos and videos with friends and family. But occasionally you may want to use it in reverse, and download an album back to your computer. If you've ever had a hard drive crash or had to work from a new computer, you know how important it is to get your photos back.

The latest release of the Picasa Web Albums Uploader application makes downloading photos as easy as uploading. After you sign in to your account, select the Existing Album tab, choose an album and click the Download Album button. You'll soon have copies of your photos in a new folder on your Mac.

If your copy of the Picasa Web Albums Uploader hasn't updated itself to the latest version, 1.3, you can get it now from the download page. The album download feature is available only in the Picasa Web Albums Uploader application, not in the iPhoto Exporter. This release downloads photos, but not yet videos. You can give us feedback about the uploaders at the Picasa Help forum.

Google Earth Browser Plugin

2008-12-04T08:25:00.000-08:00

By Scott Knaster, Google Mac Team

The very cool Google Earth Browser Plugin is now available for Mac OS X. Read all about it in our Geo Developers Blog.

Google.com/mac now available in 10 languages

2008-12-03T20:00:00.000-08:00

By Jason Toff, Associate Product Marketing Manager, Google Mac Team

As a new member of the Google Mac team and a diehard Apple and Google fan, there are few places on the web that get me as excited as google.com/mac. But until now, non-English speakers had been unable to view this page in their native languages.

Today, I'm happy to let you know that many more people all over the world can take advantage of google.com/mac, as it is now available in 10 languages: German, Spanish, French, Italian, Dutch, British English, American English, Japanese, Chinese, and Taiwanese. Enjoy!

Google Calendar now supports Apple iCal

2008-12-01T16:46:00.000-08:00

By David Besbris, Engineering Director

The Google Calendar team is proud to announce the public release of our support for the CalDAV protocol. You can now use Apple iCal with your Google Calendar, so you can work even when you're offline, sync almost instantly, respond to invitations from others and see the free/busy data of your friends and coworkers.

We launched CalDAV support to our developers last July for feedback, and since that time a few of us whipped up a nifty setup program for iCal. This tool makes it a breeze to get iCal working with your Google account. We've released this as open source and the program is available for download at our Google Code site.

Vocito (Voe-kee-toe)*

2008-11-18T15:44:00.000-08:00

By Dave MacLachlan, Google Mac Team

For those of you who are lucky enough to be be part of the GrandCentral Beta Program, there's a new toy on the Google Mac Playground. Vocito* is a quick dialer that lets you dial your phone directly from your desktop.

Vocito is also integrated into Address Book, QuickSilver, and Automator, and is fully AppleScriptable.

The AppleScript connection makes it easy to have Vocito automatically dial your phone from just about any application that supports scripting or Automator actions. For example, you can easily set up your iCal meeting appointment to automatically dial the conference call for you at the correct time.

Since GrandCentral is currently in a limited beta, we don't have any more invites to hand out right now. So those of you without a GrandCentral number don't get to play just yet, so please reserve your number now to get in on the action as soon as more invites become available.

Vocito is available here for download. It works on Tiger and Leopard, is both PowerPC and Intel native, and is fully open sourced. There is a discussion group at vocito-discuss on Google Groups.

* Vocito is "call" in Latin. According to most scholars, Latin speakers used a hard 'c' (sounds like an English 'k') as opposed to the soft 'c' (sounds like an English 'ch') used by Italians and the Catholic Church. We decided to go with the hard 'c' to give us some street cred with all the Latin scholars out there. If it was good enough for Julie, it's good enough for us.

Just say it! Searching by voice with the new Google Mobile App for iPhone

2008-11-14T11:47:00.001-08:00

Posted by Bill Byrne, Mobile UI Witch, Google

Call me lazy, but sometimes I just don't have the time or the patience to type a search query on my iPhone. Well, no more excuses. With the new release of the Google Mobile App for iPhone, I can just hold the phone to my ear, wait for the tone and say stuff like "Indian restaurants." And just like that, I'm looking at a bunch of places that will easily satisfy my craving.

And, of course, while I'm enjoying my Tandoori chicken, I can use the voice search feature to settle important disputes with my friends without ever having to lift a finger. I say "lyrics to Purple Haze" and Google quickly proves I was right. Ha ha! "How much wood COULD a woodchuck chuck?" I knew it! "Where HAVE all the flowers gone?" Wow. Didn't know that one.

The new release can also make use of my current location when I search. So whether I'm in San Francisco, Chicago, or New York City, "Indian restaurants" is all I have to say to get my next Tandoori chicken fix.

Just remember not to search with your mouth full. It's going to be harder now, for sure.

To get the latest Google Mobile App for iPhone, go to the App Store and search for "Google Mobile App." Note that voice search will be enabled by default for U.S. English users only. You can learn more about the new Google Mobile App for iPhone on the Google mobile blog and by watching this overview video:

Google Earth for iPhone

2008-10-27T09:12:00.000-07:00

By Scott Knaster, Google Mac Team

Google Earth is now available for the iPhone! And it's free, of course. Read all about it at the Google Mobile Blog.

Your data, on the web and at your fingertips

2008-10-23T17:03:00.001-07:00

By Greg Robbins, Google Mac Team

More of Google's web services are allowing you to manage your personal information. Since the freedom to access and control your data is one of our core principles, Google Data APIs are keeping up with the personalization trend. Google Book Search, for example, lets you keep track of your own library of favorite books. The Book Search Data API helps developers create applications that give you access to your library, including the books you've reviewed online. Similarly, there is now an API for Google Finance, so developers can create software that lets you keep tabs on the portfolio you've set up with Google Finance. Or if you prefer, you can make up a portfolio of the investments that you wish you had, and follow that instead of your actual savings.

The Book Search and Finance Data APIs are part of the new version 1.5 release of the the Google Data APIs Objective-C Client Library. Along with support for the new services, software developers will find this release of the library offers better compatibility and parsing performance for iPhone applications, and 64-bit compatibility for Mac desktop applications. I hope that this release encourages even more developers to take advantage of Google's services as a part of their applications.

If you would like to see the other open source toys that our Mac team has built for Mac users and developers, please take a look at our Playground.