Go-NoGo + architecture changes for support of apktool

[mougino]

Hello to all, I have been successfuly investigating a brand new direction that would allow to compile a BASIC! program into an APK either 1) from a computer much more easily than the current AppBuilder (no need of JDK+Android SDK etc.) and/or 2) directly from within BASIC! on the Android device. This direction is called apktool: https://code.google.com/p/android-apktool/ https://code.google.com/p/apktool/

There are however some cons, it's not all pros:

• the principle of apktool is to make changes to an existing APK without altering it (it still can be installed after the changes). This means that the keystore and signature would not be touched. In other words, BASIC! APKs produced with apktool will be signed by Paul's BASIC! key. I don't know the ramifications in terms of Google Play store but it is worth mentioning
• the Android version would need to download a 60MB zip onto the sdcard at first build, this could be done via WiFi only but it has significant end user impact to consider if it's a viable solution
• in order for both solutions (PC and cellphone) to work the current Basic.java would have to be modified, because it works better to only decompile the /res and not the /src then replace everything in /res to match user program then recompile we would have to export the following values into an xml:

    public static String AppPath = "rfo-basic";             // Set to the path name for application directories

    public static boolean isAPK = false;                    // If building APK, set true

    public static boolean apkCreateDataDir = true;          // If APK needs a /data/ directory, set true

    public static boolean apkCreateDataBaseDir = true;      // If APK needs a /database/ director, set true

What do you guys think? Does this sound promising enough to continue investigating or current solution is good enough?

[jMarcS]

This is a very interesting tool, Nicolas. I agree that it should make changing the program in a stand-alone APK very easy. You are right to be concerned about the signature, but I don't know what to do about it. This tool lets users do very low-level things, and we can't control what they do with it.

I ran a quick test to make sure I understand how to put the boolean values in an xml file. I just dropped them into res/strings.xml. It worked okay, but I think to make things easy for users -- and for ApkBuilder -- we should make a new xml file. I'm not sure what should go in it, but once it is created we can tune it. I have been avoiding adding source files, but this one makes sense.

In my test I kept the same variables. Basic.onCreate initializes them from the resource file.

[mougino]

Yes Marc, that is absolutely the spirit ;o) If we put the above values in, let's say, a new xml res/values/build.xml and we initialize the corresponding variables in Basic.onCreate then I could make the AppBuilder much much lighter and way easier for our end-users: it would transparently change this xml as well as strings.xml (for app name and version) and the AndroidManifest.xml and recompile that's it! We save the user the hassle to set any additional tool such as JDK, Android SDK, SDK platform... I even have other inovative ideas to simplify AppBuilder UI and building settings further. But let me check if I was thorough in the variables that need to be in this new xml first

[mougino]

