@NathanaelA ok.

What about the conflict with iOS vs Android touch Pointers?

As it stands:

function myTouchEvent(args: TouchGestureEventData): void {
  const pointer = args.getActivePointers()[0];
  const x = pointer.getX();
 
  // x is in DP on iOS, but DIP on Android
  console.log(x);
}

Should I leave iOS as DP for now. Or correct it to match Android. They should both be the same.

P.S. I think all properties and methods provided by the NativeScript API should default to DIP, unless otherwise noted.

Agree everything should return dip! I wrote a plugin for better gestures based on the great react native plugin. This was one of the reason. I think that PR should be a amazing addition

@vmutafov , Sorry about the formatting. My VSCode just does that every time I save a file. I must have installed a formatter at some point. Not sure how to deactivate it, we'll look into it.

I will rework the branch to remove breaking changes.

As for the method implementation do we prefer:

// A)  Same method names, but an optional boolean specifies the format.
getX(DIP?: boolean): number;

// B) Method names specify format, then property.
getDIPX(): number;

// C) Method names specify property, then format.
getXDIP(): number;

Personally I prefer either A or C. If there's already a convention where object properties would follow C, then it could make sense to do likewise with methods. Although, if the methods return the same type then A could be the go, as it follows the same convention, only in a method centric way, and with one less function declaration.

@NathanaelA @farfromrefug

Personally, I'm not a fan of methods starting with get having a boolean parameter. It seems like a code smell to me, so I would prefer B) or C)

@vmutafov i understand your point
But to me if we want not to break anything and still be consistent with the way it works everywhere else A seems the best to me

@NathanaelA Does it clutter the API do have both getXDIP() and getXPixels() etc..?

I feel like I've seen comments from the NativeScript team indicating they only want their API to offer properties/methods that have I high need from most users.

I think most will probably just need DIP. Unless you are diving down into native code DIP is what you'll need to update the UI; if that's why you need the coordinates.

Devs needing pixels (DP) are likely implementing native code, and probably know about layout.getDisplayDensity(), screen.mainScreen.scale, or how to get the values from the underlying native object.

This is why I think DIP should be the standardised default throughout the API. And why my initial PR was just an override of getX()/getY(), because if it's all standardised to DIP we don't need to specify format in property/method names.

@mudlabs I totally agree. I don't see the need for both.

Found more inconsistencies

On iOS the return values from getFocusX()/getFocusY() of Pinch events, and the values for deltaX/deltaY of Pan events are all in DP format.

On Android these are all in DIP format.

I think I'm going to just keep this PR to implementing the getX()/getY() methods for tap events. These will return DIP.

I'll undo any other changes so we don't have any breakages. And leave in all the inconsistencies for now.

Then I'll open a new issue outlining our desire to see a standardised use of DIP throughout the API. And then create a new PR with breaking changes for v7.

• If we can get that standardised then to get the DP off any value you'll only ever need to use layout.toDevicePixels(DIPValue).

@vmutafov any chance of getting that review closed?