androidandroid-edittextandroid-recyclerviewrealmrealm-java

Using two-way data binding with managed RealmObject in EditText

Background: I am using io.realm:android-adapters:2.0.0 for showing a list of items. Each row consists of three TextViews and two EditText fields. These three TextViews text are set from realm schema. I am using two way data binding for EditText like:

<EditText
 android:layout_width="wrap_content"
 android:layout_height="wrap_content"
 android:inputType="number"
 android:text="@={Conversion.toString(offline.inputUI)}" />

This offline is the schema that extends RealmObject with two @Ignore fields which correspond to the two EditText. Vales are reflected in the offline model when user types.

Problem: When I scroll past the screen EditText values are lost. If four rows are visible at a time on the screen and user feed the EditText and scrolls for the next four rows and if revisits the first four rows values of all EditText are lost. This is happening because of zero copy design and I understand it. However if I remove the @Ignore from EditText then an exception is thrown that you cannot perform transaction outside ....etc.

Desired output How to avoid the values of EditText vanishing while scrolling and taking the benefit of realm zero copy design. Also, save the values of EditText in realm in real time as user types or after user has left the EditText. Is it really possible or not? . Do I need to change my current approach. If I use frequent write transactions when focus is changed from EditText, will it drain the battery?

Solution

  • If you want to leverage Realms zero-copy architecture, the only solution is to persist all the data you want to have saved, but 2-way databinding with automatic transactions are not supported automatically right now.

    You could make it work if you added transactions to all setters used by databinding. But depending on how often you are saving data, it could still result in introducing jank to your UI.

    It is a problem we are thinking about, but we will not be able to provide any solutions in the short-term.

    I'm afraid, that no matter what, there isn't any "easy" choice.

    Note, battery drain is not the issue, but that you will be writing to disk very frequently.