Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Other packages are not receiving custom URLs #120

Closed
mbkim95 opened this issue May 10, 2024 · 3 comments
Closed

Other packages are not receiving custom URLs #120

mbkim95 opened this issue May 10, 2024 · 3 comments

Comments

@mbkim95
Copy link

mbkim95 commented May 10, 2024

Describe the bug

Hello. I'm an maintainer of kakao_flutter_sdk plugin.
This plugin provides a number of features specific to the KakaoTalk app (South Korea's messenger service)
Typically, It provide login throught the KakaoTalk app.

I'm experiencing issues when using app_links and kakao_flutter_sdk together, so I was wondering if you could look into this.

kakao_flutter_sdk get authorization code via the application(_:open:options) method when handling login in the iOS. (url is kakao${app_key}://oauth?code=${authorization_code})
However, The application(_:open:options) method in app_links is returning true, so application(_:open:options) method in kakao_flutter_sdk is not being called.

The kakao_flutter_sdk doesn't seem to be able to handle this issue, and I didn't find a solution in the app_links guide.
Could you please let me know if there is a way to resolve this issue, and also explain why you changed the return value of application(_:open:options) in app_links to true. (I have read the changelog) Or maybe you could modify the return value of application(_:open:options) to false?

Does it related to

[ ] App Links (Android)
[ ] Deep Links (Android)
[ ] Universal Links (iOS)
[x] or Custom URL schemes? (iOS)

Does the example project work?

[ ] Yes
[] No
[x] Irrelevant here

Did you fully read the instructions for the targeted platform before submitting this issue?

Uploaded your files to webserver, HTTPS, direct connection, scheme pattern setup, ...

[ ] Yes
[ ] No
[x] Irrelevant here

@llfbandit
Copy link
Owner

You're right, since we're all isolated from each other there's no possibility per plugin to workaround this. That was a bad decision on my side.
I'll release soon a new version reverting this behaviour change to ease usage.

@llfbandit
Copy link
Owner

Change has been reverted in 6.0.2.

@mbkim95
Copy link
Author

mbkim95 commented May 14, 2024

Thanks for responding to the issue so quickly! I've confirmed that it works fine in the version you fixed!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants