Async / esperar malas prácticas bajo Android?

Actualmente estoy portando una aplicación C # Windows 8 / iOS existente a Android (con Xamarin).

Utilicé una gran cantidad de async / await para el archivo IO, diálogos, red, etc …

¿Qué sucede cuando la aplicación se detiene / suspende durante una llamada de espera? Bajo Windows e iOS hay dos posibilidades:

La aplicación se reanuda más tarde, como si nada hubiera pasado
La aplicación se termina si la memoria es baja.

En ambos casos, no hay fugas de memoria, no hay cambios en el flujo de control.

Sin embargo, bajo Android, una actividad puede ser destruida y recreada mientras el proceso permanece activo. En mi entendimiento de async / esperan esto significa:

Un diálogo no cerrado esperará para siempre, lo que significa que los objetos que eran accesibles desde el llamador ("esto", variables locales, etc) permanecerá en la memoria para siempre (pérdida de memoria)
Cuando una solicitud de red esperada termina mientras la anterior actividad ya ha sido destruida por Android, el código después de "esperar" (por ejemplo, escritura de archivo) podría colisionar porque existen dos instancias en ejecución de la Actividad.

¿Mis afirmaciones son verdaderas? En caso afirmativo, ¿qué se puede hacer? (Sin hacer el programa tan complicado como antes de la invención de async / await)

Una actividad de Android está garantizada para llamar a OnPause antes de que la actividad se desactive / destruya y OnResume cuando se inicia (consulte http://developer.android.com/training/basics/activity-lifecycle/index.html ).

¿Qué tal si usted tenía un CancellationTokenSource disponible de su actividad. A continuación, en OnPause puede llamar Cancelar y luego usar:

try { // Your async code ... } catch (OperationCancelledException e) { }

Consulte también http://msdn.microsoft.com/en-us/library/jj155759.aspx para cancelar tareas asíncronas.

Más una sugerencia que una respuesta definitiva, pero espero que ayude.

Editar:

Cuando empecé a introducir async / await en mi código, lo encontré como un virus zombie. Una vez que comience a asíncratarlo, encontrará que se extiende a lo largo del resto de su código. Puede ser que usted tiene un montón de llamadas asíncronas por la misma razón. Generalmente hay dos reglas a seguir:

Declare métodos como public async Task Foo() lugar de public async void Foo()
No bloquee el código asíncrono

En mi propia práctica, he descubierto dos lugares donde puedes romper estas reglas generales.

Si está en la parte superior (es decir, la interfaz de usuario) de su código, puede haber lugares donde tiene que declarar código como async void porque el delegado que está reemplazando toma void como un tipo de devolución. Un ejemplo típico de esto es con un método button.Click.
Tenía una llamada de la base de datos que miró para arriba un solo valor en una base de datos. Si lo convertí a asíncrona, un montón de mi código en otro lugar tendría que cambiar. Descubrí que si estás garantizado, y quiero decir garantizado , estar en la parte inferior de tu código, específicamente que ninguno de los métodos debajo de la que estás llamando utilizar asíncrona, entonces usted puede llamar con seguridad. Tarea. Esto me ahorró de asíncrono la mitad de mi código innecesariamente.

Espero que esto ayude.

Puede utilizar un servicio para realizar estas tareas largas en ejecución. Otra opción sería utilizar un fragmento sin cabeza (uno sin una vista y que es .RetainInstance propiedad establecida en true ).