profile
viewpoint
Frédéric Camblor fcamblor 4sh Villenave d'Ornon, France http://fcamblor.wordpress.com

pull request commentbdxio/bdxio.github.io

Better handling talk height in grid for HoL

ping ?

fcamblor

comment created time in a month

Pull request review comment4sh/datamaintain

Feat dtmt 3

+package datamaintain++import org.junit.jupiter.api.Test+import strikt.api.expectThat+import strikt.assertions.first+import strikt.assertions.get+import strikt.assertions.isEqualTo+import strikt.assertions.last+import java.nio.file.Paths++internal class SorterTest {+    private val sorter: Sorter = Sorter(Config(Paths.get(""), ""))+

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.

Lysoun

comment created time in 2 months

Pull request review comment4sh/datamaintain

Feat dtmt 3

+package datamaintain++import org.junit.jupiter.api.Test+import strikt.api.expectThat+import strikt.assertions.first+import strikt.assertions.get+import strikt.assertions.isEqualTo+import strikt.assertions.last+import java.nio.file.Paths++internal class SorterTest {+    private val sorter: Sorter = Sorter(Config(Paths.get(""), ""))+

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.

Lysoun

comment created time in 2 months

Pull request review comment4sh/datamaintain

Feat dtmt 3

+package datamaintain++import org.junit.jupiter.api.Test+import strikt.api.expectThat+import strikt.assertions.first+import strikt.assertions.get+import strikt.assertions.isEqualTo+import strikt.assertions.last+import java.nio.file.Paths++internal class SorterTest {+    private val sorter: Sorter = Sorter(Config(Paths.get(""), ""))+

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 ?

Lysoun

comment created time in 2 months

issue commentdpa99c/cordova-diagnostic-plugin

[iOS] Location Authorization "Allow Once" on iOS 13 fails on 2nd run

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 :-)

ucsbricks

comment created time in 2 months

issue commentdpa99c/cordova-diagnostic-plugin

[iOS] Location Authorization "Allow Once" on iOS 13 fails on 2nd run

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 :/
ucsbricks

comment created time in 2 months

Pull request review comment4sh/datamaintain

Feat dtmt 3

+package datamaintain++import org.junit.jupiter.api.Test+import strikt.api.expectThat+import strikt.assertions.first+import strikt.assertions.get+import strikt.assertions.isEqualTo+import strikt.assertions.last+import java.nio.file.Paths++internal class SorterTest {+    private val sorter: Sorter = Sorter(Config(Paths.get(""), ""))+

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)

Lysoun

comment created time in 2 months

issue commentdpa99c/cordova-diagnostic-plugin

Weird getMotionAuthorizationStatus() behaviour on iPad

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")

Diagnostic_plugin_ok_on_ipad_mini_4

fcamblor

comment created time in 2 months

issue commentdpa99c/cordova-diagnostic-plugin

Weird getMotionAuthorizationStatus() behaviour on iPad

@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

fcamblor

comment created time in 2 months

issue commentdpa99c/cordova-diagnostic-plugin

Weird getMotionAuthorizationStatus() behaviour on iPad

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 :-)

fcamblor

comment created time in 2 months

issue commentdpa99c/cordova-diagnostic-plugin

Weird getMotionAuthorizationStatus() behaviour on iPad

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 Diagnostic_-_Motion_permission_requested_being_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

fcamblor

comment created time in 2 months

issue commentdpa99c/cordova-diagnostic-plugin

Weird getMotionAuthorizationStatus() behaviour on iPad

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 : Cordova_diagnostic_issue_on_iPad_Mini_4

fcamblor

comment created time in 2 months

issue commentdpa99c/cordova-diagnostic-plugin

Weird getMotionAuthorizationStatus() behaviour on iPad

@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 :

Version isMotionRequestOutcomeAvailable() getMotionAuthorizationStatus() requestMotionAuthorization() behaviour requestMotionAuthorization() outcome
v4.0.12 true always not_requested, even after permission popup being shown shows permission popup once always not_determined
v5.0.1 false always not_requested nothing always not_available

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

fcamblor

comment created time in 2 months

issue openeddpa99c/cordova-diagnostic-plugin

Weird getMotionAuthorizationStatus() behaviour on iPad

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,

created time in 2 months

push eventfcamblor/grunt-concurrent

fcamblor

commit sha ade067b5479b6aff552f21f7d1b5bdb807ef6ddc

allowing to put special 'hidden' color to remove logs for a specific task name

view details

push time in 2 months

push eventfcamblor/cordova-diagnostic-plugin

Frédéric Camblor

commit sha ebf24ce8c5b98ef372c9574f81ea51b495982cc8

Provides types for various statuses constants Allows to reference those constants in a typesafe manner

view details

push time in 2 months

push eventfcamblor/cordova-diagnostic-plugin

fcamblor

commit sha 3d10f6be78cff8c168131888317f5f63aa62543d

Provides types for various statuses constants Allows to reference those constants in a typesafe manner

view details

push time in 2 months

pull request commentdpa99c/cordova-diagnostic-plugin

Describe status constants possible values

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 :-)

