"In the case of NativeScript - it uses platform declaration files that have been written to easily navigate through native api's of the device. Lets see what does it take to Check and have a continuously updated level of battery on our screen."
The question is, who has written these platform declaration files? Will they always be up to date? Or will a future Android API release possibly deprecate some of these features requiring an upstream maintainer to update these binding libraries?
This seems to be the same approach as what Xamarin uses, with their Android API binding libraries. They are automatically generated, I assume NativeScript is the same. Whenever there is an API platform update, these binding libraries are updated, so you will always depend on these binding libraries.
The other issue I see with this approach is that when you write your own code in .ts and use these binding libraries, if you have a bug or an error that you introduce, and it throws an exception, the exception will be a NativeScript exception, not a native library exception. I used to experience this personally with Xamarin, and googling exceptions is extremely difficult (as, logically, there will always be more people experiencing that issue in the native language than in C# or whatever, so your chances of finding a fix are reduced).
The Flutter way of doing this is to abstract away the platform specific functionality into that platforms language. It means you have to know a bit of Kotlin or Swift to get around but it also means that you are 100% in control of your own app and you're not relying on these binding libraries to be up to date. Which I think is a lot, lot better. Of course that's just my 2 cents :)
Thank you for your opinion. It's a valid one concerning the debugging as the errors are really like you say, hard to figure out on what's happening. This was probably most annoying thing for me to work with NS in terms of productivity.
However having the native API library definitions just seems very easy to work with when developing some native functionality requirements.
Beats knowing Swift and Kotlin by far in my eyes as it could get complex to write native platform code.
Again, thanks for commenting and have a happy Valentine's day. 🙋🏻♂️
NativeScript has a metadata generator whereby platform APIs are up to date at build time (by each individual developer) - this allows anyone at anytime to generate up to date types at their own disposal for any SDK version they are targeting (eg, 'ns typings ios' or 'ns typings android') - no maintainer or third party required. You are in 100% control 100% of the time.
The author is correct here that there are two different technical problems that each address. One important point perhaps is that NativeScript developer can take advantage of Skia inside their app - not sure the same could be said for the inverse.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"In the case of NativeScript - it uses platform declaration files that have been written to easily navigate through native api's of the device. Lets see what does it take to Check and have a continuously updated level of battery on our screen."
The question is, who has written these platform declaration files? Will they always be up to date? Or will a future Android API release possibly deprecate some of these features requiring an upstream maintainer to update these binding libraries?
This seems to be the same approach as what Xamarin uses, with their Android API binding libraries. They are automatically generated, I assume NativeScript is the same. Whenever there is an API platform update, these binding libraries are updated, so you will always depend on these binding libraries.
The other issue I see with this approach is that when you write your own code in .ts and use these binding libraries, if you have a bug or an error that you introduce, and it throws an exception, the exception will be a NativeScript exception, not a native library exception. I used to experience this personally with Xamarin, and googling exceptions is extremely difficult (as, logically, there will always be more people experiencing that issue in the native language than in C# or whatever, so your chances of finding a fix are reduced).
The Flutter way of doing this is to abstract away the platform specific functionality into that platforms language. It means you have to know a bit of Kotlin or Swift to get around but it also means that you are 100% in control of your own app and you're not relying on these binding libraries to be up to date. Which I think is a lot, lot better. Of course that's just my 2 cents :)
Thank you for your opinion. It's a valid one concerning the debugging as the errors are really like you say, hard to figure out on what's happening. This was probably most annoying thing for me to work with NS in terms of productivity.
However having the native API library definitions just seems very easy to work with when developing some native functionality requirements.
Beats knowing Swift and Kotlin by far in my eyes as it could get complex to write native platform code.
Again, thanks for commenting and have a happy Valentine's day. 🙋🏻♂️
NativeScript has a metadata generator whereby platform APIs are up to date at build time (by each individual developer) - this allows anyone at anytime to generate up to date types at their own disposal for any SDK version they are targeting (eg, 'ns typings ios' or 'ns typings android') - no maintainer or third party required. You are in 100% control 100% of the time.
The author is correct here that there are two different technical problems that each address. One important point perhaps is that NativeScript developer can take advantage of Skia inside their app - not sure the same could be said for the inverse.