We recently covered the new OpenClip project, and expansion of what was first demonstrated with MagicPad, and we liked both their implementation and their moxy in trying to pip Apple to the cut and paste post. Not everyone was as entirely impressed as us, however. John Gruber of Daring Fireball questioned whether or not the developers were really respecting the App Store SDK agreement. Since OpenClip aware applications write to their own sandbox’d Documents directory, but read the last-modified chunk from other applications Documents directory, Gruber considers it more of a loophole, and cites Apple’s iPhone OS Programming Guide:
Not simply that no other application can write to, but which no other application can access. That this restriction is not yet enforced at a technical level (such as is the case with an app attempting to write outside its own sandbox) does not mean it’s permitted.
Worse yet, Gruber points out that the current Beta 4 of the upcoming 2.1 firmware DOES enforce complete denial-of-access to other application’s Documents directory:
The OpenClip demo apps, which work as advertised on iPhone OS 2.0.2, do not work in the current 2.1 beta, because apps are no longer able to read or even see other apps’ sandboxes.3 To be clear, this change is clearly not in response to OpenClip; Apple began seeding the 2.1 betas with these tightened sandbox restrictions before OpenClip debuted, and the iPhone OS Programming Guide has stated all along that apps can’t “access” the contents of other sandboxes.
However, I’m not entirely certain any of that matters. OpenClip, based on my understanding, was never intended to be a long-term solution, merely a proof-of-concept to show that cut, copy, and paste could be done in an elegant manner on the iPhone, to keep a spotlight on the continued lack of cut, copy, and paste support from Apple, and to encourage the discussion of the issue and implementation.
In that regard, I think they’ve already succeeded.
Following up on the earlier post about OpenClip, the new open-source framework for implementing a shared (i.e. cross-application) clipboard for the iPhone, the video above highlights developer Zac White’s presentation at iPhoneDevCamp2. Not enough for you? Okay, TiPb had another chance to talk with the innovative folks at Proximi (makers of MagicPad, the original proof-of-concept for this functionality), who were kind enough to share a few more details with our readers.
Cali Lewis over at Geekbrief.tv recounts how iPhone App Store developer Juviwhale (who previously spoke to TiPb about his work on MagicPad) met up with a college student named Zac White at Dev Camp, who turned MagicPad’s localized cut/copy/paste functionality into cross-application gold with the open-source OpenClip framework:
Apple forbids applications from running in the background because it would take up too much of the iPhone’s resources. Also, developers are not allowed to create plug-ins that make their apps work with other apps on the iPhone. Zac White’s Open Clip framework uses a shared space on the iPhone. Any application that includes Open Clip can then access the common area and write to it, and read from it, thereby enabling copy and paste between participating apps.
Bottom line, it looks like any developer can add OpenClip, and instantly gain access to the shared cut/copy/paste pool. (Two of the apps demonstrated, sing a similar slide-up set of buttons to the proof-of-concept David Friedman showed off a few weeks back)
Tired of waiting for a cut, copy, and paste on the iPhone? MagicPad — a Note App replacement that also features Rich Text editing (buh-bye Marker Felt!) — sure was. Witness the above proof-of-concept video. Ladies and gentlemen, the holy grail of iPhone feature.
Curious as to how they implemented their solution, and what challenges they faced? So were we, so we asked them. Read on for their answer!