fcamblor

comment created time in 2 months

push eventfcamblor/cordova-diagnostic-plugin

fcamblor

commit sha b9375e176e96ab1715db3053fe43e339f3f6b6a5

Provides types for various statuses constants Allows to reference those constants in a typesafe manner

view details

push time in 2 months

pull request commentdpa99c/cordova-diagnostic-plugin

Describe status constants possible values

should be ready for review now :-)

fcamblor

comment created time in 2 months

push eventfcamblor/cordova-diagnostic-plugin

Frédéric Camblor

commit sha 3f492024d56d672bb7d93cc35c53fa2a5133c413

Provides types for various statuses constants Allows to reference those constants in a typesafe manner

view details

push time in 2 months

create barnchfcamblor/cordova-diagnostic-plugin

branch : ts-4x-constants

created branch time in 2 months

pull request commentdpa99c/cordova-diagnostic-plugin

Describe status constants possible values

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

fcamblor

comment created time in 2 months

PR opened dpa99c/cordova-diagnostic-plugin

Describe status constants possible values

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 :-)

+82 -9

0 comment

1 changed file

pr created time in 2 months

push eventfcamblor/cordova-diagnostic-plugin

Frédéric Camblor

commit sha 96d2f049b23bb96ab44cabd3c2f3bef68b8391ca

Provides types for various statuses constants Allows to reference those constants in a typesafe manner

view details

push time in 2 months

push eventfcamblor/cordova-diagnostic-plugin

Frédéric Camblor

commit sha 4cd22404a252ef7205471151eb2e1a5e96186cd3

Describe motionStatus constants Allows to reference those constants in a typesafe manner

view details

push time in 2 months

push eventfcamblor/cordova-diagnostic-plugin

Frédéric Camblor

commit sha 9e18283613e914e73b1fa6fbbf4f7ca29e8aa92b

Describe motionStatus constants Allows to reference those constants in a typesafe manner

view details

push time in 2 months

push eventfcamblor/cordova-diagnostic-plugin

Frédéric Camblor

commit sha 699b45e16927c652b8b66a9413fb2c030bf0fb49

Describe motionStatus constants Allows to reference those constants in a typesafe manner

view details

push time in 2 months

issue commentchemerisuk/cordova-plugin-firebase-analytics

consider merging efforts with cordova-plugin-firebase

@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

v3ss0n

comment created time in 3 months

PR opened bdxio/bdxio.github.io

Better handling talk height in grid for HoL

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 :-) IHaveNoIdeaWhatIMDoing

+1 -1

0 comment

1 changed file

pr created time in 3 months

push eventfcamblor/bdxio.github.io

Frédéric Camblor

commit sha e86c655a44bea14f12da97b13a83fb918210f0d4

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

view details

push time in 3 months

more