ping ?

Agree, I used a shortcut to talk about Script.filepath instead of the scriptIdentifier, but basically, if we consider we rely on the default behaviour (no ScriptIdentifierExtractor), then this should be the same.

That being said, I don't understand why you would take filename in consideration rather than the whole filepath ?

We don't want directory1/script5 to be executed after directory2/script3, and I assume this is something obvious.

I feel it implicitely means that you're going to 1/ group Scripts by directory, then 2/ use sort algorithm to sort Scripts belonging to the same directory ... but it doesn't tell how to sort directories altogether.

Using filepath solves this issue.

So for me there is no reason to make distinction between the extracted prefix or the filename. The algorithm will be the same to sort this string. I guess we are all ok with that.

The important question here is "what is the input type for the sorting algorithm" ?

• Should it be the filepath only ?
• Should it be what I call the $scriptIdentifier (which would be the result of a ScriptIdentifierExtractor, configurable, getting the script's filepath as input) only and which could be, sometimes (when default ScriptIdentifierExtractor is used), valued to the script's filepath
• Should it be a Script object having a lot of informations embedded into it (filepath, scriptIdentifier, metadata etc...)

Thinking about it, I would be more in favour of the 3rd option which allows a lot of flexibility in the sorting algorithm.

And by default, the sorting would be based on Script.filepath attribute.

Just to make sure that case does not matter, I would do as @driccio suggested: flattening case before sorting.

I'm in favour of case insensitivity too. To go one step further, I would even store script names as upper-cased (or lower-cased, it depends of taste). I guess that's what you were proposing @driccio ?

About case sensitivity, I think we can be simple : 'flattening case' with lowercase for instance and then sort.

About the number mixing, I think we don't understand ourselves. My point was to say "as soon as we have a regexp aimed at extracting a $scriptIdentifier", then we should base the sorting upon this $scriptIdentifier, not the raw script name (otherwise, this $scriptIdentifier will be useless). If we don't have any regexp aimed at extracting a $scriptIdentifier then the $scriptIdentifier is the filename (implicit : we sort alphabetically based on filename)

Makes sense ?

After reading https://medium.com/q42-engineering/apple-location-permission-ios13-1e0e59002889 it seems like some of my assumptions were not correct :

• It seems like "Allow once" should be considered exactly like the "When in use" outcome :

If the user taps option 1: “Allow once”, your app will be notified that the CLAuthorizationStatus changed to authorizedWhenInUse. Just like you’re used to in older iOS version when you get a permanent permission. It is now allowed for your app to start requesting locations, no code changes necessary.

• Background acquisition of geoposition will then be asked to the user on purpose, only when there is a background process that acquires those positions

Getting consent to scan for location in the background has gotten a bit harder but in exchange, your users will enjoy more transparency regarding the locations you’ve received in iOS 13. The first notable change is that even when you call requestAlwaysAuthorization, the user will only get the ‘just now’ and ‘when in use’ options in the permission dialog. If the user grants you ‘when in use’ permission and you try to scan for location in the background, only then the user will be presented a dialog to grant the background permission.

So ... not sure what to think about it, it looks like the current implementation of the plugin is right. But I find it misleading that when you select "When in use", you get a "GRANTED" outcome. I can understand it from a backward compatibility view, but it sounds really misleading to me.

@dpa99c I would be really interested in your thoughts on this :-)

I'm facing a similar issue with this new "Allow once" status.

I suspect that the outcome of requestLocationAuthorization() call is based on the "button index" of the clicked option rather than its true value.

Let me elaborate : when I execute this code snippet as the very first execution of my app (just after installation) :

cordova.plugins.diagnostic.requestLocationAuthorization(console.info, console.error, cordova.plugins.diagnostic.locationAuthorizationMode.ALWAYS);

I get following outcome :

• Popup is opened with only 3 options : When in use (selected by default) / Allow once / Never (the "Always" option is not shown anymore since iOS 13 !)
• When first option (When in use) is selected, the outcome of the call is an "authorized" (= cordova.plugins.diagnostic.permissionStatus.GRANTED constant) value
• When second option (Allow once) is selected, the outcome of the call is an "authorized_when_in_use" (= cordova.plugins.diagnostic.permissionStatus.GRANTED_WHEN_IN_USE constant) value
• When third option (Never) is selected, the outcomt of the call is a "denied_always" (= cordova.plugins.diagnostic.permissionStatus.DENIED_ALWAYS constant) value

Previously, on iOS < 13, first option was "Always" and second one was "When in use" ... that's why I suspect that the outcome is based on the index of the selected option rather than the true selected value.

When I open the System preferences and navigate to my app preferences, I can see that what I selected in the popup is the truth, and diagnostic plugin saved value is not the good one.

Note : I tested with cordova.plugins.diagnostic.locationAuthorizationMode.WHEN_IN_USE third mode parameter and it doesn't change anything to my ascertainment.

TLDR; I have 2 major concerns regarding requestLocationAuthorization with iOS 13 :