After further investigation, it's not as simple as I thought; I (AppBuilder) would have to decompile the /src/*.java as well in order to change the package name (!not a small change!) or else the end-user won't even be able to install his APK on the same device where he has RFO-BASIC! (the package name com.rfo.basic would do a conflict). The problem is that apktool does not decompile to Java files but to Smali files. I would have to see how to change the package name in this format... (edit: seems not so complicated according to http://stackoverflow.com/questions/9218641/renaming-the-package-name-inside-an-apk)

Other values I didn't put above that we need to take out of the .java into the new .xml is Basic.java 's

protected void onPreExecute(){
    output.add("Standby for initial file loading.");  // The message that tells what we are doing.
    output.add("");
}

And Basic.java 's resources that need to be copied to SD at first startup:

public static final String loadFileNames [] = {         

        "boing.mp3", "cartman.png", "meow.wav",
        "fly.gif", "galaxy.png", "whee.mp3",
        "htmldemo1.html", "htmldemo2.html",
        ""
    };

And finally, in order to change the console colors AppBuilder modifies some values that are hard-coded in the following Java files: Run.java, Select.java, Delete.java, TextInput.java and TGet.java to be precise, the following occurences are changed:

textColor = 0xff000000;
backgroundColor = 0xffffffff;
lv.setBackgroundColor(0xffffffff);
theTextView.setTextColor(0xff000000);
theTextView.setBackgroundColor(0xff000000);

[olimaticer]

Hallo Nicolas,

your suggestion sounds on the first look good.

You pointed out that the main con are the unchanged RFO-Basic package name and key.

Looking in the source there is a recompress.sh script for running in the Busybox. This sounds like rooted devices. Am I right?

I prefer a https webserver which creates different packages like your fantastic tool.

1. Create a minimal package with different name and key on the web server. (RFO-Basic WebView Service)
2. Load it to the device. (RFO-Basic WebView Service)
3. Decompress it. (RFO-Basic)
4. Add the needed files. (RFO-Basic)
5. Compute the hash codes. (RFO-Basic)

public String sha1(String s) { MessageDigest digest = null; try { digest = MessageDigest.getInstance("SHA-1"); } catch (NoSuchAlgorithmException e) { // TODO Auto-generated catch block e.printStackTrace(); } digest.reset(); byte[] data = digest.digest(s.getBytes()); return String.format("%0" + (data.length*2) + "X", new BigInteger(1, data)); }

1. Bring the hash code links together. (RFO-Basic or web server)
2. Compress (zip) all files to an APK package. (RFO-Basic)

I think item 6 is the main challenge.

Cons:

• Web connection needed.

Pros:

• Different package names
• Different keys
• Newest updates
• Low memory consume
• Main work on the server
• Programmer's own BASIC-Code and resource files have not to send over the INTERNET.

[olimaticer]

1. Bring the hash code links together. (RFO-Basic or web server)
2. Compress (zip) all files to an APK package. (RFO-Basic)

I hate this numbering automatic!

/ Gregor

[olimaticer]

GRRRRRRRRRRRRR

sixth 6. Bring the hash code links together. (RFO-Basic or web server) seventh 7. Compress (zip) all files to an APK package. (RFO-Basic)

[mougino]

Hi Gregor, I thought of a webservice as well, but the amount of development/work is tremendous! An APK is not a "pure" zip: first the java classes need to be compiled to dex after some alteration (see which ones in my post above), so you need an Android SDK on server side, then the "zip" needs to be signed so you need a JDK (+keytool) on server side. On what platform would you offer this webservice ifever we manage to develop it? Such a server has a cost, needs CPU and bandwidth...

Nicolas

[olimaticer]

Hi Nicolas,

Initial file loading has to be handled with the BASIC-Code.

Step 1: WebFormular: ApplicationName, PackageName, PathNames, upload--> appIcon, E-Mail-Address --> Upload all resources. Download the records. Compiling one time per day with --> http://www.autoitscript.com/ on a windows computer

Step 2: Send back per E-Mail

OR

Step 1: WebFormular: ApplicationName, PackageName, PathNames, upload--> appIcon, UserName, PassWord Download the records. Compiling record per record with --> http://www.autoitscript.com/ on a windows computer with DNS-Service

Step 2: Asking if ready (loop)

Step 3 to 7 on Android

Gregor

[jMarcS]

Nicolas, I don't see anything in your list we can't do. I'd really like to organize the color settings somehow -- there are too many copies spread around in the code. If there is anything else you think would make AppBuilder easier to maintain, just ask.

About packages: right now all of files are in the same package (except for Base64.java). Is that necessary? Maybe we can move most of the files to another package so you don't have to change them.

Gregor, the webserver idea is interesting, but I'm not qualified to comment on it. I assume you do not want to delay the changes for AppBuilder?

[mougino]

Thanks Marc, the points listed above represent everything AppBuilder has to change in order to create a user APK. I agree the colors are a first thing to address because the way they are hard coded now is not clean.

I am not sure that creating 2 or more packages would improve anything, or in fact I'm not really sure to see where you're going with that ;-) Please tell me more.

Tell me when you make some progress and I can start implementing a test version of AppBuilder based on apktool and your modified BASIC! archive.

[jMarcS]

I was thinking we could leave all of the files in package com.rfo.basic, except for Basic.java. That would go in the user's package, com.my.app or whatever. Then you would have to change the package in Basic.java and AndroidManifest.xml, but not in any of the other files.

But now that I have said it, I see two problems. First, all of the other files that use something from Basic.java -- and there are a lot of them -- would have to know what package to load to get the things they need. Second, if you have to change even one Java source file, you would have to tell apktool to decompile them all.

We could make the first problem better, so you would have to change only a few files. But there is probably nothing we can do to change the second problem.

So there is no real benefit to playing with the packages.

[mougino]

Yes I agree Marc, this is an "all of nothing" process, but there won't be any problem on my side to change the package name in all Java (dex) files, AppBuilder is very good at replicating a same change in multiple files. Let me know your progress on the above and I'll test your changes.

I think I will propose 2 different tools in the near future: a simple one based on apktool called "RFO-BASIC! Quick App" (or "Quick APK", haven't decided yet) and a big package, proposed as a torrent, called "RFO-BASIC! App Builder Studio" (or more simply "App Studio"?) with what is the current AppBuilder, an Android SDK, the latest platform API, ant toolchain, etc. How do you guys think?

[jMarcS]

While getting the static import out of Run.java, I wasted some (precious!) hours trying to regularize our Context usage. I gave up; I just don't know enough about the subtleties of Android -- and apparently this is an area where Android is not consistent, either. I settled on using local Context (this) for getting program resources (res/*), and ApplicationContext (from Basic.BasicContext) for things that launch Intents or get physical resources (like MediaPlayer).

But I only changed what I had to, for the static import. There are many instances I did not touch, and I'm pretty sure some are not quite right. For example, the new code I put in for the context-lost crash bug (#114) uses this for Context, then immediately destroys that Context with a finish() call.

Note to future self: There are 19 instances of getResources() in the code, and almost all of them should be replaced with a method of Basic.java. That would localize and formalize the Context references, and eliminate a lot of duplicate code, too.

[jMarcS]

Nicolas, that commit breaks AppBuilder. There is only one place to set colors now, but it is still in code. The next step is to move things to build.xml. I will do that tonight or tomorrow. You have been very patient -- just a little longer now.

Did you want to try to do something with typeface? I think you posted about that once. How about other console features?

[jMarcS]

In that last commit, I forgot the loading message. It's in now. I also fixed a typo in the line color for the BW option.

In this commit, I'm adding an XML file, res/values/build.xml, as Nicolas recommended.

It has:

• string: app_path
• bool: is_apk
• bool: apk_create_data_dir
• bool: apk_create_database_dir
• integer: color_black
• integer: color_white
• integer: color_blue
• string-array: loading_msg
• string: progress_marker
• string-array: load_file_names

There are three colors because that's how many there are in preferences. For example, WBL uses color_white for text, color_blue for background, and half-alpha color_black for lines. You can change the integers to make any colors you want, but if you change the names you have to change them in Basic.java, too.

The loading_msg is a string array. Put in as many items as you want lines in your opening message. By default there are two lines: the first is "Standby for initial file loading." and the second is blank. Having only one line is legal. Having zero lines does not work - I could fix onProgressUpdate to be able to handle an empty array, but I did not take the time.

The progress_marker is the string that gets displayed as loading happens, by default a single dot "."

Documenting this in the manual Appendix is going to be a lot of work.

[jMarcS]

Nicolas, please look at the new build.xml file and tell me if the format is okay. Are the comments in your way? Do you want the order different? Change it any way you like, or tell me what you want.

[mougino]

Thanks for your hard work Marc! I have pulled your changes from github to my repo and have my hands in AppBuilder's code now.

About typeface (as well as font size, and screen orientation) yes I tried to modify them as well in settings.xml and arrays.xml with AppBuilder but didn't succeed, there are good chances too that some hard-coded values are somewhere in the Java code. See http://rfobasic.freeforums.org/change-how-the-console-screen-looks-like-in-standalone-app-t1570-10.html

Initial post here: http://rfobasic.freeforums.org/change-how-the-console-screen-looks-like-in-standalone-app-t1570.html

[mougino]

Great job in the build.xml Marc, very well documented :-) the comments and format are ok, no problem for me, my xml parser library is flexible enough to find (and replace) the value of any tag wherever it is in the xml, however it is written (upper lower mixed case, etc.) also kudos on the portion of code to copy the raw resources to sd-card from the list in the xml! will test it intensely...

[olimaticer]

In my last mail I suggested a ParseUri Command. Is it may be useful to add some predefined locations like STORAGE--> "../../", RFODATA, RFOSOURCE or RFOHTML so you get "" for RFODATA in the Interpreter and "[Data APK Resources Folder]" in the APK App? In my opinion it has to be an automatic change in the APK building process. Nicolas, looking forward we have to set some user defined permissions for later NFC commands in the manifest.

[mougino]

The locations are already made different in the Java code whether the call of the command is from interpreter or from a user APK, see this commit for example https://github.com/RFO-BASIC/Basic/commit/4c37d14aaefb3e711f157b0b566ab92c2a7e0ec0 ...or maybe I don't understand your request of predefined locations? The other problem is that users don't want to stick with predefined locations but want to place their resources wherever they feel. Only in the last days, there were 2 examples in the forum:

http://rfobasic.freeforums.org/error-getting-raw-resource-t1913.html where a user placed his resources in different subfolders of rfo-basic/data but then when building to APK of course everything is "set flat" in res/raw and there were problems

http://rfobasic.freeforums.org/post10077.html#p10077 where another user placed his resource even in a different folder than rfo-basic

So any attempt in our side to restrict the places the users choose in order to facilitate the conversion interpreter program -> user APK is doomed :-)

No problem for the NFC permissions, just point me to them and they will be added. Did you work on some new BASIC! NFC commands? I wanted to implement an NFC stack to RFO-BASIC! lately but missed the time.

[olimaticer]

Yes Nicolas, I remember the comments. In Android there are some predefined locations like market, pictures etc.. So parseUri("ROOT/storage/sdcard/rfo-basic/source/test.bas") or "ROOT/storage/sdcard0/rfo-basic/source/test.bas" can be happen (sdcard versus sdcard0). In my opinion parseUri("RFO-BASIC/source/test.bas") is a better solution. With parseUri("PICTURES/test.png") you get the default picture folder. If parseUri gets a second parameter (1,0) you can decide that the result is relativ to the root folder or the rfo-basic/data folder. The rfo-basic/data folder should be default.

See the my RoadMap suggestion, the most work is done. I'm still looking for an another guy with a NFC device to test the beam function.

Predefined locations are a main feature of Android for file, activity and NFC beam handling.

/ Gregor

[jMarcS]

Nicolas, I am looking at Appendix D of the manual. It describes changing the "app_name" string in res/values/strings.xml. That's the normal place to put an application title, but it works just as well in build.xml.

I don't want to clutter up build.xml with things that nobody will ever use, but I think it should hold almost everything an app developer would want to change. I will not move anything without your approval. Here are my suggestions.

"app_name" - app name for Launcher icon "version" - mentioned in Appendix D, used by VERSION$() function, changed in every BASIC! release "run_name" - the default Console title, overridden by CONSOLE.TITLE command "textinput_name" - the default TEXT.INPUT title, overridden by command parameter

If you say it is okay, I will move those to build.xml.

Does AppBuilder touch any other files?

[mougino]

Hi Marc, go ahead and move these to build.xml, I will make the changes. Other than that AppBuilder only touches to AndroidManifest.xml so it's all good.

[mougino]

Hello Marc, Stefano from the forum asks if it is possible to rename the new build.xml to myapp.xml (or any fancier name) in order to avoid confusion with ant's or eclipse's build.xml that are produced at the time of compiling? http://rfobasic.freeforums.org/post10237.html

[jMarcS]

Thanks, Nicolas. I replied in the forum this morning. I don't think "myapp" works because it is the same file that sets up standard BASIC!, if you just leave all the values unchanged. I took your "appdesc" and changed it to "appdef" as a suggestion, but I like something simple like "setup.xml" best.

While we are changing things: I think I chose poorly when I called the colors by real color names. Would it be okay to call them something generic, like "color1", "color2", "color3"? By default, they would be black, white, and blue, respectively. "BW" would select "color1" for text and lines, and "color2" for background. "WBL" would select "color2" for text, "color3" for background, and "color1" for lines.

[mougino]

OK. Your color suggestions and "setup.xml" work for me

[jMarcS]

Ok. I'll do that right away.

Have you considered how Appendix D should be rewritten? I don't want to step on anything you have already started, but I had some time yesterday, so I took some screen shots and wrote a few paragraphs to see what it might look like. It can't be finished until we finalize all the names and what should be in the new xml file.

The other issue we must settle for Appendix D is "my_program" vs. "f99_my_program" is res/raw. I do not know the full history. My impression is that originally Paul had "f99_my_program", then Michael (paulon0n) added "my_program" as a demo for the preprocessor. At some point we changed the preprocessor, but not the demo. Then later, Paul stripped out all the stuff that didn't work in "my_program".

The problem is that somehow Basic.java got into GitHub with code loading "my_program" and not "f99_my_program", but Appendix D still says "my_program".

We should only have one. 1) We can remove res/raw/my_program and change the code to load f99_my_program, as it was before. 2) We can remove res/raw/f99_my_program, but copy the Hello Kitty demo into res/raw/my_program.

