The Whatsapp wa.me link does not correctly display the emoji sent in the text parameter on the desktop and web - whatsapp

I'm using the link wa.me in a web application for open a chat with a message with emojis. With the message like "Hi 😉" the formed link is like this:
https://wa.me/XXXXXXXXXXXXX?text=Hi+%F0%9F%98%89
When the user opens this link on the smartphone everything is fine, but on the desktop (and WhatsApp Web) the message is sent as "Hi �"
The emoji is encoded correctly ("%F0%9F%98%89"). I found that if I use the old api.whatsapp.com/send instead wa.me, I don't have this error. Could there be something wrong when wa.me redirects to the old api.whatsapp? I'm afraid to use the api.whatsapp in production because the whatsapp documentation doesn't talk about it anymore, and can be changed without notice, I imagine.

I stumble upon this GitHub repo: Social Share URLs That has a complete and updated way of using link on how to share to different social networks.
I stopped using:
https://wa.me/XXXXXXXXXXXXX?text=Hi+%F0%9F%98%89
And now I do it like:
https://api.whatsapp.com/send?phone=XXXXXXXXXXXXX&text=Hi+%F0%9F%98%89
and it works perfectly fine with emojis! In the preview of the API webpage shows the � symbol, but when entering the Whatsapp App it shows the emoji correctly!

Related

Whatsapp API not Working On desktop and PHP page

Good Day
I had a Whatsapp API I used in a URL to send a Whatsapp to a specific person or group in my contact list. Below is the code I used.
https://api.whatsapp.com/resolve?deeplink=/%3Ftext%3D%252AeTrack%2BNational%2BLookout%253A%252A
It normally worked fine and no issues. Now looks like Whatsapp page has been removed. I need a similar external link to send messages from my PHP page to a whatsapp contact or group. We use either Whatsapp Web or their Downloaded app on Windows. On our Android phones the link still works and opens Whatsapp and we can select the recipient. But using Chrome and a Windows system it does not open Whatsapp anymore.

Whatsapp share link does not work in safari

I'm using this approach: https://stackoverflow.com/a/25796908/3437433
It works like a charm, but when I'm trying to use it in Safari (both desktop and mobile), then quite strange things happen.
On desktop, origin link https://wa.me/?text=123 is somehow replaced with whatsapp://send?text=123. And then Safari displays error page about wrong protocol.
On mobile, correct page is opened by origin link, but also alert appears saying "can't open page because url is wrong". I can close that alert, can click on "send" button, but then https://whatsapp.com/download/ page is opened, instead of prompting to login to whatsapp and redirecting to chat.
Does anybody know what's going on here and whether it can be fixed?
We usually differ link at desktop view and mobile view to offer support for safari and other browser.
for desktop view we use
https://web.whatsapp.com/send?phone=6200000000&text=Hello%20Moxqitto
for mobile, we follow whatsapp best practice https://faq.whatsapp.com/en/android/26000030/
https://wa.me/6200000000
Tested on
Chrome for mac
safari for mac
android chrome
Ps: not tested when mac have whatsapp desktop app, but it will still work in the safari itself. so it should be ok
Official Sharing Documentation For WhatsApp. They say to use their wa.me/... URL. Okay! So let's try it out! http://wa.me/?text=mytest For me, I get an error message...
PAGE NOT FOUND
However, these seem to work great for me!
https://api.whatsapp.com/send?text=YourShareTextHere
https://api.whatsapp.com/send?text=YourShareTextHere&phone=123
If you are interested in watching a project that keeps track of these URLs, then check us out!: https://github.com/bradvin/social-share-urls#whatsapp

Disable Twitter Universal Deep Links