1. its outcome is not true currently if I either select "When in use" or "Allow once" options (the "Never" one is still 👌 )
2. I don't have the possibility to select "Always" option anymore from within my app. I'm not sure if you can do something for this in the plugin (allow to display the 4th "Always" option in the permission popup) but if you can't it would be a real pain to ask users to open their iOS preferences to switch to this mode as this is a very complicated manipulation :/

Case sensitivity is a topic on its whole regarding file names : I remember that on (old) version of Windows (not sure if it's still the case) file names matching were case insensitive (script1.js was considered the same as ScRiPt1.JS)

Not sure what to think about it (if we should enforce case sensitivity, or consider file name as case insensitive just because of windows)

About the number mixing, I don't think that we should allow both 1-script2.js and script2.js at the same time. I can recall that at some point, we talked about a regex pattern allowing to "extract" ordering number from file name => If we use such regex to consider that the number "is just before the file extension", then number for 1-script2.js will be 2 (the 1- prefix will be ignored, due to the regex)

OK, ran the tests and it looks good with a proper iPad Mini 4 : I now have the not_determined status after the requestMotionAuthorization() call (and cannot call requestMotionAuthorization() twice, which is something expected when I have an option to skip this call by checking getMotionAuthorizationStatus() == "not_requested")

@dpa99c Apologies, I was just checking and ... I'm testing with an iPad Mini 1 since this morning, not the iPad Mini 4 (they are very close in terms of design)

I'm going to unroll this thread and test everything again with the iPad Mini 4 this time, will keep you posted

Yes, that's what I am (and was) doing.

But I can recall that the change you made on 5.0.1 changed the behaviour. I do think that there is some Motion permission existing on this device ... prior to 5.0.1, when I was calling requestMotionAuthorization I think it was asking for the motion permission.

I'm not 💯 about that, let me check this again with a previous version of the plugin to be sure of myself :-)

And also at line 51 to check if the motion_permission_requested flag is nil when subsequently calling getMotionAuthorizationStatus().

Yes, motion_permission_requested is nil

Therefore, if you want to investigate this further, you'll need to debug on the device in Xcode yourself. I suggest setting breakpoints in Diagnostic_Motion.m at line 92, and line 96 when calling requestMotionAuthorization() to see if iOS enters that completion block with no permission popup.

As stated above, isMotionRequestOutcomeAvailable() is returning false And while in debug, I never stop at lines 92 & 96 because [self isMotionAvailable] statement returns nil

Hi @dpa99c,

You can see the outcome of those in my table previously.

Anyway, it was not on your sample app, so just in case I tried with your sample app but had exactly the same results as those described in the table above :

@dpa99c for my knowledge, can you confirm you just disabled availability of motion permission on the iPad mini 4 model device prior to v5.0.1 ?

As I can see changes in behaviour between 4.0.12 and 5.0.1 for the iPad Mini 4 :

(note that I'm not against this change, but I'm trying to understand the implications of this change here :-) )

I'm submitting a ... (check one with "x"):

• [x] bug report
• [ ] feature request
• [ ] documentation issue

Bug report

Current behavior: On iPad Mini 4, when I call getMotionAuthorizationStatus(), I always get a not_requested outcome, even when I call requestMotionAuthorization() prior to it (no matter what I respond to the motion authorization request popup).

eg :

cordova.plugins.diagnostic.getMotionAuthorizationStatus(motionStatus => {
    console.log("fist motion authorization status : "+JSON.stringify(motionStatus));
    cordova.plugins.diagnostic.requestMotionAuthorization(requestedMotionStatus => {
        console.log("first request motion authorization outcome : "+JSON.stringify(requestedMotionStatus));
        cordova.plugins.diagnostic.getMotionAuthorizationStatus(motionStatus2 => {
            console.log("second motion authorization status : "+JSON.stringify(motionStatus2));
            cordova.plugins.diagnostic.requestMotionAuthorization(requestedMotionStatus2 => {
                console.log("second request motion authorization outcome : "+JSON.stringify(requestedMotionStatus2));
			}, console.error);
		}, console.error);
	}, console.error);
}, console.error);

outputs :

[Log] fist motion authorization status : "not_requested" (t.js, line 13)
// Motion authorization request popup opened ... same logs below wether I allow or deny the motion authorization...
[Log] first request motion authorization outcome : "not_determined" (t.js, line 13)
[Log] second motion authorization status : "not_requested" (t.js, line 13)
[Log] second request motion authorization outcome : "not_determined" (t.js, line 13)

Expected behavior:

