Re: [AD] Android port notes

[Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>]

On Sun Mar 11, 2012, Michał Cichoń wrote:
> One suggestion I want to make is to not use Android version numbers
> but API levels. This will be less confusing for developers.

While I didn't really do that consciously, I did try and make the code not 
dependent on Android version numbers at all. What code that is there that 
actually depends on specific (api) versions, checks at runtime to see if the 
feature exists, and uses it, or falls back to something that /sort of/ works 
in older api versions. For instance, the touch handling. But note, that code 
needs to be re-done to yank out the checks from inside the onTouch handler, 
and move them into the startup code. Then the onTouch code will just check for 
simple booleans (or maybe we'll play some shenanigans with function pointers? 
probably not necessary though).

> On 11 March 2012 11:57, Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx> 
wrote:
> > Ok, for those interested in the port, some notes.
> > 
> > Some things should be kept in mind due to the nature of the android
> > platform.
> > 
> > The latest SDK should always be used if at all possible. The latest
> > platform version should be targeted (with minSDK targeting something
> > like 1.6 or 2.2?). OpenGL ES support should likewise be treated as
> > supporting the abolute latest in the default config of allegro. Meaning,
> > a generic setup of an allegro android project should be able to be
> > compiled to work on versions from 1.6 (2.2?) through 4.0. ****
> > 
> > I intend to build a table of the various supported android device
> > profiles, including cpu type, instruction set version, and instruction
> > set extensions, to help lay out a proper set of compile time switches.
> > 
> > **** that's given that the platform works the way I assume it does, I
> > don't know for sure exactly how the store treats different cpu variants
> > yet. if you can't make a large monolithic multi arch apk, then well it
> > may not make much sense at all to allow the use of say, GLES2, on a
> > compile that can work on 1.6 devices, and most of them likely won't
> > support GLES2. This needs some thought.
> > 
> > To trentg, that WANT_ANDROID_4 option is very mis-named. Someone more
> > familiar with Android development will immediately assume Android ICS
> > (aka 4.0) when reading that. And we /really/ shouldn't be making that
> > /just/ a compile time option. I have nothing against having compile time
> > options that cut out a lot of compatability code paths, but by default I
> > think the config should be to leave most of them in, so as few apk's
> > need to be built as possible for a given app (last I heard the android
> > store can be silly about multiple apk package versions).
> > 
> > Note: I'm quite tired, so I may have misunderstood some of the changes
> > you/trentg made, or completely mis-brained everything I wrote above. But
> > that's just some of the stuff I've been thinking about, and it should be
> > kept in mind.
> > 
> > --
> > Thomas Fjellstrom
> > tfjellstrom@xxxxxxxxxx
> > 
> > -------------------------------------------------------------------------
> > ----- Virtualization & Cloud Management Using Capacity Planning
> > Cloud computing makes use of virtualization - but cloud computing
> > also focuses on allowing computing to be delivered as a service.
> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > --
> > https://lists.sourceforge.net/lists/listinfo/alleg-developers


-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx