[moved] Phone hangs for 15s after closing IAP app?

[jkosonen]

Hi

The latest news from first hands are bad : on SR1 (belle) or SR2 environment task switch system is changed and after application exit it will switch to next process. Even if process is not listed in task switcher it switches to iapengine.exe process. This process have exit timeout (~20s) after last client is disconnect. This process consumes all touch events.

You can make delay before application exit showing busy indication --- that would be reasonable device behavior from user point of view --- from the other hand dev team is fixing the bug in future IAP version. New IAP version will be just announced since no application re-build is required.

Anyway please have a look on delay proposal implementation --- installation package is also available -- so you can quick check how it looks. I hardcoded delay in 21 seconds.

However the problem is not seen in Application manager --- you can scroll the app grid right after your app exit.

Regards,
izinin

Thanks for the info. Any time schedule, when the new fixed version of IAP would be available? It's not optimal for users if they want to close the app but it won't shutdown instantly.

Edit: One thing I noticed, if you have the delayed shutdown, you can minimize your app to background and everything works ok then. Any chance that you could add to your code that when the delayed shutdown starts, it minimizes the app to background, so I could test that? That way user experience would be ok. And even better if the app could also be hidden from the task manager, but is that doable?

[wizard_hu_]

In fact that would have been my initial idea for a workaround, however now with the real cause revealed it probably could not help. It is the second application in the "stack" which closes slowly. So sending your own app to the background will do the same as simply exiting from it: the topmost app disappears, while the second, non-responsive one appears and steals the focus.
As far as I know this "stack" is not really readable, so there is no general way to check the 3rd application and bring it to the foreground (also, it would have a strange result after fixing the problem). An acceptable workaround could be bringing the Home screen in front, users can probably tolerate that (do not even notice perhaps).

[jkosonen]

In fact that would have been my initial idea for a workaround, however now with the real cause revealed it probably could not help. It is the second application in the "stack" which closes slowly. So sending your own app to the background will do the same as simply exiting from it: the topmost app disappears, while the second, non-responsive one appears and steals the focus.
As far as I know this "stack" is not really readable, so there is no general way to check the 3rd application and bring it to the foreground (also, it would have a strange result after fixing the problem). An acceptable workaround could be bringing the Home screen in front, users can probably tolerate that (do not even notice perhaps).

Hmm, why does it work if you manually put it to background then?

E: And is there any easy way to bring home screen in front, for regular developer like me?

[wizard_hu_]

Hmm, why does it work if you manually put it to background then?

What you do manually is bringing an application to the foreground, like the Menu or the Home screen. After that it does not matter what other applications do in the background (stuck or not). It is different from sending your own application to the background, because in this latter case there are good chances that the non-responsive application will get the foreground.

An other test which could be done is: starting the IAP demo application, doing whatever you want from it (so testing the functionality, etc.), switching to the Home screen, switching back to the application, and exit from it. In this case the second element in the "stack" is the Home screen, and exiting the application is expected to make it responsive immediately. Since the invisible server app is somewhere else.

E: And is there any easy way to bring home screen in front, for regular developer like me?

Something like

const TUid KHomeScreenUID={0x100058b3};
TApaTaskList taskList(CEikonEnv::Static()->WsSession());
TApaTask task (taskList.FindApp(KHomeScreenUID));
task.BringToForeground();

The UID may vary, however: http://www.developer.nokia.com/Commu..._standby_phone

[derconny]

Hi,

I just wanted to chime in because my app (using IAP) is showing the same issue. This happens on Anna and Belle. If you need more information for debugging, please let me know. I'm watching the thread.

[izinin]

Hi derconny

I think there is no update expected in this discussion thread. The summary is as the following: this defect is fixed in IAP future release. For now there is only workaround available. Please check message thread below for some ideas how to diminish user experience impact. You can experiment with test application that reveals the problem https://projects.developer.nokia.com/IAP_QML_minimal , the latest variant implements 20 seconds IAP shutdown before the application exit. Good idea is to show HomeScreen on application exit.

Please note IAP initialization takes considerably time and is blocking synchronous operation -- for that reason it is recommended to instantiate IAP once per application session on the app start

[derconny]

Hi izinin,

Hi derconny

I think there is no update expected in this discussion thread. The summary is as the following: this defect is fixed in IAP future release. For now there is only workaround available. Please check message thread below for some ideas how to diminish user experience impact. You can experiment with test application that reveals the problem https://projects.developer.nokia.com/IAP_QML_minimal , the latest variant implements 20 seconds IAP shutdown before the application exit. Good idea is to show HomeScreen on application exit.

Thanks for the summary. I've read the thread and I just offered my help for debugging this issue.

Please note IAP initialization takes considerably time and is blocking synchronous operation -- for that reason it is recommended to instantiate IAP once per application session on the app start

I know. In fact I've reported it here about 2 month ago.