| ▲ | butlike 2 hours ago | |
You're sharing data between apps. It's an app->app API, essentially. You can easily send an app store listing to your Reminders "Wishlist" section if you want, for example. It's definitely not only social sharing. | ||
| ▲ | TeMPOraL an hour ago | parent [-] | |
I wasn't even thinking social. Problem is, the actual operation being done is one of: - Give the other app a temporary/transient copy of a document or a file - Give the other app the actual file (R/W) - Give the other app the actual file but some other way (there's at least two in Android now, I believe?) - Give the other app some weird-ass read-only lens into the actual file - Re-encode the thing into something else and somehow stream it to the other app - Re-encode the thing into something else and give it that (that's a lossy variant of transient copy case - example, contact info being encoded into textual "[Name] Blah\n[Mobile] +55 555 555 555" text/plain message). - Upload it to cloud, give the other app a link - Upload it to cloud, download it back, and give the other app a transient downloaded copy (?! pretty sure Microsoft apps do that, or at least that's what it feels when I try to "Share" stuff from that; totally WTF) - Probably something else I'm missing. You never really know which of these mechanisms will be used by a given app, until you try to "Share" something from it for the first time. Now, I'm not saying the UI needs to expose the exact details of the process involved. But what it should do is to distinguish between: 1. Giving the other app access to the resource 2. Giving the other app an independent copy of the resource (and spell out if it's exact or mangled copy) 3. Giving the other app a pointer to the resource In desktop terminology, this is the difference between Save As, Export and copying the file path/URL. Also, desktop software usually gives you all three options. Mobile apps usually implement only one of them as "Share", so when you need one of the not chosen options, you're SOL. | ||