'Jobject' no debe ser IntPtr.Zero al ajustar el texto textview en MonoDroid

Al mezclar los contextos de vinculación de listitem / célula con el contexto padre, estás entrando en un área bastante avanzada.

Para ayudar a intentar explicar / depurar lo que está pasando, es necesario comprender un poco acerca de todo el ciclo de vida de los padres, el ciclo de vida de listitem / célula y los ciclos de vida de los contextos de enlace MvvmCross correspondientes.

En el nivel de ciclo de vida de los padres, generalmente se trata de una Activity o Fragment Android. Para simplificar, utilizaré Activity para el resto de esta respuesta.

Esta Activity tiene un par de eventos clave del ciclo de vida

• OnCreate se llama una sola vez cuando se lanza la Activity
• OnDestroy se llama una sola vez cuando la Activity no se mostrará de nuevo.

MvvmCross intercepta estos eventos y:

• Dentro de OnCreate , establece un ViewModel como ViewModel la Activity . Código de usuario – normalmente código Xml inflado dentro de SetContentView – a continuación, crea enlaces. Estos enlaces se almacenan dentro del BindingContext de la Activity
• Dentro de OnDestroy , MvvmCross destruye todos los enlaces dentro de BindingContext

En la interfaz de usuario que nos interesa aquí, la Activity posee un ListView , y que ListView tiene un Adapter configurado para él. Dentro de este escenario, el DataContext para el ListView y su Adapter es el mismo como su padre.

Dentro de la vida útil de ListView la lista puede necesitar mostrar un montón de elementos. Los elementos que se muestran en cualquier momento pueden cambiar, tanto por las acciones táctiles del usuario como por los cambios del modelo de vista. Para mostrar estos elementos, el ListView le pregunta al Adapter para View . Para cada elemento se muestra que el Adapter suministra una View , y estas View pueden ser reutilizadas (utilizando el parámetro convertView ). Sin embargo, a veces, estas View también no se reutilizan; en esta situación, a veces es posible que el objeto Ver permanezca en C # incluso después de que se haya quitado Java / Dalvik View se haya finalizado Java.

MvvmCross intercepta las llamadas GetView dentro de su MvxAdapter . Para cada llamada no devuelve sólo una View pero además y MvxListItemView . Esta es una View con un BindingContext añadido – y esto permite a los usuarios de MvvmCross vincular cada MvxListItemView a su elemento de lista DataContext .

Cuando se MvxListItemView utilizar un MvxListItemView , es sencillo para MvvmCross cambiar simplemente su DataContext .

Cuando un MvxListItemView no se reutiliza – cuando se quita de la interfaz de usuario y, a continuación, JavaFinalize d – MvvmCross intercepta el evento OnDetachedFromWindow y utiliza esto para cambiar el DataContext a null . Esto se hace en OnDetachedFromWindow lugar de JavaFinalize como la llamada a la ventana se garantiza que se haga en el hilo de interfaz de usuario y como se siente (a mí) como un lugar más limpio para hacer esto.

Tenga en cuenta que parte de este comportamiento ha cambiado sutilmente en versiones recientes, pero esta descripción anterior es correcta para v3.0.14

Con ese fondo en su lugar, lo que parece que está intentando hacer es crear un enlace para el contenido de un ListItemView dentro del BindingContext de la Activity .

Esto significa que el enlace no tiene realmente una buena comprensión del ciclo de vida de ListItemView – por lo que el enlace puede decir vivo incluso después de que el ListItemView ha sido eliminado de la pantalla y (tal vez) finalizado.

Para resolver este problema …

• Creo que la ruta más simple es cambiar el DataContext para su listitem. Si su enlace ListItemView es un simple enlace normal – si contiene la propiedad MinutesRemaining – entonces no debe golpear estos errores del ciclo de vida.
• Usted puede intentar el enlace avanzado encontrado en la respuesta de @ Jamie ( https://stackoverflow.com/a/20031690/373321 ) – sin embargo, creo que esta respuesta todavía no lo entiendo bien – como creo:
  • No maneja correctamente el caso donde el listitemview se quita / finalizó – si el primer artículo de la lista se desplaza fuera de pantalla bajo el código actual entonces creo que todavía puede ver problemas. Para utilizar el adaptador de código basado, entonces creo que el adaptador necesita de alguna manera obtener una devolución de llamada desde el listitemview en el caso de que la vista se elimina de la interfaz de usuario o finalizado.
  • El JavaFinalize en esa respuesta es "un poco travieso" en que borra la Activity principal BindingContext durante la Finalize del Adapter . Esto es probablemente OK para hacer pero no debería ser realmente necesario – OnDestroy debe manejar eso.

Se corrigió actualizando el código del adaptador anterior a:

  public class SubjectFilterAdapter : MvxAdapter { private EntityListFragment<TEntity, TViewModel> _owner; private MvxFluentBindingDescriptionSet<EntityListFragment<TEntity, TViewModel>, TViewModel> _scheduleBindingSet; public SubjectFilterAdapter(Context context, EntityListFragment<TEntity, TViewModel> owner) : base(context, (IMvxAndroidBindingContext)owner.BindingContext) { _owner = owner; } protected override View GetBindableView(View convertView, object dataContext, int templateId) { var view = base.GetBindableView(convertView, dataContext, templateId); if (templateId == ItemTemplateId && GetPosition(dataContext) == 0) { if (_scheduleBindingSet != null) { _owner.BindingContext.ClearBindings("SelectedScheduleTextFilterBinding"); _scheduleBindingSet = null; } _scheduleBindingSet = _owner.CreateBindingSet<EntityListFragment<TEntity, TViewModel>, TViewModel>(); _scheduleBindingSet.Bind(view.FindViewById<TextView>(Resource.Id.SelectedScheduleText)) .To(x => x.SelectedScheduleText).WithClearBindingKey("SelectedScheduleTextFilterBinding"); _scheduleBindingSet.Apply(); } return view; } protected override void JavaFinalize() { if (this.BindingContext != null) this.BindingContext.ClearAllBindings(); base.JavaFinalize(); } }