When changing orientation on loading screen the activity is restarted

[Kieran Fleming]

If the user changes the screen orientation on the G1 phone, the progress is lost and the user has to start the loading operation again.

[Guillaume Rosaire (zerog)]

This issue makes that the loading screen currently started in the onCreate method of the SatNatActivity is displayed another time (or each time that the screen orientation is changed). Must be fixed before I can commit my changeset for issue #26

[Guillaume Rosaire (zerog)]

ZeroG wrote:
> This issue makes that the loading screen currently started in the onCreate method of the SatNatActivity is displayed another time (or each time that the screen orientation is changed). Must be fixed before I can commit my changeset for issue #26

Not the loading screen but the Welcome Screen - Forget my previous comment, that's the correct behavior for Activities to be recreated when orientation change (I didn't think so).

To help fix this bug, you may have a look at http://stackoverflow.com/questions/456211/activity-restart-on-rotation-android

[chris_debian (cjhandrew)]

Kizza,

Looks like you are looking at this one, so I've assigned to you. If not happy with this, let me know and I'll change.

Cheers,

Chris.

[Murphy (murphy2712+launchpad)]

Is this bug the same as bug #53? (orientation issues)
I think it's resolved in patch provided by evolvedlight in feature #30.

[evolvedlight (steve-evolvedlight)]

I agree - I think my issue #53 is a sort of duplicate of this, and so I'm closing this issue.

[chris_debian (cjhandrew)]

evolvedlight wrote:
> I agree - I think my issue #53 is a sort of duplicate of this, and so I'm closing this issue.

Thanks, Steve.

Chris.

[Kieran Fleming (kieran-fleming)]

Nope, this bug is still a problem. I don't think my bug report was detailed enough, so I apologise for that. The bug is that when the "Please wait" screen is showing, if the user changes the orientation the loading is either cancelled or we get a Force Close. The FC is actually new, when I reported this bug we weren't getting that.

This bug is pretty common on the G1 - after typing in where they want to go and pressing 'Search', the user usually wants to put the keyboard away.

Now that the bug's closed I haven't got an option to reopen it. Can the big and powerful admin please do so? Thanks :)

[chris_debian (cjhandrew)]

Kieran,

Re-opened as requested. Hope this helps.

Chris.

[evolvedlight (steve-evolvedlight)]

Thats because you haven't yet handled it in getLocations() (SelectPOIActivity.java line 143): when the orientation changes you need to handle it by overriding methods (something like onSaveInstanceState), and make sure you remember what the user was doing at that point, and then in getLocations you need to make sure that the dialog actually exists before you try to close it.

Thats what I don't like about the android plaform: things can actually change between 2 lines of code...

[Murphy (murphy2712+launchpad)]

There is definitively something wrong with orientation changes because when I change orientation several times (8-9 times), application Force Close!
There must be a memory leak.
logcat:
"E/dalvikvm-heap( 1688): 65536-byte external allocation too large for this process.
E/ ( 1688): VM won't let us allocate 65536 bytes
D/skia ( 1688): --- decoder->decode returned false
W/dalvikvm( 1688): threadid=55: thread exiting with uncaught exception (group=0x4001a210)
E/dalvikvm-heap( 1688): 65536-byte external allocation too large for this process.
E/ ( 1688): VM won't let us allocate 65536 bytes
D/skia ( 1688): --- decoder->decode returned false
E/dalvikvm-heap( 1688): 65536-byte external allocation too large for this process.
W/dalvikvm( 1688): threadid=53: thread exiting with uncaught exception (group=0x4001a210)
E/ ( 1688): VM won't let us allocate 65536 bytes
D/skia ( 1688): --- decoder->decode returned false
W/dalvikvm( 1688): threadid=57: thread exiting with uncaught exception (group=0x4001a210)
I/OPENSTREETMAP( 1688): Rendering overall: 96ms
I/global ( 1688): Default buffer size used in BufferedWriter constructor. It would be better to be explicit if an 8k-char buffer is required.
I/global ( 1688): Default buffer size used in BufferedWriter constructor. It would be better to be explicit if an 8k-char buffer is required.
I/global ( 1688): Default buffer size used in BufferedWriter constructor. It would be better to be explicit if an 8k-char buffer is required.
I/global ( 1688): Default buffer size used in BufferedWriter constructor. It would be better to be explicit if an 8k-char buffer is required.
I/global ( 1688): Default buffer size used in BufferedWriter constructor. It would be better to be explicit if an 8k-char buffer is required.
..."

[evolvedlight (steve-evolvedlight)]

I've tested this further - your stack trace there is unfortunately incomplete. Here is a fuller one,

10-02 17:11:47.880 E/AndroidRuntime( 8003): Uncaught handler: thread main exiting due to uncaught exception
10-02 17:11:47.920 E/AndroidRuntime( 8003): java.lang.RuntimeException: Unable to start activity ComponentInfo{org.opensatnav/org.opensatnav.SatNavActivity}: android.view.InflateException: Binary XML file line #26: Error inflating class java.lang.reflect.Constructor
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2268)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2284)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.app.ActivityThread.handleRelaunchActivity(ActivityThread.java:3278)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.app.ActivityThread.access$1900(ActivityThread.java:112)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1696)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.os.Handler.dispatchMessage(Handler.java:99)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.os.Looper.loop(Looper.java:123)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.app.ActivityThread.main(ActivityThread.java:3948)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at java.lang.reflect.Method.invokeNative(Native Method)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at java.lang.reflect.Method.invoke(Method.java:521)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:782)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:540)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at dalvik.system.NativeStart.main(Native Method)
10-02 17:11:47.920 E/AndroidRuntime( 8003): Caused by: android.view.InflateException: Binary XML file line #26: Error inflating class java.lang.reflect.Constructor
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.view.LayoutInflater.createView(LayoutInflater.java:512)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at com.android.internal.policy.impl.PhoneLayoutInflater.onCreateView(PhoneLayoutInflater.java:56)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.view.LayoutInflater.createViewFromTag(LayoutInflater.java:562)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.view.LayoutInflater.rInflate(LayoutInflater.java:617)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.view.LayoutInflater.inflate(LayoutInflater.java:382)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.view.LayoutInflater.inflate(LayoutInflater.java:320)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.widget.ZoomControls.<init>(ZoomControls.java:49)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.widget.ZoomControls.<init>(ZoomControls.java:40)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at org.opensatnav.SatNavActivity.onCreate(SatNavActivity.java:159)
10-02 17:11:47.920 E/AndroidRuntime( 8003): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1132)
10-02 17:11:4...

[Guillaume Rosaire (zerog)]

Could be related
http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html

[Guillaume Rosaire (zerog)]

One of the current memory leaks comes from my UncaughtExceptionHandler (issue #6), I'm working on it...

[Guillaume Rosaire (zerog)]

As I said, each the orientation chenges, the Activity is renewed but I kept a reference to each Activity which kept the garbage collector from releasing it. That's fixed in rev 63, forget notes #12 and #13 which are not tied to the current issue

[chris_debian (cjhandrew)]

Can anybody confirm that they have tested this and the problem is solved?

Chris.

[Guillaume Rosaire (zerog)]

chris_debian wrote:
> Can anybody confirm that they have tested this and the problem is solved?
>
> Chris.

Seems ok for me