I think I like the first option better. "f99_my_program.bas" gets loaded into the SamplePrograms folder just like all the other sample programs, so you can see how it works in standard BASIC! before building it into an APK. But I can see good arguments for either choice!!

Writing code is so much easier than naming the things we are writing about!

[jMarcS]

Nicolas, how does AppBuilder tell BASIC! what program to load?

Shouldn't we be able to put the program name in setup.xml?

[mougino]

As far as I know, since I debuted in BASIC! and got involved in the forum (i.e. back in January 2012) there has always been "my_program" and never "f99_my_program". In the same way, AppBuilder doesn't "tell" BASIC! to load any program, this is all stated in Basic.java: the program that is loaded in all cases, editor or user APK, is "res/raw/my_program". We should get rid of any reference to "f99_my_program". And about your last proposition, no need to complexify the user APK build, let's keep it as it is, i.e. always put the user program inside "res/raw/my_program" and no other name.

[jMarcS]

Hmm. Sorry, I guessed wrong. I should have waited for your reply.

I think that in November 2012 Paul tried to change it and got tangled up with Michael's preprocessor demo. Appendix D has been wrong ever since.

Here is the flow in Appendix D:

• Run source/Sample_Programs/f99_my_program.bas in standard BASIC!.
• Fix up Eclipse to build an APK.
• Run the APK - the result should look just the standard BASIC! run.
• Put your own program in res/raw/f99_my_program to build it into an APK.

