Android wechat share after stay in wechat, no callback solution to the problem

There are a lot of questions online about wechat sharing without callbacks, most of which are caused by incorrect configuration and incorrect package name of the WXEntryActivity class. However, the problems I want to talk about today are not caused by these improper integration problems, but the problems of wechat sharing SDK itself (or it is not a bug of wechat SDK, but wechat itself is designed in this way). The problem is that when we share successfully, wechat will pop up a pop-up window, allowing users to choose “stay in wechat” or “return to app”.

I recently encountered such a demand: the app guides users to share a tweet to wechat and rewards them with a coupon for successful sharing. However, if the user stays in wechat after successful sharing, the app cannot receive the callback of successful sharing and cannot determine whether the sharing is successful. This is obviously a serious problem that has to be solved. So how to solve this problem?

We might as well analyze the cause of the problem first: after the success of sharing, users have two choices: “stay in wechat” and “return to app”. If the user selects “Back app”, we receive the callback normally in this way. If users “stay in wechat,” we can’t call back. Therefore, as long as users can be detected to stay in wechat after sharing, users can be regarded as successful sharing. Because users cannot stay in wechat in case of failure or cancellation of sharing, we can also normally receive failed or canceled callback.

So how do we make sure users stay on wechat? Let’s take a look at how the current Activity life cycle differs when the user clicks “Back to app” versus “Stay in wechat” to get an idea. Note: The current Activity refers to the Activity that invokes the wechat share, not the WXEntryActivity that receives the wechat share callback. When a wechat share is activated, a Wechat share page is launched, overwriting the current Activity, and the current Activity’s life cycle is called onPause()->onStop().

As can be seen from the difference in the lifecycle callback above, “return app” will call onRestart() and onResume() at the same time, while “stay in wechat” will call onRestart() but not onResume(). If the Activity calls back onRestart() but does not call back onResume(), the user stays in wechat. That is to say, the user has shared successfully (only in this case can wechat be retained). Let’s test this idea with some code.

    private boolean isSharing;  // Whether the share is switched on. This value is true if sharing is invoked.
    private boolean isResume;  // Whether the Activity is in the foreground.

    @Override
    protected void onRestart(a) {
        super.onRestart();
        Log.i("TAG"."onRestart");
        if (isSharing) {
            isSharing = false;
            // There is a delay of 0.2 seconds before the onResume callback, since onRestart is executed before onResume.
            new Handler().postDelayed(new Runnable() {
                @Override
                public void run(a) {
                    // If onResume is not called after 0.2 seconds, the share is considered successful and wechat is kept.
                    if(! isResume) { Log.i("TAG"."Share success, stay on wechat"); }}},200); }}@Override
    protected void onStart(a) {
        super.onStart();
        Log.i("TAG"."onStart");
    }

    @Override
    protected void onResume(a) {
        super.onResume();
        Log.i("TAG"."onResume");
        isSharing = false;
        isResume = true;
    }

    @Override
    protected void onPause(a) {
        super.onPause();
        Log.i("TAG"."onPause");
        isResume = false;
    }

    @Override
    protected void onStop(a) {
        super.onStop();
        Log.i("TAG"."onStop");
    }

Copy the code

Share successfully, click “Stay in wechat”, log as follows: