iPhoto 9.2.1 update fixes 3ivx bug; addresses compatibility with iCloud and iOS 5

AppId is over the quota
AppId is over the quota
Jason D. O'Grady+ developed an affinity for Apple computers after using the original Lisa, and this affinity turned into a bona-fide obsession when he got the original 128 KB Macintosh in 1984.

He started writing one of the first Web sites about Apple (O'Grady's PowerPage) in 1995 and is considered to be one of the fathers of blogging. He has been a frequent speaker at the Macworld Expo conference and a member of the conference faculty. He also co-founded the first dedicated PowerBook User Group (PPUG) in the United States.

After winning a major legal battle with Apple in 2006, he set the precedent that independent journalists are entitled to the same protections under the First Amendment as members of the mainstream media.

O'Grady is the author of The Nexus One Pocket Guide, The Droid Pocket Guide, The Google Phone Pocket Guide, and The Garmin nuvi Pocket Guide (Peachpit Press), the author of Corporations That Changed the World: Apple Inc. (Greenwood Press), and a contributor to The Mac Bible (Peachpit Press). In addition, he has contributed to numerous Mac publications over the years, including MacWEEK, Macworld, and MacPower (Japan).

When he's not writing about Apple for ZDNet at The Apple Core, he enjoys spending time with his family in New Jersey.

View the original article here

MobileMe to iCloud migration and calendar sharing

AppId is over the quota
AppId is over the quota
By Jason D. O'Grady | October 19, 2011, 6:00am PDT

Summary: Over the weekend I migrated two accounts from MobileMe to iCloud and everything went flawlessly. I configured two iPhones, two iPads and two MacBooks to sync to the iCloud accounts without issue.

Over the weekend I migrated two accounts from MobileMe to iCloud and configured two iPhones and two iPads to sync to the iCloud accounts and everything went flawlessly thanks in large part to the instructions posted at me.com/move.

My wife and I use two different iCloud accounts and we share calendars by simply control-clicking on the calendar name in iCal, then clicking on Sharing Settings. From this screen (pictured above) we just click the radio button for “Only the people you invite” then we add the other person’s email using the “+” icon at the bottom.

This is a little different than Ralleykeeper’s (somewhat unorthodox) method below. When I migrated our accounts to iCloud over the weekend I had no idea that you could add multiple iCloud accounts to one iOS device and pick and choose what items to sync — although it makes sense.

It’s also worth noting that although my wife and I each have our own iCloud accounts, we share one iTunes account, and this is no problem as Ralleykeeper notes. The only issue with our setup is that Photostream is tied to one iCloud account, so we no longer get to share one Photostream like we did when we shared one iCloud account (during beta testing). I’m guessing that a workaround would be to add each other’s iCloud accounts and pick one to share for Photostream, but I haven’t tried this yet.

The iCloud transition hasn’t been perfect though, users have reported various problems in the process, most of which appear to be centered around confusion over the difference between one’s MobileMe/iCould ID (used for syncing) and their Apple ID (used for iTunes). If they’re separate/different accounts you’re actually better off than if they use the same email address.

If you share calendars with your spouse I highly recommend the two iCloud, one Apple ID configuration — if you don’t already have separate Apple IDs, that is. This requires that you use different email addresses for each, but if you do, simply:

enter your iCloud ID in Settings > iCloudenter your Apple ID in Settings > Store

Unfortunately it doesn’t look like Apple’s going to allow merging of Apple IDs any time soon.

Rallykeeper posted a salient comment on the PowerPage story MobileMe users vent frustrations about iCloud transition issues about his success in migrating from MobileMe to iCloud:

I think there’s a lot of FUD out there on this issue.  Apple’s to blame for very poor documentation, but for me at least it’s actually worked quite well.

I managed the transition on 6 iOS devices, 3 iPods and 2 Macs sharing the same iTunes Apple ID (for app, music and video purchases) and converted two MobileMe accounts to two new iCloud accounts.  (4 devices use one iCloud account and 2 devices use the other).

To its credit, Apple has pretty clearly documented that you can use one Apple ID for iTunes and a completely different one for iCloud. Just input the different version in the Setting panel for Store (in iOS) and log in under that account in iTunes (for OS X).