That's a good flow for a tutorial, but it does not work, because Basic.java loads "my_program", not "f99_my_program". The "Run the APK" step runs a program, but not the Hello Kitty. Putting your own program in "f99_my_program" doesn't do anything at all.

We can fix that by taking out f99_my_program and using only res/raw/my_program, as you (and Frank Cox) suggest. To make the first step work, we have to put my_program into res/raw/the_list.txt. That feels weird to me because everything else in thelist starts with `f`, but that doesn't really matter -- just me being compulsive! (Emerson wrote, "A foolish consistency is the hobgoblin of little minds". But he was talking about "little statesmen and philosophers". I think that for programmers, consistency is almost never foolish.)

I will hold off for a while before making that change. I want to try to be sure that I have all the details right this time.

[stefano-px]

Hi Marc, I suggest a more easy solution. Just copy the content of f99_my_program to my_program, and delete reference to f99 (change with my_program) in the guide. No need to list my_program in the_list, because it's some kind of special 'hidden' file designed for people who want to make their own APK.

• Copy f99_my_program to my_program
• Delete reference to f99_my_program in the guide

Easy and clean.

Thanks for attention.

Stefano

[stefano-px]

I explain better. I recently made a lot of testing APK with BASIC 1.76. Some test APK were made exactly this way: copied content of f99_my_program to my_program. Than I compiled the APK and I had Kitty meowing. No need at all to put my_program in the_list_txt for making a working APK. Teorically is a little change that is not a real change. The important thing is editing the guide to be coherent. If you don't like f99_my_program, rename it f99_kitty and search for reference to it in the code, but as I can see with my poor knowlegde the only string matching f99 in all Basic.zip is in the_list.txt.

[jMarcS]

Hi, Stefano. Thank you for explaining how you made it work.

After a new install, BASIC! does its initial file load. It takes all of the programs listed in the_list.txt and copies them from resources (res/raw) to the sample programs folder of the Android file system (source/Sample_Programs). Right now f99_my_program is listed, so it gets copied. That's what it means when Appendix D says "Run source/Sample_Programs/f99_my_program.bas in standard BASIC!".

When I remove all references to "f99_my_program", I must put "my_program" into the_list.txt so the initial file loader will copy res/raw/my_program to source/Sample_Programs/my_program.bas. It is for standard BASIC!, not for the standalone APK.

I like calling it "f99_my_program", because everything else in the_list.txt starts with f and a number. That's okay; I will use "my_program" and remove the "f99". As you said, the important thing is to make De Re BASIC! coherent.

Happy New Year!

[jMarcS]

I am sorry to make you wait. I was considering some other changes. For instance, wouldn't it be nice if all of the standard BASIC! sample programs were in their own resource directory? And what if we did not need the_list.txt any more? I think when making an APK, the programmer should not have to delete any standard BASIC! resources -- they should disappear automagically.

But don't worry, I did not do any of those things!

[mougino]

This is already the case, no? The sample programs are in the resource directory res/raw, or are you talking about assets maybe? What do you call their "own resource directory"?

