MVVM Architecture

suggest change

Versions

[{“Name”:“2.1.x”,“GroupName”:null},{“Name”:“2.2.x”,“GroupName”:null},{“Name”:“2.3”,“GroupName”:null},{“Name”:“2.3.3”,“GroupName”:null},{“Name”:“3.0.x”,“GroupName”:null},{“Name”:“3.1.x”,“GroupName”:null},{“Name”:“3.2.x”,“GroupName”:null},{“Name”:“4.0”,“GroupName”:null},{“Name”:“4.0.3”,“GroupName”:null},{“Name”:“4.1”,“GroupName”:null},{“Name”:“4.2”,“GroupName”:null},{“Name”:“4.3”,“GroupName”:null},{“Name”:“4.4”,“GroupName”:null},{“Name”:“4.4W”,“GroupName”:null},{“Name”:“5.0”,“GroupName”:null},{“Name”:“5.1”,“GroupName”:null},{“Name”:“6.0”,“GroupName”:null},{“Name”:“7.0”,“GroupName”:null},{“Name”:“7.1”,“GroupName”:null}]

Remarks

Syntax quirks with DataBinding

When binding a viewModel function to a property in xml certain function prefixes like get or is are dropped. Eg. ViewModel::getFormattedText on the ViewModel will become @{viewModel.formattedText} when binding it to a property in xml. Similarly with ViewModel::isContentVisible -> @{viewModel.contentVisible} (Java Bean notation)

The generated binding classes like ActivityMainBinding are named after the xml they’re creating bindings for, not the java class.

Custom Bindings

In the activity_main.xml I set the textColor attribute on the app and not the android namespace. Why is that? Because there is a custom setter defined for the attribute textColor that resolves a ColorRes resource id send out by the ViewModel to an actual color.

public class CustomBindings {

    @TargetApi(23)
    @BindingAdapter({"bind:textColor"})
    public static void setTextColor(TextView textView, int colorResId) {
        final Context context = textView.getContext();
        final Resources resources = context.getResources();
        final int apiVersion = Build.VERSION.SDK_INT;
        int color;

        if (apiVersion >= Build.VERSION_CODES.M) {
           color = resources.getColor(colorResId, context.getTheme());
        } else {
            color = resources.getColor(colorResId);
        }

        textView.setTextColor(color);
    }

}

For details on how this works check DataBinding Library: Custom Setters

Wait…there is logic in your xml!!!?

You could argue that the things I do in xml for android:visibility and app:textColor are wrong/anti-patterns in the MVVM context because there is view logic in my view. However I would argue it is more important for me to keep android dependencies out of my ViewModel for testing reasons.

Besides, what really does app:textColor do? It only resolves a ressource pointer to the actual color associated with it. So the ViewModel still decides which color is shown based on some condition.

As for the android:visibility I feel because of how the method is named it is actually okay to use the ternary operator here. Because of the name isLoadingVisible and isContentVisible there is really no doubt about what each outcome should resolve to in the view. So I feel it is rather executing a command given by the ViewModel than really doing view logic.

On the other hand I would agree that using viewModel.isLoading ? View.VISIBLE : View.GONE would be a bad thing to do because you are making assumptions in the view what that state means for the view.

Useful Material

The following resources have helped me a lot in trying to understand this concept:

Feedback about page:

Feedback:
Optional: your email if you want me to get back to you:


MVVM Architecture:
* MVVM Architecture

Table Of Contents
2 Gradle
5 Intent
17 Service
19 WebView
31 SQLite
35 Glide
37 Dialog
38 ACRA
44 Handler
53 Toast
63 Menu
65 Picasso
70 Volley
71 Widgets
78 Realm
90 Spinner
95 OkHttp
108 TextView
109 ListView
111 Loader
118 Xposed
119 Security
121 ImageView
123 Doze Mode
130 Drawables
131 Colors
134 Fresco
139 AdMob
145 Keyboard
146 Button
150 EditText
155 Vk SDK
163 ExoPlayer
169 XMPP
175 OpenCV
177 Threads
182 MVVM Architecture
184 ORMLite
186 TabLayout
190 LruCache
192 Zip files
194 Fastlane
199 FileIO
202 Moshi
210 VideoView
216 Paint
218 ProGuard
226 CleverTap
228 ADB shell
229 Ping ICMP
230 AIDL
234 Context
240 JCodec
242 Okio
249 FuseView
254 Looper
261 Fastjson
263 Jackson
267 Smartcard