I understand that iPad motion is half available (we can request it, but since we don't have Pedometer events on iPads, it cannot be determined)

However, I would have expected that a second call (after requestMotionAuthorization() call) to getMotionAuthorizationStatus() would return not_determined instead of not_requested

WDYT about my assumption ?

Current behaviour is annoying because I need to always rely on requestMotionAuthorization() to have a "true" status, since getMotionAuthorizationStatus() doesn't give me the true status on iPad.

Steps to reproduce:

Execute following code :

cordova.plugins.diagnostic.getMotionAuthorizationStatus(motionStatus => {
    console.log("fist motion authorization status : "+JSON.stringify(motionStatus));
    cordova.plugins.diagnostic.requestMotionAuthorization(requestedMotionStatus => {
        console.log("first request motion authorization outcome : "+JSON.stringify(requestedMotionStatus));
        cordova.plugins.diagnostic.getMotionAuthorizationStatus(motionStatus2 => {
            console.log("second motion authorization status : "+JSON.stringify(motionStatus2));
            cordova.plugins.diagnostic.requestMotionAuthorization(requestedMotionStatus2 => {
                console.log("second request motion authorization outcome : "+JSON.stringify(requestedMotionStatus2));
			}, console.error);
		}, console.error);
	}, console.error);
}, console.error);

My assumption would be to have this output :

[Log] fist motion authorization status : "not_requested" (t.js, line 13)
// Motion authorization request popup opened ... same logs below wether I allow or deny the motion authorization...
[Log] first request motion authorization outcome : "not_determined" (t.js, line 13)
[Log] second motion authorization status : "not_determined" (t.js, line 13)
[Log] second request motion authorization outcome : "not_determined" (t.js, line 13)

Environment information

• Cordova CLI version 9.0.0 (cordova-lib@9.0.1)
• Cordova platform version

  android 8.1.0
  browser 6.0.0
  ios 5.0.1
Available platforms: 
  electron ^1.0.0
  osx ^5.0.0
  windows ^7.0.0

• Plugins & versions installed in project (including this plugin)

cordova-android-firebase-gradle-release 4.0.0 "cordova-android-firebase-gradle-release"
cordova-background-geolocation 3.2.2 "BackgroundGeolocation"
cordova-plugin-androidx 1.0.2 "cordova-plugin-androidx"
cordova-plugin-androidx-adapter 1.1.0 "cordova-plugin-androidx-adapter"
cordova-plugin-background-fetch 5.6.0 "CDVBackgroundFetch"
cordova-plugin-cocoalumberjack 0.0.4 "CocoaLumberjack"
cordova-plugin-device 2.0.3 "Device"
cordova-plugin-file 6.0.2 "File"
cordova-plugin-file-transfer 1.7.1 "File Transfer"
cordova-plugin-firebasex 6.1.0 "Google Firebase Plugin"
cordova-plugin-whitelist 1.3.4 "Whitelist"
cordova.plugins.diagnostic 4.0.12 "Diagnostic"

• Dev machine OS and version, e.g.

ProductVersion: 10.14.5
BuildVersion:   18F203

Runtime issue

• Device details : IPad Mini 4
• OS details
  • iOS 10.3.3

Related code:

cordova.plugins.diagnostic.getMotionAuthorizationStatus(motionStatus => {
    console.log("fist motion authorization status : "+JSON.stringify(motionStatus));
    cordova.plugins.diagnostic.requestMotionAuthorization(requestedMotionStatus => {
        console.log("first request motion authorization outcome : "+JSON.stringify(requestedMotionStatus));
        cordova.plugins.diagnostic.getMotionAuthorizationStatus(motionStatus2 => {
            console.log("second motion authorization status : "+JSON.stringify(motionStatus2));
            cordova.plugins.diagnostic.requestMotionAuthorization(requestedMotionStatus2 => {
                console.log("second request motion authorization outcome : "+JSON.stringify(requestedMotionStatus2));
			}, console.error);
		}, console.error);
	}, console.error);
}, console.error);

Kind regards,

Also, note that I prepared a branch, on my local repo, targetting version 4.x : https://github.com/fcamblor/cordova-diagnostic-plugin/tree/ts-4x-constants

I cannot propose any PR yet for 4.x as there is no real branch targetting this branch currently on your repository :) If you're interested by such PR, please create a dedicated 4.x branch and I'll submit it :-)

should be ready for review now :-)

⚠️ Please wait, I found some inconsistencies between android and ios constant values, will push the fix quickly

PR Type

• [ ] Bugfix
• [ ] Feature
• [ x ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Documentation changes
• [ ] Other... Please describe:

What is the purpose of this PR?

Today, for example, we are not able to use motionStatus constants in a typesafe manner (there is no check on the existence of this or that motion status since the type is any)

This PR aims at fixing this.

Does this PR introduce a breaking change?

• [ x ] Yes
• [ ] No

Conceptually, yes, this is a breaking change in terms of type descriptor (today's any has a wider type space than the one I'm proposing)

However, this is for good : people using window.cordova.plugins.diagnostic.motionStatus.NOT_DETERMINNED (typo in the name) in their code were not having any error, and now they will have some.

Note that it may help pinpoint migration issues introduced recently (like #230) in case people doesn't read the changelog :-)

@chemerisuk I guess this would be helpful to explicitely talk about differences between those 2 plugins in the README, as this is the first question that came to my head when I found cordova-plugin-firebase and cordova-plugin-firebase-analytics in the available cordova plugins

Increasing HoL height on schedule (includes handle of special case for lunch time when workshops is across 3 talks and not only 2)

Important note : test this, I didn't tested it myself :-)