The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

Anyone on this list know why the android implementation of both on the Java side with the static variables?

I've rewritten the SDLAndroid.java class w/o any static functions or static variables and from my testing there seems to be no adverse affects so far.


Also on the c implementation side there's this file SDL_androidtouch.c around line 56


function "SeparateEventsHintWatcher" calls into SDL_android.c and accesses the JNI from there. I've done some tests and it could instead call a function from SDL_android.c that just returns true or false.


I think that would make things a bit cleaner and easier to maintain.


I would like to submit a patch and get some people with non trivial android apps to test it out, possible getting rid of some crash bugs related to static variables.

"static variables" in Java do not exist as they do in C. A static field of a class means that the field exists in class context, e.g. once per class, as opposed to once per instance/object, when the keyword "static" is not present.

Similar to methods (functions), which are equal in all instances when they are declared static, and separated per instance if not static.

I assume that there are static fields and methods, so they can be accessed without having a reference to the "Activity" object (having access to "mSingleton" is sufficient then). Having more than one object of the "Activity" (sub)class is probably not intented/not required - when starting the app, Android takes care of the instanciation, and so another instance is never required. I actually wonder whether you get sth. useful out of instanciating "Activity" or a subclass of it on your own.

I doubt that things become easier when you try to redesign the SDLActivity without class fields and class methods, e.g. making all of them instance fields and methods.

What is the reason that you try to do so?

Regards,

Daniel



---------- Původní zpráva ----------
Od: Owen Alanzo Hogarth
Komu: SDL Development List
Datum: 24. 9. 2015 17:26:25
Předmět: [SDL] Android SDL implementation

The main goal was to be able to make SDLActivity extend a serive instead of an activity, that way I could turn make SDL on android act like a livewallpaper.

I wanted to make sure that doing that I didn't break anything or split the code so that there would be two versions to maintain. After trying a bunch of different things it seemed that just making the variables non static was the simplest solution because wallpapers can actually have 2 instances at the same time. One that's actually being rendered if it's a live wallpaper and one as a preview. If you only have class variables in that situation you get a lot of undefined behaviors.


It's really apparent there but I think that sorting out those issues for live wallpapers will also sort out those strange onresume type crashes I've seen discussed on this list. The crashes are due to some variables holding random values when the app comes back to the foreground.




On Fri, Sep 25, 2015 at 2:04 AM, hardcoredaniel wrote:

---------- Původní zpráva ----------
Od: Owen Alanzo Hogarth
Komu: SDL Development List
Datum: 24. 9. 2015 20:20:49
Předmět: Re: [SDL] Android SDL implementation




I can't talk about why you would need 2 instances, but changing SDLActivity from an Activity to a Service is indeed a major change that surely would break things for everybody else. The typical use case is still an Activity (to have a launchable app) and not a service (that would have to be started somehow, so people have to write their own Activity for that). And I wonder whether a Service can receive events (touch, mouse)?




I disagree. The variables keep their last value, while the app is is the background. They won't get random values assigned. Plus what is making these "non-static" going to change? They will still keep their value upon resume, whether they are class variables or instance variables doesn't matter.

I disagree. The variables keep their last value, while the app is is the background. They won't get random values assigned. Plus what is making these "non-static" going to change? They will still keep their value upon resume, whether they are class variables or instance variables doesn't matter. 

This actually might be true, nevertheless the patch that I submitted shouldn't break anything, if you do a test compilation and run it, SDL behaves just as it did with static variables.


I have been using SDL as a service for a few days now, once I finish sorting out this which just means writing a new SDLActivity.java


On Fri, Sep 25, 2015 at 1:07 PM, hardcoredaniel wrote:

I for once appreciate the freedom of implementing things other than activities with SDL, so imho this is a good thing, specially if the behavior is still the same.


Em sex, 25 de set de 2015 às 04:28, Owen Alanzo Hogarth escreveu:

Hi! (I'm Simon and I am new here)...


I am a few targets away from SDL on Android but I think the correct solution for managing life time of native libraries is to subclass Application, not Activity and certainly not Service.

http://developer.android.com/reference/android/app/Application.html





On Sat, Sep 26, 2015 at 2:37 AM, Leonardo Guilherme wrote: