I believe that it is common to sneak into the app to share it with WeChat friends or friends circles, such as the code for sharing a web page information (URL) to the WeChat client:
/**
* WeChat Share: Share the web page
* @param context
* @param url
* @param title
* @param description
* @param scene
*/
public static void shareToWeChatWithWebpage(Context context, String url,
String title, String description, int scene){
IWXAPI iwxapi = (context, WXEntryActivity.WXAPI_APP_ID);
if (!()){
(()).showToast("You have not installed the WeChat client yet");
return;
}
WXWebpageObject wxWebpageObject = new WXWebpageObject();
= url;
WXMediaMessage wxMediaMessage = new WXMediaMessage(wxWebpageObject);
= wxWebpageObject;
= title;
= description;
=
(((), .ic_share_invite), true);
req = new ();
= (());
= wxMediaMessage;
= scene;
(req);
}
Although I have used N times in different apps, there is still an error in a recent project: after executing this code, the application has no response, the WeChat client cannot be tuned, and there is no error message printing prompt. I had to check the official information - [Android FAQ], find a prompt like this:
Q：Calling the interface returns true, but the WeChat client has not started. Please check the following items:
A:
1) Is WeChat installed?
2) Whether the Apk package name and signature when calling are consistent with the open platform fill in. Please use this tool for signature: Click to download, which often happens when the debug version is installed and the release version is installed. After confirming the package name and signature, uninstall WeChat and reinstall it or clear WeChat data before doing tests.
3) Check whether the thumbnail size at the time of sending exceeds 32k
4) You can call WeChat to the selected friend list, but there is no response after clicking to send. Please check whether the proguard configuration is obfuscated with the WeChat SDK code. It is recommended not to obfuscate the SDK. Refer to the following proguard configuration:
-keep class .** {
*;
}
After inspection, the code was found(req);After execution, false is returned. In fact, according to the above Q&A writing method, it no longer falls within the scope of this problem. But I still checked it according to these four points. The local preview size of the sent thumbnail image is less than 20KB, and there is no problem with other configurations, but there is still an error. What is the problem?
Finally, in a try-and-see attitude, I replaced the thumbnail with a small image less than 7KB, and executed the code again, and the result was amazingly discovered:(req);Return true and successfully call up the WeChat client! At that time, ten thousand grass and mud horses galloped past in my heart!
After some excitement, I began to study why the thumbnails I used before did not exceed the limit of 32K of the official website document, but could not adjust the WeChat client? Is the official website document written incorrectly? The upper limit is not 32KB? So return to the source code and open the class provided by the WeChat SDKWXMediaMessage, find a series of constants defined below:
public static final int THUMB_LENGTH_LIMIT = 32768; private static final int TITLE_LENGTH_LIMIT = 512; private static final int DESCRIPTION_LENGTH_LIMIT = 1024; private static final int MEDIA_TAG_NAME_LENGTH_LIMIT = 64; private static final int MESSAGE_ACTION_LENGTH_LIMIT = 2048; private static final int MESSAGE_EXT_LENGTH_LIMIT = 2048;
As expected, the WeChat SDK has restricted the thumbnail size, title length, description length and other information shared to WeChat. Among them, the thumbnail size limit is 32768, and there is no comment in the source code to specify the unit. I was curious and divided it by 1024 and got 32. Isn’t this the upper limit value mentioned in the official website document 32KB (it means that the unit of the numerical value in the source code is Byte)! That means that the official website document is not written incorrectly, but what is the problem?
In fact, it is related to the actual hard disk usage and memory usage of the picture. Image files stored in the computer's hard drive will be compressed according to the compression rules of different image formats, thereby reducing the size of the hard drive. For example, lossy compressed image formats such as JPEG. In the Android system, the memory size occupied by reading an image into memory has nothing to do with the actual size of the image stored in the hard disk. It may be larger or smaller. Use the following code to obtain the memory size occupied by the image:
private Bitmap decodeResource(Resources resources, int id) {
TypedValue value = new TypedValue();
(id, value);
opts = new ();
= ;
Bitmap bitmap = (resources, id, opts);
("Bitmap", "size is " + () * ());
return bitmap;
}
in,() * ()What is obtained is the memory footprint of Bitmap, the unit is Byte, and then divided by 1024, it can be converted into BK units. Note: The above process of obtaining Bitmap objects from resources is not used directlydecodeResource(Resources res, int id)The method with two parameters is to avoid the problem of inconsistent memory usage caused by the storage of pictures in different drawable or mipmap folders. Friends who have some understanding of Android screen adaptation should understand this. I won’t go into details here. You can refer to an article by Brother Kaizi — [Research and analysis on the relationship between picture size, memory usage and drawable folders in Android].
Through the PS tool, modify the thumbnail size, and then use the above code to test the memory size occupied by pictures of different sizes in Android phones, and check whether you can adjust the WeChat client. After such tests, it was finally found that the upper limit size of the 32KB thumbnail in the WeChat SDK and official documents refers to the memory footprint, not the hard disk footprint of the picture. This will solve the problems I encountered before.
Finally, I have to complain about the criticism of Android WeChat SDK, which is also a common problem for some third-party service providers including Alipay SDK. I have no other intentions and I just vented:
• Signature uniqueness
Everyone who does Android development knows that the apk files compiled, packaged and run on mobile phones or emulators during the development process use the default common signature provided by the IDE, while the apk files officially released use the official signature file customized by the developer. When registering an application, the WeChat SDK can only enter one signature information, which means that the WeChat SDK related functions must be tested in the official package, and the official package cannot be tracked and debugged, which is very inconvenient. Of course, you can also do this. When you are in the development stage, register the signature information of the test package on the WeChat open platform, and modify it to the official signature file information when it is online; or you can also modify the default signature file of the IDE. But these are not very convenient. Wouldn't it be fun to register two or more signature information for an application like some other third-party service providers?
• The document is unclear
Many large third-party service providers only care about the provision of functions, regardless of the documentation instructions, and even the Samples code is written in a mess, which has caused our developers to not even have a complete reference description during use, and they have no idea where to start when there is any problem, and they waste a lot of unnecessary time and energy.
The article is a bit long-winded, mainly explaining the process of encountering problems, analyzing and solving problems when developing WeChat sharing this time. I hope to give you some reference.