Archive for October 2, 2013

Wednesday, October 2, 2013 [Tweets] [Favorites]

Amazon Kindle Fire HDX 7-inch

Andy Ihnatko:

A new origami-style case adds to the bulk, but it’s a terrific design. Magnets inside the folding cover allow you to fold it back around for reading, or to click it into landscape or portrait tabletop mode, with your choice of two angles. And unlike the iPad’s Smart Cover, it won’t pop off when it shouldn’t: The Fire clicks into a stub and remains held in place by more magnets.

[…]

I don’t expect to see Apple lower the price of the 16GB iPad mini below its current $329. For the life of me, I don’t know what Apple could do to enhance the iPad mini to make me recommend it over the Fire HDX, provided that the person asking my advice had little interest in productivity or gaming. A 7-inch Fire HDX will give you a superior content experience and leave $100 in your pocket—which you can spend on books, music, and movies.

I’m surprised that the 7-inch Kindle Fire HDX is only 0.2 oz lighter (10.7 oz) than the 7.9-inch iPad mini (10.9 oz), which feels heavy compared with even my 8.5 oz Kindle 3. Put another way, both the Fire and the Mini are heavier than a current Kindle Paperwhite and an iPod touch combined.

Sustainability and the Mac App Store

Dan Counsell:

We honestly believe we build some of the best, most polished apps in the world. We sweat so many details, yet users are waiting for them to go on sale, simply because that’s the way things have been done. We now know that volatile pricing is not sustainable for us and wrong for so many reasons.

The audience on the Mac App Store is not yet large enough to sustain low prices (like the iPhone can, sometimes) – it’s just not feasible. If companies keep selling software at bargain basement prices without a large enough market, it doesn’t end well – they go out of business and if that happens, the very people who love great apps lose too.

Core Data Ensembles

Drew McCormack:

Ensembles extends Apple’s Core Data framework to add peer-to-peer synchronization for Mac OS and iOS. Multiple SQLite persistent stores can be coupled together via a file synchronization platform like iCloud or Dropbox. The framework can be readily extended to support any service capable of moving files between devices, including custom servers.

There doesn’t yet seem to be a detailed description of how it works. My impression is that it’s supposed to be the general Core Data iCloud approach, done right, and generalized to support other servers.

Update (2013-10-02): Drew McCormack:

In stark contrast to iCloud—Core Data, you also shouldn’t need to tear down your Core Data stack at any point just to accommodate Ensembles. Your NSManagedObjectContext can proceed unhindered, even when Ensembles has no connection to the cloud, or a catastrophic problem arises, such as the user changing cloud accounts. Syncing may terminate, but your app will go forth as though nothing happened.

And when your app is ready to reconnect to the cloud, Ensembles automatically migrates data to the cloud, so again, you are not required to play musical chairs with store files, and artificial migrations between stores, like you must when using iCloud—Core Data synchronisation.

[…]

We are dealing with a decentralised, peer-to-peer synchronisation model, where no device can assume it has the complete global state at any point in time. When merging a change set from a different device, it is often necessary to reapply changes from a change set that has already been merged, in order to guarantee eventual consistency.

[…]

A temporary background NSManagedObjectContext is created which shares the same SQLite store as the main context. Change sets are merged into this context, in order, with no regard to validity of the object graph. When it is time to commit the changes, a delegate method is invoked to give the host app an opportunity to apply any repairs that it wants to make before the data is sent to disk. A second delegate method is called if the background save fails, offering another opportunity to make repairs. Any repairs made by the application code are captured and added as a change set.

(This whole process is very much analogous to how a developer uses a DVCS like Git. Typically, you pull new versions from a server, and merge them with your local changes. If conflicts arise, you repair them, and commit these new changes, before pushing all local changes back to the server.)

Sounds like a good start. Unlike iCloud, the persistent store is never in an invalid state. It doesn’t yet support large blobs or compacting change sets.

Lifting the Lid on the iOS 7 UIPicker

Sean Woodhouse (via Mike Rundle):

As you can see from Marc’s diagram, you can no longer drag above and below the AM/PM column to move it. This is a huge pain because now you have to place your finger over the content in order to make your selection. In iOS 6 I’d often push or pull underneath the selected AM/PM value to change it. You’re also not able to tap the AM/PM or minute items to select them, which is completely inconsistent because you can tap the day and hour items!

Hopefully these were unintentional changes that will be fixed, because I’m finding the new picker difficult to use.