Detect which Runtime?

[NathanaelA]

Is their a command to get the current android runtime version, this would be very useful for add on. I've got a add-on that is going to require a patch that hasn't been deployed yet. This would be great if I could say
if (__versionRuntime <= "1.02") then doSomething()

[blagoev]

Thanks for the suggestion, we will consider how this can be best done and what implications it has.

[NathanaelA]

Is their any news on this. Their is a nasty bug in v1.6.0 of the runtimes that I have to code around. 1.0-1.5.x works fine, and I'm sure it will be fixed in v1.6.1; but in my code their is no way to detect which runtime it is running on. This is something that would be VERY helpful to plugin developers.

If you have a preferred variable name, I might see if I can code up the Android side. Their is already a story/issue for doing this on the iOS side also.

[Plamen5kov]

Hi, @NathanaelA
Can you say what particular problems you are having with v 1.6.0?
And because you mention that having the version easily available would be very helpful to plugin developers, could you share what scenarios and user cases you have in mind. Having a version available in javascript is one possible solution but it might not be the best one, so IMHO we should explore what other options there are before committing to anything.
Having a version of the runtime easily available in javascript seems like a slippery slope to me.

EDIT: If you wan't to use the version of the runtime as a workaround you can do:

var packageJson = require("./package.json");
var runtimeVersion = packageJson.version;

[NathanaelA]

Why would having access to the version be a slippery slope? changes occurs, bugs happen, being able to detect the version would allow me to code around them. This is not something I can easily "feature" detect if a bug that crashes the engine is present...

The main factor is that v1.6 of the Android runtime breaks the Application.context timing.

