NativeScript
Feature request: Linking interface
It's a common problem to detect redirections via deep linking and it would be awesome to have a core Interface to reuse the logic, also it's very useful creating plugins to detect that for all platfoms (Android & iOS).
Describe the solution you'd like
Create something like this: https://facebook.github.io/react-native/docs/linking
Linking gives you a general interface to interact with both incoming and outgoing app links.
Common methods:
- openURL (It's already supported from tns-core-modules/utils/utils)
- canOpenURL (Determine whether or not an installed app can handle a given URL.)
- addEventListener (Add a handler to Linking changes by listening to the url event type and providing the handler)
Alternatives you've considered:
- nativescript-urlhandler (But it's not a verified plugin to have as a dependency from other plugins).
Additional context What do you think to support deep link paths from the navigation too?
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
@jdnichollsc - NS tries to keep the core fairly small and lean.
Most apps don't need deep linking, so I don't understand the issue if their is a plugin that already solves the issue... Deep linking really isn't a core feature; it is imho a plugin feature. :grinning:
@NathanaelA but you can't remove the listeners from those plugins and Oauth authentication (deep linking is required for this) is a very common situation for mobile apps :/
On the other hand, from iOS platform other plugins can override application.ios.delegate and that's a problem here, what do you think?
I mean Can you guys analyze the possibility of this? It would be very helpful having a general interface to interact with both incoming and outgoing app links. 🙏
Well the ios framework delegate issue is an issue that the core team and I have debated many times of the last four years; I even had a PR that was rejected because they didn't like the way I was trying to easily open up access to the delegates outside of the framework (for plugins) -- and imho it still is the second best way to solve the whole issue (no breaking changes, and would allow plugins access right now without breaking each other, so it is still the best way for quickly moving forward without breaking anything)... The actual best way to solve this issue is some major reworking, and maybe they will consider it for NS 8 or 10 (as it would be breaking changes if I recall correctly). I don't see issue being solved anytime soon, since we have been debating it since before NS 2, it is imho one of the biggest issues with extending the iOS side of the framework... :frowning_face:
If you created a PR, they might be willing to accept it, but for them to even consider adding your PR, it has to offer them something that a plugin can't (normally) and be code that can be easily maintained without breaking or complicating things..
As an example; Android 6+ requires most permissions are asked for at runtime. This would be a feature that would be great in the framework, as almost every Android app needs it at some point. They have even probably debated it internally several times on if they should just subsume my ns-permissions plugin and integrate it inside the framework. It is a very stable permissions plugin for Android, and works for virtually every permission known to man. :grinning: However, by leaving it outside of the framework; they don't have to maintain it. The community maintains it and it is simple to add to your project. Even some plugins use it as a dependency.
For them to add it, it has to be a feature that is more important than most other framework work -- i.e. the work has to be justified taking it from other open PR's and issues... In my humble opinion, this feature is not something I would have them work on; there are considerably way more important things (like the delegate access system I mentioned above... :grinning:) than this feature which I've never once needed to use in so far about 20 clients apps. :grinning:
So all that to say, ask them if they would be willing to take a PR for this feature, if they are -- make the PR... :grinning:
I would like to know your opinion first, if it makes sense to make that effort, I just consider it an opportunity for improvement compared to the utilities that React Native has and they are precisely moving a lot of components to the React Native Community https://github.com/react-native-community to make the Core as clean as possible.
@NathanaelA @NickIliev I agree that maybe it is better to have it as a plugin, but would be nice to have it as an official plugin from nativescript, since the last plugin nativescript-urlhandler has been abandoned
@Jonatthu - Not sure NS-urlhandler has been abandoned yet -- it was updated only a month ago...
Maybe he's talking about this comment https://github.com/hypery2k/nativescript-urlhandler/issues/88#issuecomment-534251491
@NathanaelA Last was 6 months ago plus this comment confirms https://github.com/hypery2k/nativescript-urlhandler/issues/88#issuecomment-534251491
Ah, thanks for the link. This plugin might be a good candidate to join the awesome ProPlugins. :grinning:
Also, I think we need the possibility to remove listeners, like removeEventListener method or something like that to remove subscriptions detecting deep linking redirections :)
E.g:
_handleOpenURL(event) {
console.log(event.url);
}
ngOnInit() {
Linking.addEventListener('url', this._handleOpenURL);
}
ngOnDestory() {
Linking.removeEventListener('url', this._handleOpenURL);
}