Share Extension/Intents #2587
Share Extension/Intents #2587
Conversation
|
good gravy those build plugins |
|
tfw writing the feature takes an hour and writing getting it to build takes a day |
|
Feeling like this is probably ready to test out. I've tested the scenarios I can think of and they have all worked so far... @pfrazee Still curious on whether you prefer to use |
|
Changing this to draft because I want to check over one thing I noticed (sharing an image that isn't in the photo gallery but rather from Safari or something) and I want to see what we're doing for intent URIs. |
|
Okay back to work. |
# Conflicts: # src/Navigation.tsx # src/lib/routes/types.ts # src/view/screens/Home.tsx
| #!/bin/bash | ||
| IOS_SHARE_EXTENSION_DIRECTORY="./ios/Share-with-Bluesky" | ||
| MODULES_DIRECTORY="./modules" | ||
|
|
||
| if [ ! -d $IOS_SHARE_EXTENSION_DIRECTORY ]; then | ||
| echo "$IOS_SHARE_EXTENSION_DIRECTORY not found inside of your iOS project." | ||
| exit 1 | ||
| else | ||
| cp -R $IOS_SHARE_EXTENSION_DIRECTORY $MODULES_DIRECTORY | ||
| fi |
There was a problem hiding this comment.
This is just a helper script for updating the extension files inside of the ./modules directory with changes made in Xcode while dev/testing the extension.
| // For some security, we're going to filter out any image uri that is external. We don't want someone to | ||
| // be able to provide some link like "bluesky://intent/compose?imageUris=https://IHaveYourIpNow.com/image.jpeg | ||
| // and we load that image | ||
| if (part.includes('https://') || part.includes('http://')) { | ||
| return false | ||
| } |
There was a problem hiding this comment.
I think this covers the main security concern with this. Any others I'm not considering?
| openComposer({}) // will pass in values to the composer here in the share extension | ||
| openComposer({ | ||
| text: text ?? undefined, | ||
| imageUris: isNative ? imageUris : undefined, |
There was a problem hiding this comment.
No support for imageUris on web for right now. At some point if we do allow external URLs through cardyb or something, we could do this.
fixes #66
fixes #1540
What I've tested
?compose=true&text=Still to do
react-native-fstoexpo-file-systemand the logic will need to be different anyway.Screen.Recording.2024-01-21.at.9.57.02.PM.mov
Intent
To open the composer, user navigates to
https://bsky.app/intent/compose?text=Hello world!. The existing router logic handles passing those params to the home screen.Native scheme
The same logic is used on native, allowing for
bluesky://intent/compose?text=Hello world!.In addition, image URIs from the extension are also allowed. These are passed in as
imageUris?=uri1,uri2,uri3,uri4. Currently, only local URIs are supported.Native share extension/module
On iOS we add an extension to the project's build phases. On Android, we add an expo module that handles the incoming intents for us and reroutes them to the correct scheme.
There's also a little script,
updateExtensions.shthat updates the tracked native files in/modules/Share-with-Blueskywith the ones in/ios/Share-with-Bluesky, for development purposes, since unlike a module, the extension code needs to live inside of theiosdirectory.Config plugin
In an effort to support the current prebuild configuration (ffs...🙃), an expo plugin handles moving the native code to the correct directories and adding the necessary build phases, entitlements, etc. to the projects. Config-defined schemes are supported, for those who may be doing their own testing in an effort to not overlap with the official build's scheme.
The Android build plugin just updates the
AppManifest.xmlwith the necessary allowed intents.