1. If you attempt to use anything that attempts to get the App.Context the runtime will throw an error message about already being initialized on startup and CRASH!. This includes, if I attempt to use ANY straight Java calls to get the context. (Unable to run existing android app after upgrading to 1.6.0 NativeScript#1577)

At this minute I am having to do a detection call on if the app contect variable doesn't exist, if it doesn't exists I have to a setTimeout loop until it exists. NASTY HACK, but their is no other solution that will work on all engines. If I had a version number, then I could say; if version >= "1.6.0" then use hack and put notice up, otherwise use the reliable method I've used since v1.00. (If you read the 1577 report you will see where this fix probably won't show up until 1.7) This hack I'm using is still not even totally foolproof as some of the calls to my plugin if they are done before App is initialized will still crash the engine with the same error. All those calls were direct data return calls; so I can't really change the api, any more than you can change the appSettings api (which will crash the engine if used before app.start(). The good news is odds are very low that any of my plugin calls will occur before the engine is initialized. I've also let everyone know that the safest to do any work in the app.js file is to do:

var app = require('application');
var screen_info = {moduleName: 'main-file'};
if (global.android) {
  app.start(screen_info);
}

// do all the work

if (!global.android) {
  app.start(screen_info);
}

Also pretty hacky, but at least it is very safe. iOS runtime doesn't run ANY code after the start. Android runtime we now need to do the start right away to eliminate any chance of crashing on startup.

---

\2. If you attempt to use clearHistory with navigation the navigation stack is corrupted (NativeScript/NativeScript#1569) -- This one might be core modules, not sure yet who is the guilty party. But if I could detect the engine than I could easily make sure my login plugin doesn't use the clearHistory flag so that the poor developer isn't wondering why the app is randomly crashing with weird issues.

\3. Some plugins no longer function properly in v1.6 and have weird results (including crashing). (Like: NativeScript/NativeScript#1585) Once a fix is found, the fix might be only relevant to v1.6x and may need to be flagged to be on in v1.6+; and flagged off in 1.5.x.

\4. It is a lot easier to do feature flagging when you know the engine actually supports the call. For example say I have a plugin that works perfectly fine in v1.2-1.5, but v1.6 adds the awesome new % sizes. I can start using that features in my plugin since I know it exists in v1.6, and continue using the old methods in the prior versions.

Please note I do realize I can do some of this by using the tns_modules/package.json and using that to detect which core modules I'm running. However, the core modules might not give me enough of the picture to know if it safe to do certain things that are only fixed (and won't crash) in the later versions of the runtimes.

If you look at the (NativeScript/NativeScript#609) reference above you will see that ligaz also asked for a engine version constant; and if you check the iOS issues; you will see a story (NativeScript/ios-jsc#123) for the same ability. I'm not an isolated case. 😀

[NathanaelA]

I should also mention Node.js has also included the versions of EVERYTHING in their process.versions (https://nodejs.org/api/process.html#process_process_versions) You would think that instead of making it more detailed if they thought this was a hindrance, they would mark it as depreciated. ;-) Node.JS has a way bigger JS community that NativeScript probably will ever have.

PHP Has http://php.net/manual/en/function.phpversion.php a way to get not only the version of the main php engine, but you can request the version for any extension.

ASP.Net has a couple ways to do it.

And of course the browser has the userAgent with the browser and version in it.

[Plamen5kov]

The main problem you are facing will be fixed with 1.6.2 release with this commit.
As far as i know, although there is an issue on the version matter, it hasn't been accepted and as far as feature parity goes it won't be a good idea to have this feature present only in the android runtime. I never said your case is an isolated one and please try to understand that I want to find the best solution for the problem.
I can't be convinced by the fact that everyone else is using versioning. By the same logic if everyone else were using feature detection it would be a good idea for us to do it as well.

[slavchev]

Hi @NathanaelA

I've read carefully your points and while I understand them I don't think versioning will help. Before I go into the details I would like to make it clear that whatever decision we take there will be a trade-off.

About 1) It is indeed a breaking change on our end. We did a change in modules and the runtime and It was hard to assess the impact of it. As a result we break some existing apps. We already committed the fix in the release branch and this morning we discussed to release a new version 1.6.2 tomorrow. I don't want people to use any versioning scheme in their plugins in order to provide a workaround for the breaking change we made. I prefer to fix the bug once. Also, suppose that this bug resurrects in a future version. It is not unheard, nobody's regression tests are perfect. I don't consider versioning a good tool in this scenario.

Points 2) and 3) are similar to 1) I guess this kind of issues will be eventually solved in different manner. I guess the npm builtin versioning comparability feature will be the preferred approach. Also, we can take a look at the guys from WordPress and see how they deal with the versioning/plugins issue. There is no silver bullet and in both cases there is always a testing step involved.

About 4) I think the explicit feature/API availability/discoverability is always proffered to version checks. I would love to discuss how this can be improved in {N} and implement a proper solution. Many of us remember the User-Agent horror and the problems it creates. I definitely don't want to go that way.

[NathanaelA]

@Plamen5kov - Feature parity is a horrible reason. If that is the case; then where is my cool non es5 "yield" in the android runtime? it has been present in iOS runtime since I think 1.4. If your going to quote feature parity, then I want that feature "parity" asap and then you can argue feature parity! 😀 Oh, I way prefer feature detection over versioning, but even with feature detection you sometimes still needed versioning (see my question 4 to slavchev).

@slavchev -
\1. Well that is awesome to see the fix will show up sooner rather than later. I fully understand how bugs occur, I wasn't complaining about the bugs -- those are a fact of the profession I've chosen to be in. What I am complaining about is you are handicapping ME in being able to provide a solution. If I had version detection ability since v1.5 then I could have totally worked around the issue in v1.6, without impacting ALL versions of my plugin because of a bad runtime.
2 & 3. Actually I would tend to disagree with you, the version would be the silver bullet. 😀
\4 - I totally recall the versioning vs feature detection; I was developing JS code on Netscape Navigator. I've been around a while. 😀 .
On Feature Detection, can you explain to me how I can do feature detection on the following new features in v1.6? (NativeScript/NativeScript#1355) (NativeScript/NativeScript#1283) and (NativeScript/NativeScript#1553)

Please note I know several people who have either chosen to stay on the 1.5 runtimes or have reverted to the 1.5 runtimes because of issues. So their is no easy way for me to say; yeah these "new" features exist. So for me to have some way to detect version is critical for some cases.

[slavchev]

@NathanaelA

I do realize how my concerns about versioning may look hostile for many of the community. I have to say that I value your opinion and the great work you do for {N} :) Please don't take my unwillingness to introduce versioning as something set in stone. Yet, I am not convinced versioning is a good way to go. Once we introduced it will be very hard and painful to remove it if we revisit our decision. Also, please note that I don't want take this decision by myself and I would rather keep the discussion going.

I hope that all can see that for important and critical breaking changes, like #362, we try to provide a fix as fast as possible. In the concrete example our time to reaction is just a few days. I hope this gains the trust of the community. Also, as an active community member you have very quick time to react for every {N} release. Sometimes it may seem that we are holding you back but it is definitely not our intention. It is just the fact that we are trying to be more conservative when providing a new feature. I do realize this can be frustrating and I guess it is a matter of time until both sides learn to deal with such issue. We will try to act more quickly, that's for sure.

Now, about the versioning. We've all seen code full of version checks and it is not pretty. I don't mind if it is pretty or not but more importantly often these checks don't work for many scenarios. Bug regression is just one example. There are other alternatives to versioning. We can provide API contracts similar to the ones in Android or UWP for example. Also, maybe it is a good time to revisit our thinking about semver. As I said earlier I would love to help and dig deeper into the this and provide solutions starting with the most critical issues. Also, I would encourage everybody involved to look closely at solutions provided by npm and WordPress.

Besides, because the runtimes are npm modules we have the version info already. Look at the package.json which is located as a sibling to the app folder. It looks as follows:

{
    "nativescript": {
        "id": "org.nativescript.app",
        "tns-android": {
            "version": "1.6.1"
        }
    },
    "dependencies": {
        "tns-core-modules": "1.6.0"
    }
}

I will check with @teobugslayer and @rosen-vladimirov to see whether it is a good idea to merge its content with app/package.json file so that @Plamen5kov proposal can work.

In any way, I would kindly ask not to rush in providing versioning mechanism without thorough discussion.

[NathanaelA]

@slavchev - Don't worry I don't take any offense at a no, or any push back. I've been developing for a really long time and never take a no to mean I did anything wrong, it just means your wrong and you haven't figured it out yet.(:grinning: Joking!) But sufficed to say it doesn't affect my ego, in the slightest. :grinning: As long as you are upfront and straight with me I am good!

I wrote this to another Telerik Employee already on another issue. I am a very opinionated developer , and I am willing to speak my opinion. I am not offended in the least when you guys disagree with me. ;-) But try to understand I will overwhelm you with reasons to make you want to say yes. 😀 But if the decision comes down to a no; then it is a no, and I will live with it. And I feel no hurt feelings over it. So pretend and treat me like I'm a member on your team and you told me that the direction you wanted to go was without versioning. I'm good with it!

I am really happy that the App.Context issue will be fixed/worked around shortly. clearHistory would be another one that should be patches asap.

I am confused about what proposal you are saying @Plamen5kov is talking about; I mentioned using the app/tns_modules/package.json to get the core_modules version. But the runtime package.json is not added to the apk, so I can't get it. And adding the main package.json is a very bad idea; those keys are often wrong because I can do "^1.6.0" and it could easily have v1.80 installed.

I guess in summary; I come down to:

1. Attempt to do a feature check first, this is typically the safest check. And most features that you have added to v1.6 can be feature detected in one way or another. 😀
2. At worst case do a version check. Without the ability in the COMPILED app to do a version check you do eliminate a valuable tool that I can use to work around issues or detect support that feature detection can't.

[slavchev]

@NathanaelA

I had a short discussion with @rosen-vladimirov and we analyzed the current state and how it can be improved. Part of the current problem is that we allow app upgrade and the user ends with old plugins + new runtime. It is important to state that while we use npm we don't take advantage of its full features and we treat versioning in a slightly different way. We realize that fixing this is part of the problem. Also, the idea of semver has very strong support and we consider to revisit our decision and adopt it. However, this will probably happen for 2.0 release.

We are going to create a proposal at https://github.com/NativeScript/nativescript-cli/issues because it is not Android specific and we consider there it will have much better visibility. I will provide a link once it is available.

EDIT: see NativeScript/nativescript-cli#1530

[NathanaelA]

@slavchev & @rosen-vladimirov - SemVar is only part of the solution. That does not fix the reason I want a __runtimeVersion. 😀

Lets say I create AwesomePlugin (AP) in v1.50 of TNS and I have versions 1.0.0, 1.0.1, 1.0.2 all minor bugs/feature enhancements. I'm working on v2.0.0 as I have some really cool new feature that breaks how the plugin works. Really close to when I'm about to release 2.0.0 myself, you release v2.0.0 because you create a new breaking changes.
Well my v2.0.0 COULD support 1.5 fine, however to be compatible with v2.0.0 only a small change is required that is incompatible with v1.5. My choices are:

1. Abandon all my 1.5 clients
2. Choose not to upgrade it to 2.0.0
3. Create two separate packages with different patches
4. Use __runtimeVersion to detect that this is 2.0.0 and have a simple
   if (ver < 2.0.0) { methodA(); } else { methodB(); }

Now, which of those situations do you really think I want to be in as a plugin developer? All four are valid options, but only one of them is a really great option.

[slavchev]

If it is a only matter of a simple if statements I would probably publish two versions of my AwesomePlugin. When the logic is more complex I would go for my own dependency, build two versions of it and then consume it from (two different versions of) my AwesomePlugin. I don't see publishing multiple versions a big price to pay as I am already doing it. But it is my way of thinking.

[rosen-vladimirov]

Hi @NathanaelA ,
Intersting example. However it means you want one version in your plugin to be used with two versions of the runtime, which have breaking changes. So this sounds really cool, but I do not feel it is correct in npm world. For example when nodejs released 4.0.0 there were tons of breaking changes. All npm packages that were using old API should have been upgraded no matter of their current release cycle. Of course the update made some packages to stop working with older nodejs versions, but that's fine as you have old versions of the package working with it.
As I've been working on the support for different nodejs versions in nativescript-cli, I can tell you - you do not want to support different major versions in a single version of your product. Currently nativescript-cli can work with nodejs ~0.10.38, ~0.12.2, ^4.2.1, ^5.1.0 but this is really, really hard to achieve and support.
So let me get back to your example - I would vote for releasing 2.0.0 compatible version with all your new features and make it work with newest runtime version. In case someone wants to use them - upgrade the runtime as well. In case you have to write a lot of code, you can just release 2.0.0 which is compatible with 1.5 and later, release 3.0.0 which is compatible with runtime 2.0.0
You'll always have a corner case when some change (in runtimes, modules, cli, plugin, nodejs, v8 or whatever) will prevent some users from upgrading. But I would definitely use the new features in all of my new versions and advise the users to upgrade.

[NathanaelA]

@slavchev - Why would you really want to maintain two code bases? When I release 2.0.1 I have to apply the patch to both version and release two different npm versions. If I have a runtime version, I am maintaining a single code base that works on both v1.5 & v2.0.

So applying your logic; when is the TNS-Core-Modules going to be split into two or more separate versions because version checking is not a good solution?

https://github.com/NativeScript/NativeScript/blob/master/utils/utils.android.ts#L29
https://github.com/NativeScript/NativeScript/blob/master/ui/core/view.ios.ts#L231
https://github.com/NativeScript/NativeScript/blob/master/ui/page/page.ios.ts#L51
https://github.com/NativeScript/NativeScript/blob/master/ui/styling/background.android.ts#L143

Please note I only pulled a couple places the team is using it in the TNS code modules. Are you really advocating having multiple different versions of TNS-Core-modules per release version?