Android orientation

Moderators: heatherlaine, Klaus, FourthWorld, kevinmiller, LCMark

VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 32
Joined: Mon Mar 04, 2013 4:44 pm

Re: Android orientation

Post by markw » Wed May 08, 2013 8:24 pm

Thanks for the explanation. Android gets very messy on this and many other points...

Screen rotation is not entirely determined by device orientation. The Nexus 7 for example has a toggle on the notification bar so you can choose the rotation while the device is lying flat. There are apps and custom ROMs that add the same functionality to almost any device. These devices almost certainly outnumber the 2.x tablets. If someone were to update the screen rotation support so it followed native/built-in apps, would it be (hypothetically) OK to drop the legacy tablet support?

FWIW, the installed base of mobile devices that install new apps is almost entirely under 3 years old and a massive majority are under 2 years old. Android has a move fast and break things approach and Apple actively pushes developers away from supporting old hardware and software (e.g. removing support for older SDKs from XCode, occasionally requiring all new apps submitted to be built against the latest SDK, no checking for use of classes/methods that aren't available in the target OS version etc). My view is that if you don't adopt a slightly more aggressive policy on dropping support for old firmware than you have for desktop OSs then the code will become increasingly hard to maintain over time for very little commercial benefit.

Worth considering at least. ;)

Livecode Staff Member
Livecode Staff Member
Posts: 970
Joined: Thu Apr 11, 2013 11:27 am

Re: Android orientation

Post by LCMark » Tue May 21, 2013 11:32 am

@markw: Indeed, I think we could be a bit more aggressive on moving forward the 'required versions' aspect of the engine - particularly on mobile where things move so fast. We're going to re-engineer the platform abstraction layer later on in the year and that will be a suitable time to review things I think.

However, due to the architecture of the engine as it stands (and its X11 heritage) , we do sometimes have to do things in a somewhat roundabout way which is not ideal... Modern OS's don't like giving up control over their event-loops, and there's a certain antagonism between the engine and OS in this regard. That being said, if we want to experiment with an 'emscripten' type solution for the web (as we briefly discussed at the conference) then we are going to have to rework the way the engine operates when script is blocked but events need to be processed.

I must confess that is a little bit of a daunting task - all the native code which calls code (or calls code which calls code etc.) that might block needs to be refactored to take a callback for what happens after the blocking occurs (essentially continuation-passing-style) this would allow the native stack to unwind completely back to the OS... Something to consider after the refactor and platform rework!

Post Reply

Return to “Engine Contributors”