OpenClip.org Offers Copy and Paste for iPhone Across Apps

[Cleverboy]

No so quick.
How will the app store and protect the data?

The "app store" doesn't have to protect anything. There is simply a protected nature to the way 3rd party native applications exist on the iPhone.

If it is a specific location in memory, that is protected from being moved, deleted, overwritten, then it would be possible for another app to find this location.

Seems like that's the technique being discussed. I can't quite tell what you're implying though.

I understand completely why Apple does not want app generated background tasks and won't allow apps to do this -- at least for now.

Copy & Paste has nothing to do with background tasks. Apple hasn't implemented this due to time constraints, and moreover, the sticking point isn't simply the amount of time it would take to implement it, but agreement on what the best method would be for the feature moving forward into the future AND the documentation and QA related to perfecting that method (security being just one of many issues). Once Apple has determined what the method will be, they'll need to coordinate that vision to everyone involved and there won't be much room for changing your mind later.

An evil app that is often run, e.g. a screensaver (I don't know if the iPhone even *has* screensavers) could then regularly poll the clipboard locations of other apps and store any info it finds.

This is another reason why the iPhone isn't allowed to have *3rd party* background applications. Each application must QUIT before another is launched. There is no "polling" because at the time the application is run, no other 3rd party app is running. I think this was a very shrewd move on Apple's part.

My vision of Apple's "copy & paste" would also include a "timeout" on the clipboard, whereby the clipboard can be manually cleared from the "Settings" area, and also set to auto-erase after a particular time-out period. I don't think the iPhone should suffer an indefinite clipboard that only erases on reboots. It would be great to know that the clipboard does its own housekeeping after you're done with the data (or if you liked, you could set it to never auto-erase, and even survive reboots). I think any iPhone "clipboard" should not exist in "memory". In my opinion, that would be a mistake in resource utilization.

~ CB

 

[happydude]

nice how apple hasn't done it yet but a student developer with free time could. common, apple!!

 

[kjs862]

Saw this earlier today, but just getting to it now. That chick reads too quick, but shes cute so its ok.

The copy and paste seems good and all, but I think I'm just going to wait until Apple officially releases their own.

 

[alchemistmuffin]

Not possible as long as Apple has the KILL SWITCH....

This is the perfect concept, except that one thing....

Apple has a KILL SWITCH....

Even if the product is launched, Apple might pull the KILL SWITCH on the program, and send cease and desist to the OpenClip.org group, since it's a violation of terms of agreement....

Copy and Paste requires a background process, which Apple won't allow... Even if the copy and paste works with individual code, the copied text end up being on the background process, which by the way, a signal for Apple to turn on the KILL SWITCH....

 

[mashkina]

I would guess Apple has half a dozen implementations of copy/paste cooked up in the lab right now, 3 of which are probably up for consideration, and 1 is so radical that we all didn't think of it before (but may not be ready for prime time).

The only thing Apple is "figuring out" is which one to use. Jobs and company like to use things before they go into any product—I would guess even more so with such an integral feature like copy/paste—so what better test than to try each out for awhile and decide if it's worth keeping?

These 3rd party developers may have stumbled upon gum but is it worth chewing on forever? That's what Apple has to kick around now. And it has to be intuitive enough that developers and everyone else is like "OK, that's it. I couldn't have done it any better."

So it's not just copy/paste... it's getting the paradigm to work well so they don't have to change it up. What Apple implements is likely going to be there 10 years from now just like the cut/copy/paste commands in the menu bar today.

I agree completely. Apple's implementation will be the simplest for the user. I don't like to use sliding menus for every action you want to perform on the iPhone. I bet, cut&paste will be based on multitouch gestures: double tap while holding on the second tap, immediately sliding to select the text, and finally some gesture to do the copy (no sliding menus whatsoever).

 

[arn]

This is the perfect concept, except that one thing....

Apple has a KILL SWITCH....

Even if the product is launched, Apple might pull the KILL SWITCH on the program, and send cease and desist to the OpenClip.org group, since it's a violation of terms of agreement....

Copy and Paste requires a background process, which Apple won't allow... Even if the copy and paste works with individual code, the copied text end up being on the background process, which by the way, a signal for Apple to turn on the KILL SWITCH....

You should re-read the main article. There is no background process required.

arn

 

[TheSpaz]

This is the perfect concept, except that one thing....

Apple has a KILL SWITCH....

Even if the product is launched, Apple might pull the KILL SWITCH on the program, and send cease and desist to the OpenClip.org group, since it's a violation of terms of agreement....

Copy and Paste requires a background process, which Apple won't allow... Even if the copy and paste works with individual code, the copied text end up being on the background process, which by the way, a signal for Apple to turn on the KILL SWITCH....

It's not a background process. It stores the data in a universally accessable folder (possibly in the Media folder) that other apps have access to. All the other developers have to do is read or write to that folder.

 

[Cleverboy]

You should re-read the main article. There is no background process required.
arn

And moreover, the "kill switch" so often bandied about is to be used on "malware" not apps Apple simply doesn't like (it is a "nuclear option" that remains generally undefined). As well, copy/paste is not it's own application... It is an agreed upon framework that numerous developers would incorporate into their code. Worse than any "kill switch" Apple could simply choose to make participating apps vanish from the store if they are engaged in behavior inappropriate to Apple's guidelines.

People need to keep the "kill switch" in perspective.

~ CB

 

[domness]

First of all, the presenter in the video clip is hot!

Second, this is such a good idea, however, for those who like to post notes and emails etc from a clipboard will be stuck until apple release an official version of copy and paste for the iphone.

 

[ldkaplan]

There's really no incentive for someone to create and sell/give away a new mail application or web browser because Apple's "free" solution works quite well (or at least well enough). But, if someone created a mobile Mozilla, or if Opera ported Opera mini to the iPhone and supported OpenClip people would buy it. Same goes for a web browser that worked more or less like Safari but supported OpenClip.

I would pay for a new mail app...this one stinks. There is no search or sort off messages. Who gives a hoot about enterprise Outlook if you can't search your email.

And Safari? I'd like to have a browser that let me add in different searches like Firefox...we need Mozilla for iPhone. And since FF is free...I hope it's them!

 

[ldkaplan]

I agree completely. Apple's implementation will be the simplest for the user. I don't like to use sliding menus for every action you want to perform on the iPhone. I bet, cut&paste will be based on multitouch gestures: double tap while holding on the second tap, immediately sliding to select the text, and finally some gesture to do the copy (no sliding menus whatsoever).

I'm thinking it will be a second tap, not a double tap. A finger is not detailed enough to hit the right spot so magnifying glass is still need to find the exact start and stop spots.

So right thumb down for magnifying glass and getting to the start spot. Left thumb down for starting the highlight while you slide right thumb (Selecting). Left thumb up to copy.

For paste, right thumb down where you want to paste. Left thumb double tap to paste.

 

[VforVelveta]

Looks like it won't be around for long, Gruber's got a nice piece on it. Apparently it'll be broken come 2.1...

http://daringfireball.net/2008/08/raining_on_the_openclip_parade

 

[alchemistmuffin]

It's not a background process. It stores the data in a universally accessable folder (possibly in the Media folder) that other apps have access to. All the other developers have to do is read or write to that folder.

Have you READ the SDK agreement MORE CLOSELY? I am a developer, and from what I have read in the agreement, I think what the OpenClip.org is doing is a violation of the SDK agreement, and also for Apple's perspective, considered a Malware in some way, and could end up enabling the KILL SWITCH....

Also, the framework the OpenClip.org is using is 2.0, NOT THE 2.1 beta that Apple STRONGLY recommended users to use in developing a MAJOR NEW VERSION of the app....

2.1 has A LOT OF difference from 2.0. I can't tell you a lot about framework, but the framework that OpenClip is planning to use will enable the KILL SWITCH function in the iPhone OS.....

 

[k'five]

Have you READ the SDK agreement MORE CLOSELY? I am a developer, and from what I have read in the agreement, I think what the OpenClip.org is doing is a violation of the SDK agreement, and also for Apple's perspective, considered a Malware in some way, and could end up enabling the KILL SWITCH....

Also, the framework the OpenClip.org is using is 2.0, NOT THE 2.1 beta that Apple STRONGLY recommended users to use in developing a MAJOR NEW VERSION of the app....

2.1 has A LOT OF difference from 2.0. I can't tell you a lot about framework, but the framework that OpenClip is planning to use will enable the KILL SWITCH function in the iPhone OS.....

MORE CLOSELY? More closely than what?
KILL SWITCH KILL SWITCH KILL SWITCH!!! Jeez kid, put THAT speedball down AND RELAX.

If Apple doesn't like it, they're not going TO ALLOW it in the appstore to begin with, since IT'S already getting this MUCH exposure going in. But I hear ya, you like saying KILL SWITCH.

Looking forward to more randomly capitalized words from you soon.

KILL SWITCH!!!

 

[alchemistmuffin]

MORE CLOSELY? More closely than what?
KILL SWITCH KILL SWITCH KILL SWITCH!!! Jeez kid, put THAT speedball down AND RELAX.

If Apple doesn't like it, they're not going TO ALLOW it in the appstore to begin with, since IT'S already getting this MUCH exposure going in. But I hear ya, you like saying KILL SWITCH.

Looking forward to more randomly capitalized words from you soon.

KILL SWITCH!!!

Look, I am also scared of the KILL SWITCH...

So, as a Apple fanboy, the SWITCH should be capitilized so I can reference to the specific kill switch I am talking about....

the Kill Switch in italics represent the switch for ending certain action not pertaining to software. The Kill Switch in bold represent killing certain apps not related to iPhone. KILL SWITCH in bold caps represent Apple killing the apps on iPhone without no notice, followed by at&t terminating your contract without your notice for installing unauthorized app.

Also, note, when I mean read closley, I meant READ THE SDK agreement WORD FOR WORD....

I am a developer, and I had to read the whole document and agreement, then talking to my lawyer before starting to create the apps, so I don't violate the agreement.

 

[Cleverboy]

Look, I am also scared of the **** ******... So, as a Apple fanboy, the SWITCH should be capitilized so I can reference to the specific kill switch I am talking about...

Please stop. PLEASE stop it. Stop talking about the supposed "KS". It's stupid. No... its MINDLESS to talk about it the way its being talked about.

#1.) The core location related code, and the "lever" mentioned by Steve Jobs are not necessarily related. One is a blacklist of programs not allowed to continue requesting the use of "core location" services, like GPS... and the other is the knowledge that Apple has a method for disabling iPhone apps already deployed (whether it means deactivated remotely or when the phone is next synced with iTunes).

#2.) Pure logic. In the event of disabling applications remotely, Apple needs to be clear that the application has malicious intentions toward its users. Why? From a legal perspective. Disabling an application on a user's device is an extreme act that Apple will have to defend in the court of public opinion (as well as possibly a court of law). As a point of FACT there are a myriad apps running on "jail broken" iPhones that Apple would never intentionally or implicitly allow. These apps will NEVER be simply "shut off", because any solution would never, ever be perfect, people would find a way around it, and it will generally end up simply enraging Apple's customer base. Lose, Lose, Lose. There is no "win" here. Moreover, Apple generally speaking, doesn't even get into "refunds" for electronic purchases. Imagine the nightmare with be to shut off a 99 cent app on 200,000 phones and coordinate automatic refunds to all those customer accounts. Not something to be regarded lightly.

#3.) Guess what? Removing your app from the App Store is a much more plausible consequence of implementing bad code than any perceived remote deactivation. This has been happening on a regular basis. We have "NetShare" and "BoxOffice" as two examples. One, clearly a violating AT&T policies and the other removed for much more nebulous reasons.

So, to review:
1.) We don't know much about it.
2.) It is the "option of last resort" of what Apple would do.
3.) Better options are being used to discourage policy-based objections by Apple to applications being sold it its store.

