Brian Kim of Proximi wrote in to tell us that BargainBin, arguably the app that coined the term “pocket rejection”, caps off one of the stranger and most memorable weeks in App Store confusion by actually getting out of the pocket and onto iPhones everywhere.

Following up on AMBER Alert’s approval, and Tweetie 1.3′s rejection and almost immediate reversal/approval, we have to wonder if the internet outcry on Twitter and blogs actually made a difference, and something changed deep inside Apple — or if this is just a cosmically coincidental, Ozymandia-worthy joke.

Heh. Maybe Apple’s just trying to get some good faith back from developers before they preview iPhone OS 3.0 and the new SDK on Tuesday…

If you’re interested in keeping track of price-dropped apps, check out BargainBin [iTunes link] and let us know how it works for you.

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.

Check out he Q&A after the break!

(Responses courtesy of Brian Radmin of Proximi fame)

TiPb: Hi Brian. Thanks for the heads-up on OpenClip. We have a few questions for you, but is there anything you’d like to start off with?

Brian: Hey Rene. To preface this, our sole intentions are to promote app-to-app copy / paste, not Proximi, Inc. While we made MagicPad and worked with Zac White to establish OpenClip.org, it is truly a collaborative effort with most of the credit being owed to him (Zac is a student developer at the University of Oklahoma).

Watching Cali Lewis’ video, it looks like the OpenClip implementation UI is varying by application. (i.e., slide-up buttons for Twittelator, static buttons for WordPress, and the existing pop-ups in MagicPad). Is this intentional, simply providing a Core-like service Apps can use as they wish, or are you eventually hoping to standardize the interface for usability, like the CMD/CTRL X/C/V conventions?

In our proposal for copy / paste / text-selection candidate (http://magicpad.proximi.com/video.php), we discussed the different types of applications and why we felt variation in UI experience was necessary.

Do you still see this effort as “proof-of-concept” pushing Apple towards implementing cut/copy/paste themselves (making you obsolete, as you mentioned last time), or are you now figuring it will take so long for something official to come down the pipe, you want to provide truly robust solution yourselves?

We are definitely hoping Apple makes OpenClip obsolete. True system-wide copy / paste is not possible without Apple. We just hope our efforts help speed the process along and provide additional utility to iPhone users in the meantime.

Finally, is auto-correction playing nicely with cut and paste yet? (Or is Gruber going to yell at us again =) )

We’ve taken a lot of time to implement auto-correction in MagicPad, and while we’ve had success with Roman character keyboards, non-Roman languages are not functioning properly. The lack of Apple’s documentation on the auto-correction method is making it really difficult to integrate with our UI for text-selection. Trust me, we’re trying, but Gruber will still be yelling at us… =)

Thanks Brian! Can’t wait to see more OpenClip aware Apps. Also can’t wait for Apple to get serious about implementing this (or whatever their ultimate take on the functionality ends up being) officially.