[
https://issues.apache.org/jira/browse/FLEX-33371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13565735#comment-13565735
]
OmPrakash Muppirala commented on FLEX-33371:
--------------------------------------------
Erik,
I dont have my USB cable with me, so I am not able to test your project. Have
you tried listening to Event.EXITING and Event.DEACTIVATE events thrown by
NativeApplication.nativeApplication to do your cleanup? That way, you can
bypass the spurious viewDeactivate events by not listening to them. The docs
[1] seems to suggest that this is the correct way.
I apologize if this is not related to your problem. I will get a chance to
look at this later tonight if you havent solved your issue by then.
Thanks,
Om
[1]
http://help.adobe.com/en_US/flex/mobileapps/WSa122979b4619725672e48c412a3e152164-8000.html
> On Android, changing orientation fires Event.DEACTIVATE and
> FlexEvent.VIEW_DEACTIVATE events
> --------------------------------------------------------------------------------------------
>
> Key: FLEX-33371
> URL: https://issues.apache.org/jira/browse/FLEX-33371
> Project: Apache Flex
> Issue Type: Bug
> Components: Mobile: MobileApplication
> Affects Versions: Adobe Flex SDK 4.6 (Release)
> Environment: Samsung Galaxy Express and Galaxy S III Android Phones,
> FlashBuilder 4.7 Premium on Windows 7, debugging through USB as well as
> deployed release builds, iPhone and iPad, but the problem doesn't exist on
> iOS devices, only Android
> Reporter: Erik Thomas
> Priority: Critical
> Fix For: Adobe Flex SDK 4.6 (Release)
>
> Attachments: AndroidDeactivateOnOrientationChangeDefect.zip
>
>
> Orientation changes on Android devices always fire the following events in
> this order:
> ViewNavigatorEvent.VIEW_DEACTIVATE
> Event.DEACTIVATE
> StageOrientationEvent.ORIENTATION_CHANGE
> The first two events are a defect. They must not fire simply because the user
> changed the orientation of the phone.
> The result of this defect is that we cannot do two very important things:
> 1. Use view state changes to hide/show layouts, using includeIn property on
> containers and components. On Android, components that are not included for a
> given state are destroyed yet they have state we want to maintain which is
> why we don't change Views.
> 2. We cannot know when the user navigates away from our application, for
> example to press the Home key. We have certain cleanup we must do in our
> complex connected app that streams FMS data, etc., and cannot keep sockets
> open for hours or days.
> On iOS, this is not a problem. Only Android has this bug and it's blocking us
> from releasing our product on Android. iOS does not have this defect.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