Update: It appears Twitter has fixed this issue. Clicking the authorize button now works! Thank you all for the responses.
I have a UIWebView that opens and directs to Twitters Oauth/Authorize webpage. The user signs in with there Twitter details and authenticates the use of our application with there Twitter account. This process worked perfect before the release of Twitter 6.37 iOS application. What happens now is when the WebView detects https://twitter.com/oauth/authorize?oauth_token instead of staying in the WebView it opens the native Twitter application and dies. If you uninstall the Twitter application everything works as usually it staying within the WebView. How can I prevent this from happening? I want to stay within my UIWebView and not automatically open deep links. I have been reading about the new URL deep link changes in iOS 9, but not sure of how to stop them from my application to other native applications. Thanks for any help!
As a workaround, in twitter authentication screen we can use the Go button on iOS typing keypad instead of using the sign in button on web view until twitter fixes.
Please refer the attached screenshot link for clarity.
Screenshot for the workaround
I ran into this issue as well and figured out it was because my authorize endpoint was set to https://twitter.com/oauth/authorize?oauth_token="+oauthToken (I believe this was in the original documentation). If you add api as the subdomain: https://api.twitter.com/oauth/authorize?oauth_token="+oauthToken, it will no longer trigger the deep linking and load the twitter app.
My answer to this via a Xamarin question:
Unless Twitter removes/updates the apps section of "https://www.twitter.com/apple-app-site-association" to allow a bypass or a secondary oauth that is not in the apple-app-site-association file I do not see how you would do it. These files are signed and iOS handles them at an OS level.
I have not played around very much with the continueUserActivity delegate and the NSUserActivity object that is passed to apps launched from UNI links, but I do not see a way for the launched app (i.e. Twitter) to return control to the original app, and at that point the oauth call-chain would be broken anyway....
Unique. Unlike custom URL schemes, universal links can’t be claimed by other apps, because they use standard HTTP or HTTPS links to your website.
Secure. When users install your app, iOS checks a file that you’ve uploaded to your web server to make sure that your website allows your app to open URLs on its behalf. Only you can create and upload this file, so the association of your website with your app is secure.
Via: https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/AppSearch/UniversalLinks.html
I would report as an issue (bug?) to Twitter's Dev forum: https://twittercommunity.com

iOS App URL is not being detected

I have created a custom App URL for my iOS app. The URL format is similar to this:
myappname://texttobeparsed
This works fine when I paste the URL in safari, My App opens and correctly handles the URL. The problem is that other apps such as iMessage or Notes do not recognize this as a URL.
Why isn't this URL scheme being recognized as a URL? Could it have to do with how I set it up in my info.plist file or something else?
Or, does the URL need to be in a different format to be recognized?
I know it's possible to have the system recognize it as a URL in apps other than web-browsers because I've seen it before with other apps (ex. iTunes: itms://itunes.com/apps/appname or Twitter: twitter:// or Facebook: fb://).
There's nothing you can do about this. If the link isn't explicit (e.g. in an HTML email), these apps can just recognize a built-in set of standard URL schemes. itms:// is one of Apple's own schemes (for the iTunes Store), so it makes sense that it is supported in addition to the standard mailto://, http://, tel://... schemes.
Edit: I would guess that the information that is used to determine what constitutes a valid URL in text views etc. is cached somehow. Contrary to what I initially guessed, it seems that app-specific URLs do work in Notes, etc. I've tested this with tweetbot:// for example (which I have installed) and twitter:// (which I don't have installed) to verify that it doesn't just check for a pattern like *://, but actually uses information about the installed apps.
I'd suggest that you try to restart your device. If it's an issue with some cache, that might help and I don't think there's much else you could do if your URL scheme already works in Safari.
Update: I've installed the official Twitter app to test this, the twitter:// scheme wasn't immediately recognized in Notes, but after killing and restarting the Notes app, it worked.
Update 2: I've done a minimal test app with myappname:// as a custom URL scheme. Again, like with the Twitter app, it worked after restarting the Notes app, so it doesn't seem related to the popularity of the app or whether it's been submitted or not.
I can't answer as to why it's not working (beyond guessing that the link interpreter is hard-coded to only recognize certain URL schemes), but I can say that the typical way around this is to link to a web page, and have the web page redirect to your custom scheme.
It's slightly less elegant, because the user will see Safari open up briefly before being forwarded to your app, but it's also more robust because the web page can provide a link to the app store to install the app if it is not installed on the user's phone.

How to launch Facebook with Button

Hey friends
I created a button on my app called: "Find us on Facebook". Right now I ran into a situation where I need the button to launch the Facebook application. I could really use some help such as launching the facebook application, detecting if there is a facebook application, and all the sorts of stuff like that, thanks
Some googling shows that the facebook app apparently registers to receive urls with the fb:// scheme. So you can construct a fb:// url (like, say fb://notes or something) and then ask the UIApplication object if it can open the URL. If it says that it can, then open it.
there is a tutorial and sample app at https://github.com/facebook/facebook-ios-sdk
Basically you need to try to call fb://profile/yourpageid to load the FB app on your page.
The sample app shows you how to do this and fall back to loading in Safari if the app is not installed on the device.