Hi, I am using Horologist (v0.2.3) libraries for my media app, I am facing a issue that whenever I c...

# compose-wear

[Akash Singh]

Hi, I am using Horologist (v0.2.3) libraries for my media app, I am facing a issue that whenever I click on the media notification on my watch the MainActivity gets recreated, I also tried using the Horologist sample app and the same thing happens there as well (MediaActivity gets recreated on notification click), I want to just resume the app if is in background on clicking the media notification, and recreate the activity only if app is not already in background.

Does anyone have some idea how can I achieve this behaviour, or am I missing out something ?

[yschimke]

This is by design. I don't think it recreates the activity, but I believe we reopen the activity with a specific deeplink. But I could be wrong, but this was what is intended and my mental model. (edit: I am wrong)

[yschimke]

The class used for player and download intents is here https://github.com/google/horologist/blob/6d119aae93d2b117d23cb39bfd9134f5b61d6f91[…]ndroid/horologist/media3/navigation/NavDeepLinkIntentBuilder.kt

[yschimke]

And configured here with uamp://uamp/player?page=0

[yschimke]

https://github.com/google/horologist/blob/0ba50ca1de056d4aca16740d5f9c8bde33215982[…]gle/android/horologist/mediasample/di/MediaApplicationModule.kt

[yschimke]

I'm going to

1. confirm my understanding, see when the activity is really recreated (but we are also at the mercy of the device, which may release to activity)
2. See how to reopen without changing it.

[yschimke]

I don't have an answer for this, and I'm not sure if it's because the previous activity is always released (paused + stopped) when you navigate to the launcher and click on the media notification. I might ask navigation related folk on this.

[yschimke]

I think it's https://stackoverflow.com/questions/72166094/how-to-prevent-pendingintent-from-creating-a-new-activity-in-android

[Akash Singh]

Yes, it's the same thing mentioned in the stackoverflow link, I'll try making this change in the sample app and see if it works as I want, thanks a lot

[Akash Singh]

For this
https://kotlinlang.slack.com/archives/C02GBABJUAF/p1669886855489789?thread_ts=1669839602.083509&cid=C02GBABJUAF

I just wanted to add, I have added logs in all the lifecycle methods and I am sure that previous activity is not getting released on navigating to the launcher. Also, if you just click on the app icon on the launcher after putting the app to background, it resumes instead of recreating, recreation happened only on clicking the notification

[Akash Singh]

In addition to that, if possible, I wanted to know your opinion on what should be the ideal behaviour on clicking the notification, resume or recreation?

[yschimke]

Resume, but clear the navigation stack and make it the top entry. On the right deeplink.

[yschimke]

I'm testing here https://github.com/google/horologist/compare/main...yschimke:debugging_launch?expand=1

[yschimke]

Got an answer from @Ian Lake in another forum. Seems WAI. The notification will always create a new task, and therefore activity.

[yschimke]

Yes, you'll always get the correct activity back stack and navigation back stack when handling a deep link on your task stack with the Navigation Component. The only way to ensure that is with a new task stack, which by necessity means a new activity instance. That is all WAI

[yschimke]

From my testing, the only one that reused it was

val launchIntent = application.packageManager.getLaunchIntentForPackage(application.packageName)

        return PendingIntent.getActivity(
            application,
            0,
            launchIntent,
            PendingIntent.FLAG_IMMUTABLE or PendingIntent.FLAG_UPDATE_CURRENT
        )

[yschimke]

But sounds like that is fighting the navigation library, so not sure we should put that in the sample.

[yschimke]

I've seen a lot of apps using onNewIntent with extras, so I wonder if they are doing this to workaround navigation limitations?

[yschimke]

https://github.com/Automattic/pocket-casts-android/blob/e7647d0a57cd8c82fca948c943[…]src/main/java/au/com/shiftyjelly/pocketcasts/ui/MainActivity.kt

[Akash Singh]

I think so, because if we resume the app on notification click, onNewIntent seems to be the only way to get the navigation data, I am actually using the onNewIntent approach in a Mobile app, although I am also skeptical of it being the correct way of doing the navigation.

[Akash Singh]

I also checked the YouTube Music app on wear, feels like it is also getting resumed on Notification click

[Ian Lake]

There's three states your activity's task stack could be in when your notification is clicked:
• It could have been removed entirely (you can't control this, the Android framework can do this at any point, even while your service is running)
• It could be on the actual activity you want to handle the Intent
• It could be on some totally different activity (e.g., the user has left the task stack when they were on your settings activity or on the system UI controlled screen to connect their Bluetooth headphones
But when you build your notification, you cannot know which of those cases you'll be in when the notification is actually triggered. This is particularly bad in the third case, where the default behavior if you just resume your task stack is to add yet another copy of your main activity (so you have main -> other activity -> main again). This is more of a limitation of activity APIs than anything else (they are indeed terrible), so the Navigation API enforce the correct back stack always. To do that, it needs to ensure the activity task stack is actually what you request, which is why it uses literally the only option available from the activity APIs and clears the whole task stack and creating it anew

[Ian Lake]

We had talked about how big of a hack all of the launchMode flags were literally years ago and how you absolutely shouldn't be using anything but the default, and, if anything, that is more true today:

https://youtu.be/2k8x8V77CrU▾

[yschimke]

Thanks for the explanation. Unfortunate but makes sense.

[Akash Singh]

Thanks @Ian Lake and @yschimke, this explanation helps a lot. I now understand the whole story of why the recreation actually happens