Right, a static block runs only once. And is guaranteed to run in this
case, since Android is going to instantiate MyApplication.
You wrote in the original email that the native side needs to initialize
some statics and singletons. Those should only be initialized once, so a
static block works here.
As for terminating those singletons - presumably, they can be left
around until Android kills and cleans up the entire process.
-- Kostya
31.10.2010 11:32, Mark Murphy пишет:
Well, in Tim's case, that static block would only be fired once, presumably.
If Application instance B is created before Application instance A is
terminated, then we're still talking the same VM, and so the static
initializer would have been run when A was created and would not be
re-run when B is created.
I suppose the real problem might be that A is *never* being
terminated, despite the process being recycled, though I haven't seen
any signs of that occurring, either. This might occur if Android is
recycling the process but not the VM, for example.
I suspect that Tim can work around his problem via passing the
Application object to his NDK library and detecting a change in that
object (e.g., different hashCode()), reinitializing his statics when
that occurs.
On Sun, Oct 31, 2010 at 4:24 AM, Kostya Vasilyev<kmans...@gmail.com> wrote:
I don't have an answer to your actual question, however -
wouldn't it be more reliable to initialize native code from a static block?
class MyApplication extends Application {
private native void initializeNativeSide();
static {
initializeNativeSide();
}
}
-- Kostya
31.10.2010 10:34, Mark Murphy пишет:
In a comment on an epic StackOverflow question-and-answer, a gentleman
who I will call Tim has outlined a scenario he says he is running
into, one I have some difficulty believing.
Reading somewhat between the lines, the flow would appear to be this:
1. User taps on an activity icon in the launcher
2. Process starts up
3. Application object is put in that process -- and a custom
Application object loads an NDK library which initializes some
statics/singletons
4. User uses application
5. User abandons application (e.g., HOME)
6. Later, user returns to application, before the first process is
killed or recycled for use with another app
7. A second Application object is created, in the same process, before
the first Application object is called with onTerminate()
This screws things up for Tim's app -- apparently, it does not deal
with pre-initialized statics/singletons well. They were presumably
counting on onTerminate() to let them clean up the NDK space. As a
result, they are relying upon killProcess() (somehow...unclear under
what conditions they might call this) to force their own process to go
away, so their statics get cleaned up.
Step #7 is what confuses me. I can see a new Application object being
created, but only if the first Application object were terminated. I
don't see any NDK-related bugs out on b.android.com that seem to match
this complaint, though in principle it might cause problems for
non-NDK apps as well.
Has anyone encountered a new Application object being created in a
process before the old one is terminated?
Thanks!
--
Kostya Vasilyev -- WiFi Manager + pretty widget --
http://kmansoft.wordpress.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
--
Kostya Vasilyev -- WiFi Manager + pretty widget -- http://kmansoft.wordpress.com
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
