Previously shared a reprinted wechat share pit filling article

It basically covers the basic operations of wechat sharing function development.

In the actual project, I encountered a puzzling problem when tracking wechat sharing.

After adding the user sharing tracking function, when the page has been loaded, Android sharing function has no problem, but ios always fails to share.

About the differences between ios and Android devices

The requirement of the project is that we need to track the sharing behavior of users and record the links they share from whom. So each user has a unique share code.

User A shared it with his own share code on the link. When user B clicks the link, he sends the share code on the current URL to the back end for record and replaces his share code at the same time.

I use the substitution argument by directly modifying the Router’s Query

this.$router.push({
  name: 'routername'// The current route name query: {sharecode:'sharecode'// Sharecode}})Copy the code

After adding tracking records, it turns out that Android devices can share successfully and get the correct records. However, ios always fails to share, even if you switch to another page, you still can’t share until you refresh the page…

amazing…

How do I interact with the back end

Signing is what the back end and wechat server do. All I need to do is pass the URL to sign to the back end.

The approach is very simple, is to listen for route changes (only change parameters also need to listen), each change to the back end of the URL.

Because no matter what channel you click into our link, a share code will be generated and added to the route, causing the page to trigger two route changes at the beginning; Moreover, if the user did not log in, wechat dad will also forcibly jump authorization, resulting in a page reload, so if a user did not log in, the page will trigger 4 route changes! That would require four interactions with the back end.

Can’t endure!

Finally, the first time entering the page is not recorded by default, so that the first screen only needs to interact 2 times at most (highlighted, later to test).

The above story tells us why people want to die

So let’s go back to ios sharing failures

To solve the process

Chorme browser debug mode found no problems, wechat developer tools found no problems, is the ios real phone appeared this bug. Wechat developer tool is actually an android wearing the coat of ios? The dev environment is ios and behaves exactly like Android.)

After painstaking online and offline debugging, it was found that there was a problem in the step of replacing others’ share codes with their own share codes on the real phone.

Sharecode parameters can be replaced on Android devices, but not on ios. The URL used by the back end for signature is the link replaced by sharecode, so the signature and route do not match.

Make sure there is no problem with the route parameter substitution method, because the Android environment can do this normally. So what about the ios environment?

This raises a question: how does ios replace routing parameters in the current page under the VUE framework?

And finally, ungraceful overloading — I’m sure I’ll find a way around it.

So the end of the first day —————————— time to the second day ———————————— continue to fill the pit

Reloading such a disgusting method of course not, do not continue to do

Just alert all the urls.

Then, on ios, something amazing happened

  1. Click on a link, for examplehttp:example.com/a&share=111
  2. There is no problem with the current URL popping up in ioshttp:example.com/a&share=111, then the next step is to replace the share code and replace the share with 222, that is, in theory the URL will becomehttp:example.com/a&share=222.
  3. By yesterday’s logic, the share will not be replaced. You can pop up the URL and find that it has been replaced! The current URL is indeedhttp:example.com/a&share=222.
  4. Then share the url and copy the current URL.
  5. Share failure! Paste the url you just copied, share is still the same111! WTF!!!! ?

Ok, then I go to the next step

  1. I switched my path frequently, jumping to C and D, etc., and the URL generated by alert also changed as I switched.
  2. Share on page C or D and copy the current URL.
  3. Share failure! Paste the url you just copied, share is still the same111! (You didn’t read the serial, it’s the same as the one above)

The above phenomenon can be concluded that in the ios environment (Android shares normally, so there is no test to see whether the same behavior exists), if the signature verification fails, no matter how the route changes, not only the sharing itself will not succeed, but also the shared route is always the route when it is first loaded.

I found out later that ios has a different signature verification mechanism than Android.

  • Android: to need to share each page route signature, and load the page to share information
  • Ios: just sign the first page route and load the share information for each page to be shared

What does this show? In the ios environment, wechat only recognizes the routes coming in for the first time.

Let’s repeat the point of interaction with the back end: by default, the first time you enter the page is not recorded, so the first screen only needs to interact 2 times at most

Don’t record your big head

Finally, when determining whether the environment is ios, honestly record the first route.

Do you have to load the first screen up to 4 times on ios?

Listen carefully to the children, reward you a big red flower ~

But! Ios only recognizes the first route, I only need to pass the first route to the back end of the line, listen for route changes! No! Use! ! (smile)

Nuggets homepage: Ruyi students

Jane Book home page: Ruyi students

B station live address, every Friday night irregularly live, occasionally write code, occasionally read, occasionally watch learning video, occasionally do some messy (anyway and study related), welcome to learn together! Yukio okamoto, ~