Re: [AD] Android port notes

[Michał C. <mi...@gm...>]

I'm using prefixes like 'assets:' or 'res:' in the engine. Flag or
prefix, both will work.

The question is: should all possibilities be exposed?

Let see, for Android we have:
ALLEGRO_INTERNAL_DATA_PATH
ALLEGRO_EXTERNAL_DATA_PATH
ALLEGRO_EXTRA_EXTERNAL_DATA_PATH (optional)
ALLEGRO_ASSETS_PATH
ALLEGRO_RES_PATH
Those flags can be stored in Android specific header.

Some of flags listed in system.h may be mapped using
ALLEGRO_INTERNAL_DATA_PATH, but not all.
So, without doing additional assumptions, just map what can be mapped
and tell rest should be handled by
platform specific code. What do you think?

How path API should behave?

How ALLEGRO_EXENAME_PATH is relevant to Android?


On 25 March 2012 21:25, Thomas Fjellstrom <tfj...@st...> wrote:
> Ok, been thinking about how to handle the various storage options on Android.
>
> There's three separate locations for data that we need to cover, and only
> really two standard path enum values. The following is my current plan:
>
> ALLEGRO_RESOURCES_PATH = apk packed resources[1]
> ALLEGRO_USER_DATA_PATH  = internal phone per-app flash storage
> ALLEGRO_????_DATA_PATH   = external SD storage
>
> I'm not sure if we should add a new enum value, or have an android specific
> function to get the latter? It's a fairly android specific thing.
>
> What does everyone think?
>
>
> 1. My current plan involves using an android specific fshook driver that'll
> check for some special prefix to let you load packed resources, and fall back
> to stdio for regular paths. either a res:/ type uri prefix, or /res prefix or
> even the full path to the APK, followed by data/ or something. I prefer one of
> the first two, probably /res is my first pick. Either way,
> ALLEGRO_RESOURCES_PATH will be that prefix.



-- 
thedmd, Michał Cichoń
Artifex Mundi
mi...@gm...
http://www.artifexmundi.com