Android build creates multiple instances of activity stub and AndroidImplementation

[GoogleCodeExporter]

In my latest build, I noticed that multiple instances of my application 
activity stub and the same number of AndroidImplementation instances were 
created (in my case there were 9 instances of each in the heap dump). However, 
there was only one instance of my main application. These multiple instances 
caused the memory usage to be very high (about 50 mb). In addition, when 
exiting the app, it took 9 calls to Display.exitApplication to finally get the 
app to exit.

This leads me to believe that the issue that I brought up in my discussion post 
"Possible Memory Leaks in Android/Action Bar Errors" were not completely fixed. 
Apparently there is now only one single static instance of the main app class, 
but that did not fix the issue with many activity stubs and implementations 
being created - which still leads to a serious bug and memory leak.

I believe (and feel free to correct me) that in case of AndroidImplementation, 
there should only ever be one instance created. This is because it seems that 
AndroidPeer objects expect the same AndroidImplementation instance to be active 
when the app restarts as they access fields of their AndroidImplemenation outer 
class.  Currently, the way ImplementationFactory and Display work, a new 
AndroidImplementationis created every time the Display is initialized when the 
app starts. This will cause any AndroidPeer's already created to not function 
correctly (I think this was the problem in issue 312 that I submitted).

In the case of multiple activity stubs being created, this should not happen if 
the app is set to only have one activity by setting the launchMode to 
"singleTask" in the manifest.

Original issue reported on code.google.com by Ian.Te...@gmail.com on 3 Sep 2012 at 10:21

[GoogleCodeExporter]

I think Chen fixed that but we didn't update the server yet. I'll try to update 
the server tomorrow. Assigning to Chen to confirm that its already fixed. 

Original comment by shai.almog on 4 Sep 2012 at 4:50

[GoogleCodeExporter]

What's the status of this? It's been 4 days with no response.

Original comment by Ian.Te...@gmail.com on 8 Sep 2012 at 6:21

[GoogleCodeExporter]

fixed, thanks

Original comment by cf27...@gmail.com on 8 Sep 2012 at 8:10

• Changed state: Fixed

[GoogleCodeExporter]

I can confirm that multiple instances of the activity stub are no longer create 
no longer have the large memory usage problem have been fixed.

However, you have not addressed the possible problem where AndroidPeer's may be 
accessing fields of their AndroidImplementation outer class when that 
particular AndroidImplementaion instance may not be the active one as 
Display.init always creates a new implementation.

Is this a valid concern or am I overlooking something?

Original comment by Ian.Te...@gmail.com on 8 Sep 2012 at 8:41

[GoogleCodeExporter]

Display.init is called only once since the fix, so the issue you described 
shouldn't happen anymore.

Original comment by cf27...@gmail.com on 9 Sep 2012 at 9:17