What Apple hasn’t documented very well is that you can continue to use iCloud just like you used MobileMe and you can sync to multiple iCloud accounts on your iOS device through the Mail, Contacts, Calendars panel (the only feature that isn’t available is iMessage since it’s only associated with the iCloud panel).

For example, if you wanted to share calendars with your spouse, you can simply add her iCloud account as an additional Mail/Contact/Calendar account and sync calendars. Ditto on contacts. You simply turn off the features you don’t want to share (e.g., Find My iPhone, iMessage)

It’s been a remarkably painless transition. Haven’t checked our iWeb site yet, but iDisk, iMessaging, Find My Friends, Find My iPhone, etc. all just work.

Heck, Apple even gives you extra free storage in iCloud (carrying over the 20 GB you had in MobileMe) and continues to give you that same free storage in MobileMe (e.g., on your iDisk).

I’m still crossing my fingers that Apple decides to keep iDisk around — even as a paid option.  It’s simply a more elegant solution than third party services.

How did you fare in the transition to iCloud? Do you share calendars?

Update: If you’re having trouble migrating to iCloud I recommend the following Apple knowledgebase articles:

Jason O'Grady+ is a journalist and author specializing in mobile technology. He has published six books on Apple and mobile gadgets and his PowerPage blog has been publishing for over 15 years.

View the original article here

With iOS 5 and iCloud, more memory is better than less for your iPhone, iPad

AppId is over the quota
AppId is over the quota
Summary: The common wisdom is that the arrival of iCloud and iOS 5 will let us store our stuff on the cloud and buy an iPhone and iPad with less memory. However, a recent developer blog post warns that more memory is the better choice.

The common wisdom is that the arrival of iCloud and iOS 5 will let us store our stuff on the cloud and buy an iPhone and iPad with less memory. However, a recent developer blog post warns that more memory is the better choice.

The issue was presented by developer Marco Arment, the maker of the useful Instapaper, the off-line content reading service and application.  The post says the problem arrived with iOS 5 and its automatic backups to iCloud.

It happens that developers have stored data in several temporary caches. This was data that was useful to the application (and for the user experience) but wasn’t backed up in the iTunes sync cycle.

Now the data could be redownloaded, but that might take a long time depending on the available bandwidth (think Wifi vs. Edge) as well as the size of the cached files (the very reason that this data is not included in the usual backup and sync). Apple didn’t flush the caches so everything was fine and developers began to rely on storing their data in the caches.

However, now with iOS 5 and iCloud, Apple wants developers to reduce the amount of data overhead for their apps. If data can be redownloaded, it should be. Arment quotes some developer notes and memos:

1. Only documents and other data that is user-generated, or that cannot otherwise be recreated by your application, should be stored in the /Documents directory and will be automatically backed up by iCloud.

2. Data that can be downloaded again or regenerated should be stored in the /Library/Caches directory. Examples of files you should put in the Caches directory include database cache files and downloadable content, such as that used by magazine, newspaper, and map applications.

The problem as Arment explains it is that the cached data is now cleared when capacity falls to some low point. For Instapaper, this means content stored for offline reading, but it could effect apps that deal with map data, e-books and podcasts. If the user fills up the device with content, the caches with the content might be flushed.

He reports that one of his customers recently packed her iPad full of games, video and materials to read for a long-distance flight — a natural action — only to discover that her actions had triggered the cache cleaning routine. No reading for her.

Of course, downloading large amounts of data in the wild may not be practical or possible.

But even with available, fast, unlimited internet connectivity, randomly deleting an app’s data is still a problem:

When customers save an article with Instapaper, get a book in iBooks, or download a podcast with Instacast, they expect it to be there next time they launch the app. Even though it’s technically redownloadable, customers see that as their data — they put it there, and it’s theirs to remove if and when they see fit.

When the cleaner wipes it out, it appears that the app has failed and deleted their data. And customers won’t know that it’s an iOS 5 behavior — they’ll understandably blame the app developers. Even though it’s not our fault, it’s certainly going to become our problem.

There needs to be a file storage location that behaves the way Caches did before iOS 5: it’s not backed up to iTunes or iCloud, it’s not synced, but it’s also never deleted unless the app is deleted.

My guess is that Apple will fix this issue for developers shortly. Still, buying the iPhone and iPad SKU with more memory appears to be the best choice for performance and productivity.

David Morgenstern has covered the Mac market and other technology segments for 20 years.

View the original article here