Anyway don't apologize for making new changes ;) in the end it will simplify BASIC! users life and myself when maintaining the AppBuilders. I was looking at the recent changes, may I suggest to slightly modify the string-array "load_file_names" so that it does not end with an empty string? Can it be handled in the Java code, or not? (in case of zero resource to copy maybe this is hard to implement?)

[jMarcS]

I like your suggestion for "load_file_names". You are exactly right -- if there is a problem it will be in the zero resource case. I'll take a look later today.

I will make a separate comment about resource directories.

[jMarcS]

By their "own resource directory", I mean a directory that an APK builder can simply delete -- no picking and choosing. Today, the sample programs and APK resources are mixed together. We could put my_program and meow.wav in res/raw, but put all of the f<number>sample programs in another directory, say res/samples.

We use lists for two purposes. "the_list.txt" lists all of the files in res/raw that must be copied to the source/Sample_Programs directory with ".bas" extensions. The LoadFileNames[] array indicates non-program files to copy to one of the data directories, and also supplies the extensions for the files when they are created.

We can eliminate both of those lists for standard BASIC! by putting all of the sample program resources in an assets subdirectory, maybe "assets/samples". You can get a list of "assets" files from the AssetsManager. (It is possible to get list of "res", too, but it is much more work). Then at start-up, BASIC! just loads everything in that subdirectory, distributing them to source or data subdirectories by file extension.

Perhaps we could eliminate LoadFileNames for APK builders, too, by putting all of their resources in a different subdirectory of assets. By default, it would contain "my_program.bas" and "meow.wav". Standard BASIC! would copy them to source/Sample_Programs and data, just as it does now.

You were the first one to mention the assets directory, Nicolas. I did not understand then how useful it is. For BASIC!, I think "assets" directories could work far better than "res" directories. Changing over completely is a fairly big task, but this would be a good time to do it, rather than rewriting AppBuilder and Appendix D twice.

Would it affect how you use apktool?

[stefano-px]

Hello Marc. Please, could you explain "Perhaps we could eliminate LoadFileNames for APK builders". You mean you want to delete string array "load_file_names"? And if so, then how we can tell the App which files have to be loaded on "data" directory and which ones not? De Re BASIC! says that there's a difference between loading or not loading files. If we load every file, the startup time would increase very much. Sorry, I'm confused, maybe I don't understand "Perhaps we could eliminate LoadFileNames for APK builders". Thanks.

[mougino]

I think this is a really great idea Marc, res/raw has never been so good a choice for user resources, the purpose of res/raw is to provide access to static final resources that will never move, quite the opposite of the flexibility we are looking when creating a user APK... assets on the contrary is a real file system, it allows to replicate the "/rfo-basic/source" and "data" architecture, including (if the user wants to) subfolders, or even while we're at it, folders outside of "/rfo-basic" (both cases mentioned above: https://github.com/RFO-BASIC/Basic/issues/118#issuecomment-31088845).

This replication could be done from APK to disk in case of Editor ; and from disk to APK in case of AppBuilder. In the 1st case I would suggest to create an "assets/rfo-basic/source/samples" and an "assets/rfo-basic/data" containing what needs to be synced in InitDirs(), this way, there will be only 1 folder to be (recursively) deleted by AppBuilder: "assets/rfo-basic". This allows us to get rid of "the_list.txt" as you suggest, and of LoadFileNames in case of standard basic (editor).

Now about eliminating LoadFileNames for a user APK... I took the time to think of the ramifications. I remember having the need of copying resources to SD when developing my RPG, in case of recource versioning... But that works also well by versioning the APK with changed resources in assets! So I don't see any inconvenient to get rid of LoadFileNames altogether. That also simplifies it for AppBuilder and Appendix D: no more "copy resource to SD at startup" option for the end-user.

Finally, I didn't try it so far but looking in the doc it seems apktools is as good as decompiling and changing assets as it is with res/raw. So let's go! :)

