Android SDL implementation

SDL Development
1

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.

2

“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

"

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._______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org"

3

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:

“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 <@Owen_Alanzo_Hogarth>
Komu: SDL Development List
Datum: 24. 9. 2015 17:26:25
P?edm?t: [SDL] Android SDL implementation

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.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

4

---------- 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

"

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.

"

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)?

?
"

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.

"

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.

“On Fri, Sep 25, 2015 at 2:04 AM, hardcoredaniel <@hardcoredaniel (mailto:@hardcoredaniel)> wrote:
”
“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 <gurenchan at gmail.com(mailto:gurenchan at gmail.com)>
Komu: SDL Development List <sdl at lists.libsdl.org
(mailto:sdl at lists.libsdl.org)>
Datum: 24. 9. 2015 17:26:25
P?edm?t: [SDL] Android SDL implementation

"

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.

SDL mailing list
SDL at lists.libsdl.org(mailto:SDL at lists.libsdl.org)
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
(http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)"

SDL mailing list
SDL at lists.libsdl.org(mailto:SDL at lists.libsdl.org)
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
(http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org)

"

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org"

5

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.javaOn Fri, Sep 25, 2015 at 1:07 PM, hardcoredaniel wrote:

---------- P?vodn? zpr?va ----------
Od: Owen Alanzo Hogarth <@Owen_Alanzo_Hogarth>
Komu: SDL Development List
Datum: 24. 9. 2015 20:20:49
P?edm?t: Re: [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.

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)?

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.

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.

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

“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 <@Owen_Alanzo_Hogarth>
Komu: SDL Development List
Datum: 24. 9. 2015 17:26:25
P?edm?t: [SDL] Android SDL implementation

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.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

6

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:

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:

---------- 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

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.

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)?

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.

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.

On Fri, Sep 25, 2015 at 2:04 AM, hardcoredaniel <hardcoredaniel at seznam.cz wrote:

“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

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.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

7

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.htmlOn Sat, Sep 26, 2015 at 2:37 AM, Leonardo Guilherme < leonardo.guilherme at gmail.com> 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 < gurenchan at gmail.com> escreveu:

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 <hardcoredaniel at seznam.cz 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

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.

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)?

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.

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.

On Fri, Sep 25, 2015 at 2:04 AM, hardcoredaniel < hardcoredaniel at seznam.cz> wrote:

“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

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.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org