Deep link action always launches main activity

I send notifications with deep links with URIs which look like this

    myscheme://mydata

I have an activity which is configured to handle such URI schema:

<activity
android:name=".MyActivity"
android:noHistory="true"
android:theme="@style/NoActionBar">
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="myscheme"/>
</intent-filter>
</activity>

If I click on a UA push notification and my app is in the background, my app's main activity is launched first, and then MyActivity
is launched.
If I click on a UA push notification and my app is in the foreground, only main activity is (re)launched, MyActivity never gets launched.

I have verified that this is only the issue with UA notifications - hand-created notifications work as expected - MyActivity is
properly launched. Verified with this code:

long when = System.currentTimeMillis();
NotificationManager notificationManager = (NotificationManager)
context.getSystemService(Context.NOTIFICATION_SERVICE);

Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse("myscheme://mydata"));
PendingIntent pendingIntent = PendingIntent.getActivity(context, 555, intent, PendingIntent.FLAG_UPDATE_CURRENT);

Notification.Builder builder = new Notification.Builder(context)
.setSmallIcon(R.drawable.common_launcher)
.setContentTitle("hello")
.setContentText("Hello!")
.setContentIntent(pendingIntent)
.setWhen(when)
.setAutoCancel(false);

notificationManager.notify(System.currentTimeMillis() + "", 33, builder.build());

How can I avoid launching main activity when opening UA notifications with deep links?

Didn't find what you were looking for?

New post

Comments

17 comments

  • Hi Denis,

    You are exactly right, we always let the app launch an activity, or we auto launch one, then we perform actions.

    You have full control of how our SDK launched activities. You can use a broadcast receiver to return "true" and we wont launch anymore activities. You can check for deep link actions with:

    @Override

    protected boolean onNotificationOpened(Context context, PushMessage message, int notificationId) {

        Log.i(TAG, "User clicked notification. Alert: " + message.getAlert());

        Map<String, ActionValue> actions = message.getActions();

        if (actions.containsKey(DeepLinkAction.DEFAULT_REGISTRY_NAME) || actions.containsKey(DeepLinkAction.DEFAULT_REGISTRY_SHORT_NAME)) {

            // Just return true so SDK does not auto launch the main activity

            return true;

        }

     

        return false;

    }

    Comment actions Permalink
    0
  • Hi Michael,

    This was useful, thanks. Doing it this way makes the SDK not to launch main activity, however the target activity is launched as expected.

    Comment actions Permalink
    0
  • Yeah, I have confirmed this does not work.  Urban Airship totally ignores me returning true from onNotificationOpened, and no matter what I do, always launches the default activity with the default intent.  I DO NOT WANT THIS!  Even upgrading from UA 7.0 to 7.2 does NOT allleviate this issue.  Why does Urban Airship hate me?

     

    I literally have an onNotificationOpened method defined in my receiver that JUST spits out a log entry and returns true.  THIS SHOULD DO NOTHING yet it always launches my activity with the default intent that UA thinks is correct.  It is NOT correct and I want it gone.  Why is UA ignoring its own logic???  This is beyond frustrating. Fighting phantom / unexpected / double launches for over a month now and isolated it to UA ignoring its own logic.

     

    If I had any say in what dependencies we use for our app, I'd heavily recommend anything other than UA at this point based on my experiences.  There has GOT to be a better way to control what intent gets launched when I tap on a notification.  

    Comment actions Permalink
    0
  • I am working with Android.  The iOS version of our app does NOT have this issue and they use the iOS UA library.  Why do you guys hate Android so much?  Or if you do not, why do you enforce launching of the intent YOU want to launch?  I thought I was the programmer.  ( >< )

    Comment actions Permalink
    0
  • This SHOULD have something to do with it as well, I just found this option and added it to my airshipconfig.properties.  IT MADE NO DIFFERENCE EITHER.  Why does Urban Airship feel the need to decide the best action for me?  This is giving me serious reason to heavily recommend switching our commerce app to a different push notification library - ANY other library.  Pretty sure the rest of them won't force me to open the default activity if I specify other behavior, like UA is SUPPOSED to let me do.  

    autoLaunchApplication = false
    Comment actions Permalink
    0
  • BTW, my manually-created local notifications behave exactly as I program them.  No unexpected double launching of an activity.  ONLY WHEN SENT FROM UA do I have these issues.  How is this not a more widespread issue??  

     

    Comment actions Permalink
    0
  • HI Chris,

    I just tested the behavior in the sample application and it works as expected. Could you post your receiver, manifest entry, and any logs that you might have? Thanks.

    Comment actions Permalink
    0
  • My current goal is to get Urban Airship push notifications to do NOTHING when I tap on them.  THIS IS CURRENTLY IMPOSSIBLE.  Why is this not possible?  

    Comment actions Permalink
    0
  • Chris,

    It is possible, and should be working for you if your application is set up properly. You currently have provided no information other then its not working. I would like to help you but it will require your cooperation.

    Comment actions Permalink
    0
  • That would be fantastic.  I can not fathom what I am doing wrong.  

    Comment actions Permalink
    0
  •  Do you have verbose logs that you can provide that shows you receiving the push, opening it, and the main activity launching? What about a custom notification factory?  I don't see any problem with what you posted so far. 

    The flag `autoLaunchApplication` was introduced when we first moved to the BroadcastReceiver model, but wanted to provide a quick flag to revert the behavior if it didn't work for anyone. If you are returning true in that method then the flag should not matter. We determine if we should launch the main activity by sending out an ordered broadcast. If the ordered broadcast result is set to 1, then we assume the app handled the push and the SDK should not launch anything. By returning true in those methods, it should set the result properly, disabling our auto launch feature.

     

    Comment actions Permalink
    0
  • Yep, goal is to figure out whats going on and getting the control you need. Is it alright if I email you directly? Want to avoid accidentally posted any sensitive info on this forum.

    Comment actions Permalink
    0
  • Please do.  chris.paiano@nike.com

    Comment actions Permalink
    0
  • Can you please delete the files I've uploaded?  

    Comment actions Permalink
    0
  • We can delete in just a moment.   

    Comment actions Permalink
    0
  • Thank you.

    Comment actions Permalink
    0
  • Thank you, Ryan!  The email support session revealed and solved the issue.  My specific problem arose from our Urban Airship console always including a default deeplink (the "Data" or "^d" field) when our app only wants / consumes a custom field from the notification.

     

    The fix for me was to add the following lines to the method called when airship has taken off and is ready:

     

    ua.getActionRegistry().unregisterAction(DeepLinkAction.DEFAULT_REGISTRY_NAME);
    ua.getActionRegistry().unregisterAction(DeepLinkAction.DEFAULT_REGISTRY_SHORT_NAME);

     

    Now I can actually have full control over what tapping a notification does, even if it contains a default deep link each time in the ("^d") field!

     

    Thank you once more Ryan!!

    Comment actions Permalink
    0

Please sign in to leave a comment.