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
>
--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy
Android 2.2 Programming Books: http://commonsware.com/books
--
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
