Feature/new task #1195
Feature/new task #1195
Conversation
JohnWilliamForcier-Spiria
requested review from
jgcmarins,
MateusAndrade and
mikehardy
as code owners
| @@ -98,6 +98,10 @@ public int compare(HashMap<String, String> map, HashMap<String, String> map2) { | |||
| public void open(ReadableMap options) throws ActivityNotFoundException { | |||
| this.options = options; | |||
|
|
|||
| if (ShareIntent.hasValidKey("isNewTask", options) && options.getBoolean("isNewTask")) { | |||
There was a problem hiding this comment.
What about openNewIntent?
| if (ShareIntent.hasValidKey("isNewTask", options) && options.getBoolean("isNewTask")) { | |
| if (ShareIntent.hasValidKey("openNewIntent", options) && options.getBoolean("openNewIntent")) { |
There was a problem hiding this comment.
I think the reason it's called isNewTask is because it's specifically using the flag that forces the system to put any activity started as a result of the Intent in a new task, I was just reading up on it in response to seeing this PR:
https://developer.android.com/reference/android/content/Intent#FLAG_ACTIVITY_NEW_TASK - it's clearly called "new task" and the whole tasks / back stack / user navigation flow uses "Task" as a term of art that is related to - but not the same as "new intent".
All of our shares are new Intents, but this makes the new Intent also put the new Activity in it's own separate history backstack which alters back behavior in specific ways
https://developer.android.com/guide/components/activities/tasks-and-back-stack#IntentFlagsForTasks
I think it's named fine. I guess what I'm having trouble with is deciding if this should actually be the default or not! Honestly it seems like it should be the default now that I read about it deeply. When submitter @SpiriaJWF says "app", in Android terms what that means is not what's in your APK, it means "one task with a backstack of Activities" - that single task with it's backstack is what shows up in the recents switcher if I understand correctly? So this isNewTask behavior means that the Activity started as a result of a share will be a fresh "app" in the recents, running on it's own with it's own independent history now.
I also noticed we set FLAG_ACTIVITY_NO_HISTORY which will interact with this as well, maybe not in a great way
By setting that currently, it means that after the share, if the user hits the home button or uses recents to do anything outside of the activity opened for the share, the activity just goes poof, which is odd. And it might be the root of why we don't get share results, according to the docs
There was a problem hiding this comment.
Note that this may only really be visible as a "mixed" (shared Activity as top item in your app's backstack inside the same task) app experience if the app wasn't already started in it's own Task prior to the share. Concretely, if Whatsapp was not open (as if! it's always open, but kill it for testing), then if you share to whatsapp you may see whatsapp pop up as the top activity on your mobile. Not sure if that example is perfect because whatsapp may define in it's Manifest that it always gets a separate task (it should really), but the same test can be tried with different share targets and I bet at least some of them will open up inside your app. Maybe @SpiriaJWF has a concrete example of an app that ends up in the react-native app's task as top activity on backstack?
There was a problem hiding this comment.
Nice catch @mikehardy! I think I made confusion with the Intent + Tasks here.
Also, as you mentioned it can be annoying to have the behavior of "destroying" the app that was open when the user presses the back button. What do you think if you give at try changing:
chooser.addFlags(Intent.FLAG_ACTIVITY_NO_HISTORY);
To a more "user-friendly" behavior using FLAG_ACTIVITY_NEW_TASK? I didn't have time to read properly about the differences between these two, but it might be a good idea to give it a try. 😄
There was a problem hiding this comment.
I like it - I think for backwards compatibility we shouldn't turn it on by default even though this is probably what everyone wants, but I don't see a reason not to merge it. It definitely allows a different sort of navigation experience for the user, which app creators may want
|
so I just +1'd it, but since you're active and have looked @MateusAndrade - I'll wait till you think on it and you can merge + release (assuming you also like it) ? |
Sure! We can definitely give it a try. Thanks a lot @SpiriaJWF! 🚀 |
# [7.4.0](v7.3.9...v7.4.0) (2022-05-05) ### Features * **task:** share with new task android ([#1195](#1195)) ([7ace66e](7ace66e))
|
🎉 This PR is included in version 7.4.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
# [7.4.0](react-native-share/react-native-share@v7.3.9...v7.4.0) (2022-05-05) ### Features * **task:** share with new task android ([#1195](react-native-share/react-native-share#1195)) ([7ace66e](react-native-share/react-native-share@7ace66e))
In Android, the external app for sharing opened within the current app. I needed to split these so the user can return easily to the app that initiated the Share action or the new opened app.