ANDROID: APK & OBB expansion management
Posted: Mon Feb 23, 2015 5:03 pm
hi.
am i the only one making big apps here, where "big" stands for "larger than 50 MB"?
i hope not.
as probably all of you know, android apps to be published on google store can't be larger than 50 MB. for bigger apps, google lets developers to load in the store as many expansion packs as needed (2 GB max size each), hosted by G for free.
http://developer.android.com/google/pla ... files.html
it would be very nice if LC took care of this limitation, giving us a help while compiling the android app.
this way, for example:
1.
while compiling, by segmenting the app in 1 main .apk file and as many .obb (or simple zip) files as needed (that's the way twixl publisher does, for example)
2.
coding side: by introducing a new specialFolder path to allow developers to recall the assets in code
<shared-storage>/Android/obb/<package-name>/
<shared-storage> is the path to the shared storage space, available from getExternalStorageDirectory()
3.
browsing side: by teaching the engine how to read from .obb files (as LC already does, after all, an apk beeing nothing but a zipped archive: see LC dictionary for "specialFolderPath": "An Android application is installed on the phone in the form of its zip package. This means that any assets that are included are not available as discrete files in the native filesystem. In order to manage this the engine essentially 'virtualizes' the asset files you include, allowing (read-only) manipulation with all the standard LiveCode file and folder handling syntax. To access the assets you have included within your application, use filenames relative to specialFolderPath ("engine")")
it would be a very big help for developers, in my opinion.
and easy to implement, or i'm totally wrong?
am i the only one making big apps here, where "big" stands for "larger than 50 MB"?
i hope not.
as probably all of you know, android apps to be published on google store can't be larger than 50 MB. for bigger apps, google lets developers to load in the store as many expansion packs as needed (2 GB max size each), hosted by G for free.
http://developer.android.com/google/pla ... files.html
it would be very nice if LC took care of this limitation, giving us a help while compiling the android app.
this way, for example:
1.
while compiling, by segmenting the app in 1 main .apk file and as many .obb (or simple zip) files as needed (that's the way twixl publisher does, for example)
2.
coding side: by introducing a new specialFolder path to allow developers to recall the assets in code
<shared-storage>/Android/obb/<package-name>/
<shared-storage> is the path to the shared storage space, available from getExternalStorageDirectory()
3.
browsing side: by teaching the engine how to read from .obb files (as LC already does, after all, an apk beeing nothing but a zipped archive: see LC dictionary for "specialFolderPath": "An Android application is installed on the phone in the form of its zip package. This means that any assets that are included are not available as discrete files in the native filesystem. In order to manage this the engine essentially 'virtualizes' the asset files you include, allowing (read-only) manipulation with all the standard LiveCode file and folder handling syntax. To access the assets you have included within your application, use filenames relative to specialFolderPath ("engine")")
it would be a very big help for developers, in my opinion.
and easy to implement, or i'm totally wrong?