1
00:00:01,310 --> 00:00:06,830
All right, so far we have created the news app with no particular architecture, but only separating

2
00:00:06,830 --> 00:00:09,800
the remote data logic from the composable interfaces.

3
00:00:10,190 --> 00:00:16,610
Now we want to clean up the app a little more using the AMP VM architecture, using code routines for

4
00:00:16,610 --> 00:00:24,320
asynchronous tasks and operations, as well as adding a data processor, state or multiple ones, like

5
00:00:24,320 --> 00:00:26,840
when it's loading or when an error occurs.

6
00:00:27,530 --> 00:00:35,480
So in the project now we have the news manager class as the intermediary between the composable UI and

7
00:00:35,480 --> 00:00:36,380
the service class.

8
00:00:36,740 --> 00:00:44,690
The data flows from the new service class to the new manager and then the respective user interfaces.

9
00:00:45,080 --> 00:00:51,260
We are using the retrofit call interface for asynchronous operations and mutable state of in order to

10
00:00:51,260 --> 00:00:52,850
hold observable data.

11
00:00:53,210 --> 00:00:58,340
So let's look at how this will change with the VM architecture.

12
00:00:59,890 --> 00:01:06,370
For the movie architecture, instead of the news manager class sending data to the UI, it sends it

13
00:01:06,370 --> 00:01:13,480
to the repository class, which then passes it to the main view model, where each UI will connect to

14
00:01:13,480 --> 00:01:15,670
and observe the data states from there.

15
00:01:16,240 --> 00:01:23,050
So every place in the UI where we have the news manager will be replaced with the main view model.

16
00:01:23,800 --> 00:01:30,820
The VM and NVMe, which is the View model, is a special class created to solve particular problems

17
00:01:31,480 --> 00:01:33,220
when using code routines.

18
00:01:33,220 --> 00:01:40,060
Just like we will be doing with a view model subclass, we can launch a scope using view model scope

19
00:01:40,330 --> 00:01:47,380
that is tied to the View model and is automatically cleared after using to avoid a memory leak.

20
00:01:48,460 --> 00:01:52,090
Another advantage is during the screen configuring changes.

21
00:01:52,420 --> 00:01:54,290
Data is usually recreated.

22
00:01:54,610 --> 00:02:00,310
But with the view model, the state will be retained and the data remains the same.

23
00:02:01,330 --> 00:02:07,960
So we will be modifying the app to show a progress bar when the data is loading a text element when

24
00:02:08,289 --> 00:02:09,220
there is an error.

25
00:02:09,490 --> 00:02:13,150
And if the request is successful, the data is going to be displayed.

26
00:02:13,480 --> 00:02:16,330
We will learn more about this in the coming lectures.

27
00:02:16,480 --> 00:02:17,950
So let's get started.