I am a developer, and I had to read the whole document and agreement, then talking to my lawyer before starting to create the apps, so I don't violate the agreement.

Having a broken application is a much more terrible curse on an app than anything else. Crashing every time a function fails to work (like PASTING) or simply not working as advertised (just look at the "reviews" section in the App Store for buggy applications). Being removed for App Store and not knowing why and wasting a significant amount of development time to implement something that doesn't actually work... these are reasons that are REAL and PRESENT.

No one has to even begin to discuss any resembling a Sword of Damocles. Hey, actually, that doesn't bug me half as much. I think I'll start referring to the KS as the SoD. Brings a literary dynamic to the whole thing and spells "DoS" backwards (the method of flooding a service with bogus traffic until it can't be accessed, instead the SoD simply "kills" the service at the root).

~ CB

 

[Cleverboy]

Looks like it won't be around for long, Gruber's got a nice piece on it. Apparently it'll be broken come 2.1...

http://daringfireball.net/2008/08/raining_on_the_openclip_parade

Yeah, I liked the piece as well. In fact, there was one part of it that really shot home, because... without looking at the OpenClip code, I thought the exact same thing. In a word "disingenuous".

That struck me as curious, as I wasn’t aware of any inter-application “shared space” on the iPhone. White’s own description of how it works and the OpenClip source code itself show that such a description is disingenuous. The “How does it work?” section of their regular (i.e. non-developer) FAQ is more technically accurate:

In fact, I found that wording of "shared space" to be SO curious, as to come up with a method of "sharing" space, that, to my knowledge... would clearly work NOW, and continuing working into the future... whereas the current OpenClip implementation will NOT be working. Moreover, my idea would even be compatible with copy & pasting from Safari with the simple use of a special bookmark. --And ALSO, users would be able to see their clipboard usage in their Safari settings under "Databases".

Maybe they need to rearchitect OpenClip to use this, and NOT to rely on a security oversight by Apple. But, for all I know, my discovery is a security oversight as well.

~ CB

 

[mashkina]

I'm thinking it will be a second tap, not a double tap. A finger is not detailed enough to hit the right spot so magnifying glass is still need to find the exact start and stop spots.

So right thumb down for magnifying glass and getting to the start spot. Left thumb down for starting the highlight while you slide right thumb (Selecting). Left thumb up to copy.

For paste, right thumb down where you want to paste. Left thumb double tap to paste.

Interesting point. However, the lens zoom can be used after pasting instead of before copying. For copying you do not want to waste so much time, trying to select exactly the text/things you want to. Better a smart copy that gets more or less what you mean. It is by pasting when you can use the lens-zoom to delete/correct the copy. Just an idea.

 

[decksnap]

According to Gruber, 2.1 not only stops this from working, but was in development before this came out. Just getting that out before people say Apple 'killed' it.

Apps will no longer be able to read other apps sandboxes, and I don't think they were ever supposed to be able to.

 

[Cleverboy]

According to Gruber, 2.1 not only stops this from working, but was in development before this came out. Just getting that out before people say Apple 'killed' it. Apps will no longer be able to read other apps sandboxes, and I don't think they were ever supposed to be able to.

You honestly think anything will stop people from saying Apple killed it? Ignorance is bliss.

~ CB