I have not tried the patch but where could the derived class (in a not fragile way) add arguments to the Vector if the Vector is first created after the application already started? Maybe this could be documented somehow.

Also maybe the Vector (or an array) could be directly passed to nativeInit(). This way the two access methods in SDLActivity would not needed.

Created attachment 1605 [details]
patch for arguments on Android

I prepared a different patch. Here the arguments are passed from the derived class to the constructor of SDLActivity and then directly to nativeInit() where they are also processed.

derived class would be e.g.

public class MyGame extends SDLActivity {
    public MyGame() {
        super(new String[] {"-a", "-b", "-c"});
    }
}

Thanks for your comment.

My idea was to add elementes to the argument vector in the class derived from SDLActivity after calling super.onCreate(). This *should* be non-fragile.  Reason: 
 a) "The Surface will be created for you while the SurfaceView's window is visible;..."[1].
 b) onStart(): Called when the activity is becoming visible to the user. [2]
 c) onCreate gets always called before onStart()[2]

Please note: SDL 2 shielded me pretty well from the Android world so far, so my Android experience is limited.


About the Idea of setting the arguments via constructor: This limits the usefullness of this extension severly as I can no longer use the Bundle information which is passed to onCreate and carries all the interesting information.

1: https://developer.android.com/reference/android/view/SurfaceView.html
2: https://developer.android.com/reference/android/app/Activity.html#ActivityLifecycle

(In reply to rettichschnidi from comment #3)
> About the Idea of setting the arguments via constructor: This limits the
> usefullness of this extension severly as I can no longer use the Bundle
> information which is passed to onCreate and carries all the interesting
> information.

You are right. I assumed constant arguments which are set when starting the application for the first time. I also forgot about getIntent().

If the "final" modifier would be removed from my patch the arguments array could also be set from onCreate(). I still would consider this as "fragile" because the derived class assumes a certain implementation in the base class instead of using a clear interface.

Maybe SDLActivity could provide a method String[] getArguments() which could be overridden in the derived class. Then it would not matter where the derived class collects the arguments but if SDLActivity starts the SDL thread would call getArguments(). This way the implementation in SDLActivity could be changed without breaking too much applications.

On the other hand the Bundle passed to onCreate() must be filled with data in onSaveInstanceState() to be useful. I think this is not meant for data which is often passed as arguments to an application (like configuration switches) but more for preserving the current state of the application if "configChanges" happen. The SDL thread should not be restarted in most of this cases so setting new arguments would not be possible anyway. Maybe such data could just be saved in a file instead. This would also prevent sending (too much) data from C to Java and back for restarts.

I like your idea of having an overrideable  "String[] getArguments()" function.

About onSaveInstanceState(): I used this function to determine if the application gets closed because the system wants to save resources (isFinishing() returns false) or because the user requested it (isFinishing() returns true). This allows me on the next startup of the game to either quickly load the latest autosaved game in case the system has killed the app beforehand or doing a normal startup when the user has explicitly requested to quit the game.

As I have some time this weekend of which I intended to spend some to create an improved patch.

Are you interested our will you DIY?

Created attachment 1628 [details]
patch for arguments on Android from method

I prepared a new version of my patch. Now the arguments are provided from a method which can be overridden in a derived class. This is more flexible than using the constructor.

Created attachment 1750 [details]
patch for arguments on Android from method

I added an updated version of my last patch because the application name changed.

Hey Gabriel, does this look good to you?

(In reply to Sam Lantinga from comment #9)
> Hey Gabriel, does this look good to you?

https://bugzilla.libsdl.org/attachment.cgi?id=1750 this patch looks great to me, go ahead Philipp!

Patch was applied (with minor corrections):
https://hg.libsdl.org/SDL/rev/985481d7f3a1