This is a huge change, if you need help replicating changes after you've done 1 or 2, I can do that for you. I have a lot of time in the coming days (weeks) as I am between jobs for at least January.

[mougino]

@stefano-px @jMarcS do you guys see a reason we should still offer the end-user the possibility to copy resources to SD-Card at startup? I can see where it is needed in case of RFO-BASIC! editor (the samples and 2-3 files that go with it) but I don't see how it is useful for a user defined APK... I vote for simplicity and keep the APK resources inside assets at all time, how do you think?

[stefano-px]

Nicolas: this my doubt and this is the reason why I asked about removing load_file_names. Why Paul explicitly talks about loading some files if needed? Why does he offer this possibility to final user? Maybe he can clarify with a little example. I suppose (but I'm not sure) that files in res/raw, once the APK is installed can't be removed or edited by normal user. So if you're going to edit a already-edited-file that you want to distribute with your APK, it must be loaded at startup. But Paul could explain.

[mougino]

You are right Marc, files in res/raw, or in assets as well, are not accessible for read or modify by the person who installs the APK. So I guess if we want to keep this functionality [edit] we still need load_file_names and adapt it to go get the files in assets instead of res/raw

[mougino]

Discussion for this issue starts to be heavy. I created a specific issue for moving resources handling from res/raw to assets: https://github.com/RFO-BASIC/Basic/issues/123

[jMarcS]

1. That was Stefano, not me! But I agree we need a way to let an apk copy a file to the file system so the program can both read and write it. I don't want to use an array like LoadFileNames, but the only alternative I can think of is to put them is separate subfolders of assets -- and that should be discussed on the new issue, not here.
2. I did not have to change anything to make an empty load_file_names string array work. It already worked. I think it probably works in 01.76, too, although I did not test it. I took out the setup.xml comment that said a blank line was required.

3. In a marathon programming/debugging session I started to lay groundwork for moving from res to assets. I consolidated some of the references to resources in a common location (in Basic.java). But in the process, I found some other things:

   Bad (not fixed): a. I think that some TEXT and BYTE positioning operations do not work on resources. Has anyone ever tried? Bad (but fixed): b. A dumb mistake that probably kept you from making an APK with the code I pushed Tuesday - I apologize. Good (new enhancements): c. The slow part of loading programs and data files was the data files. Now that is the fast part. d. Now an APK can load other BASIC! program files from resources with INCLUDE.

Nicolas, I am sorry to hear you suddenly have too much free time on your hands. I wish you well. It may not mean much, but I would be happy to write you a recommendation. Certes, it would have to be in English.

[stefano-px]

Quote "d. Now an APK can load other BASIC! program files from resources with INCLUDE."

This means the old way, paste all *.bas files into res/raw/my_program, is deprecated or no more working?

[mougino]

This is a big change indeed! Does it mean that an APK can arbitrary create then load a .bas file from its own directory on SD-Card? Does the RUN command work as well in APK now?

[stefano-px]

Sorry, I misunderstood point d.

[jMarcS]

Stefano, The old way still works, but it is no longer necessary. You can put other .bas files in res/raw and INCLUDE will find them. It has the usual problem: the extension is ignored, so you can't have both 'xyz.bas' and 'xyz.wav'. I think you did not misunderstand -- I think Nicolas is way ahead of both of us!

Nicolas, the INCLUDE processing is done while loading the program. The file to INCLUDE must exist before the program runs. RUN is different. It is processed at run-time, very much like starting a shortcut. But I think what you say is a very good idea. Let me take a look.

[stefano-px]

Ok, Marc. Thanks for explanation. Now I know I didn't misunderstand. But now another question comes to my mind. When we build the APK, we usually indicate a main .bas file, because it's the first to be copied in my_program. So, now, we just have to copy the main .bas file to my_program and the rest of the work will be done by BASIC! searching for other *.bas file in res/raw? Right?

In short:

• copy the main *.bas file to my_program
• copy all other *.bas to res/raw

I still find much comfortable the old way, but I'll try the new option too. I can't imagine how much work you're doing...

[mougino]

Hi Marc, actually I was concerned about security, so I'm not that sure that allowing RUN in a user APK is a good thing :-) Anyway, please do not spend too much time on this, it was a simple question from me, and I think your todo list is quite full without it!