Odd behaviour with LocationRequest (Android, Oxygene, Extended Constructor)

Elements
, , ,
1

This one had me scratching my head for a while…

Working with Android LocationServices I was initialising a LocationRequest using an initialized property and an extended constructor:

Foo = class
private
  property Request := new LocationRequest( Interval := 5000 );
end;

This isn’t the complete initialization, but shows what I was doing. But my instance of Foo would have a nil Request !

Moving the code to a constructor or similar method, rather than an initialized property, I would then get a strange build error:

Uncaught translation error: com.android.dx.cf.code.SimException
    mismatched stack depths

There is no problem as such however, rather I think the LocationRequest class has some idiosyncrasies which are catching the compiler out in some way ?

Specifically it does not have a ctor, but rather a public static create() method. I have not had any trouble with other Java/Android classes and extended constructors until this one.

I’m not sure whether an extended constructor could/should work in a case such as this or whether the compiler should treat an attempt to use one here as an error ? Just thought I’d mention it.

2

It should work. I’ll investigate.

3

Thanks, logged as bugs://77266

4

Can you give me an example of this? I checked the code and it looked fine.

5

I’ll try to find some time to work up an MCVE.

1 Like
6

Ok, this is weird.

In a new Android App project for MCVE purposes, the problem doesn’t appear to occur, but it definitely occurs in my actual application. The build error if I use an extended constructor in an instance method:

Capture1.JPG917×253 35.1 KB

And the breakpoint hit only if an inline initialised member is not actually assigned a result:

Capture2.JPG799×229 27.8 KB

The member initialization is hit first, fRequest is still nil after stepping over, hence the second breakpoint is then also hit.

Possible complications that might be involved (?):

  • inferred type of member
  • nested class
  • nested class with (unqualified) name similar to super-class (I can’t see how that should be involved, but … ?)
7

maybe you can send your project as is? I’ll keep it secret of course and it will help me track this down.

8

Sure. I’ll first double-check that it still occurs in the latest beta, now that I’ve updated.

9

OK, yes it still happens and I’ve managed to create an MCVE. Rather than starting with an empty project and adding the code that breaks I instead started with my original project and stripped out everything except a minimum to allow the app to run and demonstrate the problem, without needing any of the supporting scaffold (Google Api’s, sign on etc etc) and confirmed that the problem remains.

I’ve attached that project for you here.

mcve.locationrequest.zip (881.0 KB)

The problem code is in the LocationService (check the comments around the fRequest member and initialisation of that.

The only other vestigial parts of the original project that remain are the gradle dependencies (altho these are not now actually used) and the external libs references (included in the “libs” subfolder of the project) including the signalr client aar which is duplicated in the project folder itself to enable the build. I left these in on the off-chance that might somehow be involved, though I don’t see how they might be.

Incidentally, the 9.1.100.2107 build seems to have a problem with debugging Android apps.

VS2015 (Community) is crashing and re-starting every time a debug session ends, whether cleanly or not, even if the debug session is expressly “stopped” from within VS itself. To start with I thought it was something I had done in introducing the SignalR support in my project but it’s still happening even with this bare-bones version of the app and (I just checked) also with a brand new, empty “New Android Project”.

10

bugs://77266 got closed with status fixed.

11

Found & Fixed, sorry about that.

12

Logged as bugs://i65008.

13

bugs://i65008 was closed as fixed.