LiveCode Forums

Hi

Any reason that the activity onConfigurationChanged method isn't sending orientation callbacks instead of using the accelerometer?

Cheers

Monte

Ah... I see the listener now.

OK, so now I'm confused why we are making the MCAndroidOrientationChanged call with an orientation then immediately forgetting it and working out orientation from device rotation in MCOrientationChangedEvent... Why not use the orientation we are given from the listener?

What? You want to do things the easy way? What kind of developer are you?

lol... well there must be a reason it's done this way. I just want to understand it

Hmm... it seems the orientation, once worked out for the device is then mapped according to the orientation maps from the file you include in the standalone. But I would expect the orientation that the listener gets to already be correct so I'm very confused why all this is necessary... It seems to me that this whole thing is done in order to block orientations changing that aren't in the allowed orientations and the allowed orientations are mapped to constant degrees of device orientation rather than to the actual orientation constants from the listener.

@monte: I remember seeing in the following pdf that some Android devices don't have their orientation set correctly, so this is a way to allow applications to override the orientation to the correct values on said devices.

https://github.com/runrev/livecode-ide/ ... f?raw=true

As far as I can work out it's LiveCode jumping through some odd hoops just to support allowed orientations rather than a problem with the devices.

Here's what seems to happen:
- set allowed orientations maps to enum values 0,1,2,3 "portrait, portrait upside down, landscape left, landscape right"
- orientation changes and sends an orientation constant 1,8,9,0 "portrait, portrait upside down, landscape left, landscape right"
- the orientation constant is ignored and a value 0->3 is worked out from the angle of the display and making use of the orientation maps in that file when they exist
- this constant is then used to block orientations that aren't allowed
- then it's sent back to the java side to set the orientation and mapped back to 1,8,9,0 to do so

I think the implementation just needs a redesign and the orientation map won't be needed but perhaps I'm not seeing something...

Well we don't try to make things overly complicated generally... However, in this instance, it was unavoidable. We did struggle a while with this (Ian, in particular).

The problem is that when you get the orientation changed notification from Android, you don't have a change to delay it... This means it is incompatible with what the engine needs with regards 'wait'. Instead, we had to essentially do it manually so the actual change in orientation could happen in sync with script updating itself (or refusing the change). That then led us to discover that on some Android devices (2.3 and before only as far we can tell) the actual orientations the 'hardware' understands are differently mapped from others - hence the device orientation map.

Making the orientation map file a little easier to use and starting to create a complete list of affected devices sounds like a good idea though

Of course, if you can find a 'wait' compatible way to use the Android notifications and still support the allowed orientations and such, then that's fair game!

Of course, if you can find a 'wait' compatible way to use the Android notifications and still support the allowed orientations and such, then that's fair game!

Is there a reason we can't use the orientation we get in MCAndroidOrientationChanged rather than recalculating it.... from what I can see if we retain that value we won't need to orientation map...

@monte: Potentially, but I don't think that would actually solve the problem - from script point of view, the reported orientation would not match that of some devices (which have skewed hardware to software orientation). The problem is consistency in terms of what the orientation ids actually mean across devices (it is only a subset of older Android devices that seem to have this issue), rather than anything else.

Note: The above is from my memory - I'll have a chat to Ian and see if he can explain the issue the orientation map solves more succinctly.

Hmm... Skewed hardware to software orientation is only an issue if your basing the orientation on the hardware rather than the software orientation isn't it?

Okay so I chatted with Ian about this. The problem occurs with Android 'tablets' that appeared before Android 'officially' supported 'tablets' rather than 'phones' (it seems some manufacturers 'hacked' 2.2 / 2.3.x to build tablets, rather than wait until 3.0 was ready). Some of these devices have a different idea as to what angle maps to 'portrait', 'landscape left', 'portrait upside-down' and 'landscape right'. Thus the problem is that you get a script (in LiveCode) that works perfectly on 'proper' Android tablets and iOS, but on these specific devices orientations get messed up. The orientation map essentially encodes corrective information so that the affected devices work the same as all the others.

[ Btw, the 'orientationChanged' notification on the android side actually passes an angle rather than a orientation constant and the reason it doesn't pass it through to the engine side is because by the time the engine processes it that value might be stale - thus it refetches it from the orientation listener when the event is actually processed on the script side. ]

This is an interesting case study for me to learn LiveCode's philosophy. I'm picking up a very strong philosophy of "support every device" almost regardless of the mess required to do so. Is that about right?

I thought that, excluding the original Kindle Fire, only about 1 million Android 2.x tablets ever sold (maybe excluding some low end Chinese dark matter) - most of them have since received updates or ended up in desk drawers because they were frankly rubbish. My own preference in that situation would be to create a special case for the Kindle Fire if necessary and forget about the rest!

I don't quite get the stale angle issue - surely if the angle is stale you'll get another orientation changed event a moment later?

@markw: Well, we do try to keep support for older devices and systems for as long as is feasible - usually until there is a significantly good reason to drop support and (from what we can tell) usage on that particular platform is almost non-existant - measuring the latter can be difficult though.

In this case the code is there and it works - if there's only a finite number of affected devices in existence then eventually the orientation map file will stabilise...

In regards to the 'stale' orientation issue, the orientation listener will fire with every change but by refetching the orientation when the engine event is processed it means the orientation changes once rather than several times in a row.