Maybe I wasn't so wrong after all.  This teardown at iFixIt shows (at step 8) solder pads that are a perfect fit for a dock connector.  It's obvious that Apple has thought about a dock connector for Apple TV.  Perhaps they were primarily thinking about the dock connector as a conduit for playing your music in your living room using your iPod, but when you have AirPlay you don't really need that.  I hope Apple comes around to the idea of using the dock connector more as a way to extend an ecosystem for software and hardware developers and places a dock connector on the next iteration of Apple TV.

~s

Once you develop a media-rich project or two where you end up loading a bunch of smaller resources that may or may not be visible to the user at any given time (experiences like email, image galleries, and video games fit this description), you realize that having a dynamic cache of these resources is necessary to make the user's experience fluid.  This is because available memory is smaller than the amount needed to keep all resources in memory at once, thus available for rendering at any time.  However, you don't want an upper layer view (as in the MVC pattern) to manage or deal with the details of what does & doesn't fit in memory: the abstraction it should deal with is to fetch and display the information.  Additional complexity would be added when multiple views simultaneously manage these resources.

Instead of thinking about keeping resources in memory, maybe we can simply fetch them every time they are needed by a view?  Usually, these resources require some transformation before being displayed (decompression, color palette lookups, etc.) or they are very latent in their retrieval (stored on a DVD or on the internet behind a URL).  Media rich applications typically need to support some form of animation or other dynamism with these resources - updating these resources in response to animation requires keeping them around in their transformed formats.  When animations run every 16ms (at 60 frames per second), and resource retrieval and transformation can take hundreds of milliseconds, fetching every time a resource is needed is not a valid solution.

So, a layer between views and resources is needed.  This cache would be responsible for fetching resources as requested by views and transforming them to a usable state before handing them back to the view.  Since the fetch and transformation is very latent, the cache remains in an indeterminate state between the first request and the completion of the fetch.  Either the cache or view can decide what to do in this case by showing a placeholder resource, or waiting until the fetch is complete.  Since it's a cache, there is also an eviction policy.  This could be size-related, or time-related.  For software programs that could cache their resources across sessions (such as web browsers), having the cache backed by storage is important.  Most any software programmer should be familiar with these concepts.

So why write a blog post about it?  In iOS, Apple has provided a great many libraries to create media-rich applications: CoreAnimation, CoreImage, etc.  But, a resource cache abstraction that is backed by application-owned storage is curiously missing.  Of course, the community has filled the gap, but this is code that only really needs to be solved once as most applications in this style have very similar use cases.  An especially interesting scenario is an application browsing a bunch of images downloaded from the Internet.  This isn't narrowly scoped to photo album viewers, but includes apps that show box art or product photos, for example.

This post details a great solution in code.  A commenter created this github repository with a cohesive implementation that includes a UIImageView protocol category that helps you use this kind of caching transparently.  If your app has anything to do with downloading lots of images, I highly recommend using this library or writing your own based on the details from the linked post.

~s

In a previous post, I talked about how I think Apple TV should have been made.  One of the features I like the most is the idea of an expansion port that iOS applications could access.  I wanted to take the time to elaborate on that idea as I think it has the ability to be a disruption, especially for game console platform holders.

What value do console platform holders give to their customers?  For that matter, who are their customers?  They actually have four classes of them: consumers, publishers, developers and retail distributors.  The platform holders provide different value to each of them.  Also, let's distinguish a publisher as the entity that wants to make money selling games, while the developer is an altruistic entity that just wants to make a great game.

To the retail distributor, they provide an ecosystem of products to sell at a profit.  Note the word ecosystem: video game consoles are sold at a loss and distributors make money by selling software.  In return for this ecosystem, the distributor provides the platform holder with physical reach for consoles: even if all the games in the world were digitally distributed, console makers still need physical retailers to put the console into your home.  Apple excels here, of course, as they have a bunch of Apple Stores.

To the publisher, a console provides an install base of users to reach and the distribution channels to reach them.  Previously, there was only one distribution channel: the game image (on a disc or in a cartridge).  Now, there are a few given the various channels of downloadable content available.

To the developer and the consumer, consoles provide special value: they solve the interaction problem at scale.  For developers, a scalable solution is one that lots of users are able to use - all the more whom developers may be able to influence through their games.  To consumers, a scalable solution allows them to interact with and control as many experiences as possible, thus maximizing an initial investment in a video game console.

So in review, the only unique problem being solved by a game console platform holder is the interaction problem.  The others are a question of sales and distribution, and they are usually the most expensive problems to solve as they become chicken-and-egg scenarios.  Without potential for profitability, distributors have no incentive to let a platform holder leverage their reach.  And without reach, the platform holder can't offer the potential for profitability.

Through its Apple Stores, Apple has attained as much reach as one could need, and through the App Store, provides a marketplace that removes the middle man distributor.  That leaves the interaction problem.  Apple would love to solve the interaction problem for the purpose of users accessing their movies, music, etc.  They've tried to do this with the five button remote.  However, Apple hasn't gone beyond that and I don't think they want to do so.

An expansion port on an Apple TV device would make it much cheaper to become a video game platform holder by allowing them to leverage Apple's distribution of Apple TVs.  The platform holder would no longer need to provide an ecosystem of profitability to distributors as the hardware would no longer serve as a loss-leader: it could be sold anywhere.  Games are net-neutral as they have the same incentives to use platform hardware as they always did.  Consumers are happier since they get to choose the kind of interaction they want without investing in multiple, expensive consoles.  Ultimately, this allow platform holders to focus more of their attention on why they truly entered the business in the first place: building great human-computer interaction.

~s

This article points out that Apple may be holding back its development of the features I previously mentioned.  I tend to agree - there's only one way for Apple (or someone) to go, and that is to build an all-inclusive device that finally gets rid of your cable box, DVD player and potentially game consoles.  If you want to take over the TV, that's what you gotta do.

~s