Is there a way to open a `Composable` screen when ...

# compose

[Isaac]

Is there a way to open a Composable screen when the app receives a notification while it’s in the foreground without using a PendingIntent? Cc: @louiscad

[louiscad]

Nope, there's no way, you must use a PendingIntent for notifications on Android, no matter what. Are you looking for an implementation guide? If so, I can share my draft article on doing that with Compose Navigation.

[Isaac]

Yes I’ll be so glad if you can share the draft @louiscad

[Ian Lake]

If you're following the guide for deep links in Navigation Compose, it already explains how to handle both explicit (i.e., PendingIntents for notifications) and implicit deep links (i.e., for handling web URLs)

[Ian Lake]

forgot the link: https://developer.android.com/jetpack/compose/navigation#deeplinks

[louiscad]

I don't recommend using deep links if it's for a foreground service though, because it removes all previous navigation

[louiscad]

That's actually the reason of me writing the draft.

[louiscad]

Links in the browser are far superior, you don't lose your progress in other tabs of the same website. I personally dislike that Twitter forgets where I was because I clicked on a notification. I'm not forced to endure this on the WEB. Why should I accept it on my phone, apart from the fact that I have little choice?

[louiscad]

Deep links are not WEB-like, they are potentially destructive when it comes to user progress, unless the app developers took the time and special measures to not have them obliterate user progress in an irreversible way.

[louiscad]

Here's my draft: https://hashnode.com/preview/61944f5a3011d8453957e161

[Ian Lake]

Note that the behavior we've set is based on a whole set of UX studies that we did including diary studies, bringing users in, and surveys. The absolutely most important thing that we found from those studies is that a consistent experience (i.e., you always go back to the same set of synthetic back stack destinations, you always have the same activity back stack, etc.) was absolutely the first priority when it comes to opening your app via any kind of deep link. The level of uncomfortableness that real users got when back wasn't consistent and predictable was much stronger than any other signal

[Ian Lake]

That does mean that handling of deep links (whether via NavDeepLinkBuilder in the Navigation with Fragment world or Uri based deep links, they both do the exact same thing) certainly does enforce a consistent activity task stack and navigation task stack

[Ian Lake]

The Single Activity talk from years ago actually specifically called out cases where you might want to use documentLaunchMode="intoExisting" for conversations or other types of content to maintain a separate task stack that wouldn't override the main task's stack - Google Docs remains a great example of how that works and provides the exact kind of separation that you need to support multitasking on Android

[Ian Lake]

Also I'll note that you don't need to include an intent filter at all if you want is to support explicit deep links (which would certainly be the case for your own PendingIntents for notifications) - intent filters are only necessary if you want implicit deep linking support. You can just set a ComponentName on your Intent to make it an explicit Intent; Navigation's deep link dispatch is agnostic to what mechanism you use to get to the activity, it only cares about the Intent itself

[Ian Lake]

And keep in mind that Uris are not the only kind of deep links supported - an action string might be all you need for many cases

[louiscad]

Interesting to know that intent filter declaration is not required.

I'll look at documentLaunchMode as well, and keep improving my draft to help readers make an informed decision about the in-app linking technique for a given destination and use case.

Thank you