Видео. Architecture Components. Improve Your App's Design. Перевод субтитров.

01 сентября 2017

Теги: Java, Android, Архитектура, Video, Youtube, Translate, Architecture Components, Философия

Смотри другие переводы видео (субтитры) по этой теме: Tag: Architecture Components

Мой клон с русскими субтитрами:

Оригинальное видео:

Аннотация к видео:

Build robust Android apps using the new architecture components. New classes and interfaces, such as ViewModel, LiveData and LifecycleObserver, make it easy to access and manage the Activity and Fragment Lifecycle. Room, an object mapping library for SQLite, simplifies caching, loading and displaying your app’s data. Used together, you can quickly generate SQLite databases and get information into your app’s UI with far less boilerplate code, letting you focus on the code that makes your app unique.

Перевод:

Создавайте надежные приложения для Android, используя новые архитектурные компоненты. Новые классы и интерфейсы, такие как ViewModel, LiveData и LifecycleObserver, облегчают доступ к жизненному циклу Activity и Fragment и управлению ими. Room, object mapping library для SQLite, упрощает кэширование, загрузку и отображение данных вашего приложения. Используя все это, вы можете быстро создавать базы данных SQLite и получать информацию в UI вашего приложения с гораздо меньшим количеством шаблонного кода. Это позволяет вам сосредоточиться на коде, который делает ваше приложение уникальным.

Ссылки к видео:

единая точка входа для архитектурных компонентов - LiveData, ViewModel, LifecycleObserver, LifecycleOwner, Room (абстрация над SQLite базой данных), etc.
Android Persistence: Room Library - tutorial codelab.
о Room - article with Kotlin.
Room, ViewModel, LifeCycle, LiveData - article
Android lifecycle-aware components - tutorial codelab.
Architecture Components: Improve Your App’s Design - видео-обзор от Google новых архитектурных компонентов, 5 мин 41 сек на просмотр.

Перевод субтитров
English	Русский
1 00:00:00,000 --> 00:00:02,130 LYLA: In response to popular demand, 2 00:00:02,130 --> 00:00:05,010 the Android Framework team has written an opinionated guide 3 00:00:05,010 --> 00:00:06,960 to architecting Android apps, and they've 4 00:00:06,960 --> 00:00:09,870 developed a companion set of architecture components. 5 00:00:09,870 --> 00:00:12,960 Hi, my name's Lyla, a developer advocate for Android, 6 00:00:12,960 --> 00:00:15,900 and I'm here to introduce you to these shiny new architecture 7 00:00:15,900 --> 00:00:17,070 components. 8 00:00:17,070 --> 00:00:19,890 These components persist data, manage lifecycle, 9 00:00:19,890 --> 00:00:22,860 make your app modular, help you avoid memory leaks, 10 00:00:22,860 --> 00:00:26,430 and prevent you from having to write boring boilerplate code. 11 00:00:26,430 --> 00:00:28,680 Your basic Android app needs a database 12 00:00:28,680 --> 00:00:30,780 connected to a robust UI. 13 00:00:30,780 --> 00:00:33,890 The new components, Room, ViewModel, LiveData, 14 00:00:33,890 --> 00:00:35,732 and Lifecycle, make that easy. 15 00:00:35,732 --> 00:00:38,190 They're also designed to fit together like building blocks, 16 00:00:38,190 --> 00:00:39,690 so let's see how. 17 00:00:39,690 --> 00:00:42,990 I'll tackle the database using Room, which is a new SQLite 18 00:00:42,990 --> 00:00:44,820 object mapping library. 19 00:00:44,820 --> 00:00:46,440 To set up the tables using Room, we 20 00:00:46,440 --> 00:00:49,550 can define a Plain Old Java Object, or a POJO. 21 00:00:49,550 --> 00:00:52,950 We then mark this POJO with the @Entity annotation 22 00:00:52,950 --> 00:00:56,650 and create an ID marked with the @PrimaryKey annotation. 23 00:00:56,650 --> 00:00:59,820 Now for each POJO, you need to define a DAO, or a Database 24 00:00:59,820 --> 00:01:01,290 Access Object. 25 00:01:01,290 --> 00:01:03,130 The annotated methods represent the SQLite 26 00:01:03,130 --> 00:01:05,950 commands that you need to interact with your POJO's data. 27 00:01:05,950 --> 00:01:08,790 Now, take a look at this insert method and this query method. 28 00:01:08,790 --> 00:01:11,400 Room has automatically converted your POJO objects 29 00:01:11,400 --> 00:01:14,265 into the corresponding database tables, and back again. 30 00:01:14,265 --> 00:01:17,130 Room also verifies your SQLite at compile time. 31 00:01:17,130 --> 00:01:19,150 So if you spell something a little bit wrong, 32 00:01:19,150 --> 00:01:21,150 or if you reference a column that's not actually 33 00:01:21,150 --> 00:01:24,310 in the database, it will throw a helpful error. 34 00:01:24,310 --> 00:01:26,070 Now that you have a Room database, 35 00:01:26,070 --> 00:01:27,570 you can use another new architecture 36 00:01:27,570 --> 00:01:30,210 component, called LiveData, to monitor changes 37 00:01:30,210 --> 00:01:31,320 in the database. 38 00:01:31,320 --> 00:01:33,900 LiveData is an observable data holder. 39 00:01:33,900 --> 00:01:35,910 That means it holds data and notifies you 40 00:01:35,910 --> 00:01:39,090 with the data changes so that you can update the UI. 41 00:01:39,090 --> 00:01:41,790 LiveData is an abstract class that you can extend, 42 00:01:41,790 --> 00:01:45,600 or, for simple cases, you can use the MutableLiveData class. 43 00:01:45,600 --> 00:01:47,730 If you update the value of the MutableLiveData 44 00:01:47,730 --> 00:01:50,230 with a call to set value, it could then trigger and update 45 00:01:50,230 --> 00:01:51,570 in your UI. 46 00:01:51,570 --> 00:01:53,170 What's even more powerful though, 47 00:01:53,170 --> 00:01:55,680 is that Room is built to support LiveData. 48 00:01:55,680 --> 00:01:58,080 To use them together, you just modify your DAO 49 00:01:58,080 --> 00:02:00,450 to return objects that are wrapped with the LiveData 50 00:02:00,450 --> 00:02:01,360 class. 51 00:02:01,360 --> 00:02:04,850 Room will create a LiveData object observing the database. 52 00:02:04,850 --> 00:02:08,258 Then you could write code like this to update your UI. 53 00:02:08,258 --> 00:02:10,959 The end result is that if your Room database updates, 54 00:02:10,960 --> 00:02:13,410 it changes the data in your LiveData object, which 55 00:02:13,410 --> 00:02:15,930 automatically triggers UI updates. 56 00:02:15,930 --> 00:02:18,840 This brings me to another awesome feature of LiveData. 57 00:02:18,840 --> 00:02:21,344 LiveData is a lifecycle-aware component. 58 00:02:21,344 --> 00:02:23,010 Now, you might be thinking, what exactly 59 00:02:23,010 --> 00:02:24,990 is a lifecycle-aware component? 60 00:02:24,990 --> 00:02:26,390 Well, I'm glad you asked. 61 00:02:26,390 --> 00:02:28,620 Through the magic of lifecycle observation, 62 00:02:28,620 --> 00:02:31,160 LiveData knows when your activity is on screen, 63 00:02:31,160 --> 00:02:34,200 off screen, or destroyed, so that it doesn't send database 64 00:02:34,200 --> 00:02:36,600 updates to a non-active UI. 65 00:02:36,600 --> 00:02:38,520 There are two interfaces for this-- 66 00:02:38,520 --> 00:02:41,070 Lifecycle Owner and Lifecycle Observer. 67 00:02:41,070 --> 00:02:43,200 Lifecycle Owners are objects with lifecycles, 68 00:02:43,200 --> 00:02:44,820 like activities and fragments. 69 00:02:44,820 --> 00:02:46,620 Lifecycle Observers, on the other hand, 70 00:02:46,620 --> 00:02:50,509 observe Lifecycle Owners and are notified of lifecycle changes. 71 00:02:50,509 --> 00:02:52,050 Here's a quick peek at the simplified 72 00:02:52,050 --> 00:02:55,770 code for LiveData, which is also a Lifecycle Observer. 73 00:02:55,770 --> 00:02:58,890 The methods annotated with @OnLifecycleEvent 74 00:02:58,890 --> 00:03:00,970 take care of initialization and tear down 75 00:03:00,970 --> 00:03:04,350 when the associated Lifecycle Owner starts and stops. 76 00:03:04,350 --> 00:03:07,530 This allows LiveData objects to take care of their own setup 77 00:03:07,530 --> 00:03:09,690 and tear down, so the UI components 78 00:03:09,690 --> 00:03:12,000 observe the LiveData, and the LiveData components 79 00:03:12,000 --> 00:03:13,890 observe the Lifecycle Owners. 80 00:03:13,890 --> 00:03:16,380 As a side note to all you Android library designers out 81 00:03:16,380 --> 00:03:19,350 there, you can use this exact same lifecycle observation 82 00:03:19,350 --> 00:03:22,350 code to call setup and tear down functions automatically 83 00:03:22,350 --> 00:03:24,240 for your own libraries. 84 00:03:24,240 --> 00:03:26,559 Now you still have one more problem to solve. 85 00:03:26,559 --> 00:03:29,100 As your app is used, it will go through various configuration 86 00:03:29,100 --> 00:03:32,070 changes that destroy and rebuild the activity. 87 00:03:32,070 --> 00:03:34,800 We don't want to tie the initialization of LiveData 88 00:03:34,800 --> 00:03:36,660 to the activity lifecycle because that 89 00:03:36,660 --> 00:03:39,830 causes a lot of needlessly re-executed code. 90 00:03:39,830 --> 00:03:41,910 An example of this is your database query, 91 00:03:41,910 --> 00:03:44,820 which is executed every time you rotate the phone. 92 00:03:44,820 --> 00:03:46,300 So what do you do? 93 00:03:46,300 --> 00:03:48,750 Well, you put your LiveData and any other data 94 00:03:48,750 --> 00:03:52,230 associated with the UI in a ViewModel instead. 95 00:03:52,230 --> 00:03:55,650 ViewModels are objects that provide data for UI components 96 00:03:55,650 --> 00:03:57,750 and survive configuration changes. 97 00:03:57,750 --> 00:04:01,500 To create a ViewModel object, you extend the ViewModel class. 98 00:04:01,500 --> 00:04:03,450 You then put all of the necessary data 99 00:04:03,450 --> 00:04:06,030 for your activity UI into the ViewModel. 100 00:04:06,030 --> 00:04:08,850 Since you've cached data for the UI inside of the ViewModel, 101 00:04:08,850 --> 00:04:10,590 your app won't requery the database 102 00:04:10,590 --> 00:04:13,860 if your activity is recreated due to a configuration change. 103 00:04:13,860 --> 00:04:16,140 Then, when you're creating your activity or fragment, 104 00:04:16,140 --> 00:04:18,660 you can get a reference to the ViewModel and use it. 105 00:04:18,660 --> 00:04:19,680 And that's it! 106 00:04:19,680 --> 00:04:21,269 The first time you get a ViewModel, 107 00:04:21,269 --> 00:04:23,160 it's generated for your activity. 108 00:04:23,160 --> 00:04:24,840 When you request a ViewModel again, 109 00:04:24,840 --> 00:04:27,000 your activity receives the original ViewModel 110 00:04:27,000 --> 00:04:28,980 with the UI data cache, so there's 111 00:04:28,980 --> 00:04:31,410 no more useless database calls. 112 00:04:31,410 --> 00:04:34,290 To summarize all of this new architecture shininess, 113 00:04:34,290 --> 00:04:37,140 we've talked about Room, which is an object mapping 114 00:04:37,140 --> 00:04:40,350 library for SQLite, LiveData, which notifies you 115 00:04:40,350 --> 00:04:43,080 when its data changes so that you could update the UI, 116 00:04:43,080 --> 00:04:45,200 and importantly, it works well with Room, 117 00:04:45,200 --> 00:04:47,070 so that you can easily update the UI when 118 00:04:47,070 --> 00:04:48,820 the database values change. 119 00:04:48,820 --> 00:04:51,480 We've also talked about Lifecycle Observers and Owners, 120 00:04:51,480 --> 00:04:55,020 which allow non-UI objects to observe lifecycle events. 121 00:04:55,020 --> 00:04:57,150 And finally, we talked about ViewModels, 122 00:04:57,150 --> 00:04:58,770 which provide you data objects that 123 00:04:58,770 --> 00:05:00,890 survive configuration changes. 124 00:05:00,890 --> 00:05:03,710 Altogether, they make up a set of architecture components 125 00:05:03,710 --> 00:05:07,190 for writing modular, testable, and robust Android apps. 126 00:05:07,190 --> 00:05:08,660 You can sensibly use them together, 127 00:05:08,660 --> 00:05:10,700 or you can pick and choose what you need. 128 00:05:10,700 --> 00:05:12,530 But this is just the tip of the iceberg. 129 00:05:12,530 --> 00:05:14,720 In fact, a more fully-fledged Android app 130 00:05:14,720 --> 00:05:16,310 might look like this. 131 00:05:16,310 --> 00:05:19,150 For an in-depth look at how everything works together 132 00:05:19,150 --> 00:05:20,900 and the reasoning behind these components, 133 00:05:20,900 --> 00:05:23,174 check out the links in the description below. 134 00:05:23,174 --> 00:05:24,590 To jump straight into code and get 135 00:05:24,590 --> 00:05:26,090 started working with these objects, 136 00:05:26,090 --> 00:05:27,840 you can check out the codelabs and samples 137 00:05:27,840 --> 00:05:29,500 for lifecycle and persistence. 138 00:05:29,500 --> 00:05:32,180 Happy building and, as always, don't forget to subscribe. 139 00:05:32,180 --> 00:05:34,330 [MUSIC PLAYING] 140 00:05:34,330 --> 00:00:00,000	1 00:00:00,000 --> 00:00:02,130 LYLA: В ответ на популярный запрос, 2 00:00:02,130 --> 00:00:05,010 команда Android Framework написала свой гид 3 00:00:05,010 --> 00:00:06,960 по архитектуре Android приложений, и они 4 00:00:06,960 --> 00:00:09,870 разработали соответствующие архитектурные компоненты. 5 00:00:09,870 --> 00:00:12,960 Hi, меня зовут Lyla, и я разработчик Android, 6 00:00:12,960 --> 00:00:15,900 И я сейчас представлю для вас эти замечательные архитектурные 7 00:00:15,900 --> 00:00:17,070 компоненты. 8 00:00:17,070 --> 00:00:19,890 Эти компоненты хранят данные, управляют жизненным циклом, 9 00:00:19,890 --> 00:00:22,860 делают ваше приложение модульным, помогают избежать утечек памяти, 10 00:00:22,860 --> 00:00:26,430 И не заставляют вас использовать скучные шаблоны кода. 11 00:00:26,430 --> 00:00:28,680 Основной части Android приложений нужна база данных 12 00:00:28,680 --> 00:00:30,780 подключенная надежно к UI. 13 00:00:30,780 --> 00:00:33,890 Новые компоненты: Room, ViewModel, LiveData, 14 00:00:33,890 --> 00:00:35,732 и Lifecycle, делают это простым. 15 00:00:35,732 --> 00:00:38,190 Они могут использоваться совместно, как строительные блоки, 16 00:00:38,190 --> 00:00:39,690 давайте посмотрим каким образом. 17 00:00:39,690 --> 00:00:42,990 Я собираюсь использовать базу данных Room, как новую SQLite 18 00:00:42,990 --> 00:00:44,820 ORM библиотеку. 19 00:00:44,820 --> 00:00:46,440 Чтобы настроить таблицы используя Room, мы 20 00:00:46,440 --> 00:00:49,550 можем определить Старый Добрый Java Объект, или POJO. 21 00:00:49,550 --> 00:00:52,950 Мы тогда помечаем этот POJO аннотацией @Entity 22 00:00:52,950 --> 00:00:56,650 и создаем ID маркер с аннотацией @PrimaryKey. 23 00:00:56,650 --> 00:00:59,820 Теперь для каждого POJO, мы должны определить DAO, или Database 24 00:00:59,820 --> 00:01:01,290 Access Object. 25 00:01:01,290 --> 00:01:03,130 Аннотированные методы представляют собой SQLite 26 00:01:03,130 --> 00:01:05,950 команды, которые должны взаимодействовать с данными POJO . 27 00:01:05,950 --> 00:01:08,790 Теперь взгляните на этот insert метод и на query метод. 28 00:01:08,790 --> 00:01:11,400 Room автоматически конвертирует ваш POJO объект 29 00:01:11,400 --> 00:01:14,265 в соответствующие таблицы базы данных и обратно. 30 00:01:14,265 --> 00:01:17,130 Room также проверяет правильность вашего SQLite во время компиляции. 31 00:01:17,130 --> 00:01:19,150 И если вы напишите что-то немного не так, 32 00:01:19,150 --> 00:01:21,150 или ваша ссылка на столбец будет не актуальна а БД, 33 00:01:21,150 --> 00:01:24,310 то выкинится полезная предупреждающая ошибка. 34 00:01:24,310 --> 00:01:26,070 Теперь, когда у вас есть Room база данных, 35 00:01:26,070 --> 00:01:27,570 вы можете использовать другие новые архитектурные компоненты 36 00:01:27,570 --> 00:01:30,210 называемые LiveData, для мониторинга изменений 37 00:01:30,210 --> 00:01:31,320 в базе данных. 38 00:01:31,320 --> 00:01:33,900 LiveData это наблюдаемый [observable] держатель данных. 39 00:01:33,900 --> 00:01:35,910 Это значит, что он хранит данные и оповещает вас 40 00:01:35,910 --> 00:01:39,090 если данные изменились, и вы можете обновить UI. 41 00:01:39,090 --> 00:01:41,790 LiveData это абстрактный класс который вы можете расширить, 42 00:01:41,790 --> 00:01:45,600 или, для простых случаев, вы можете использовать MutableLiveData класс. 43 00:01:45,600 --> 00:01:47,730 Если вы обновляете данные в MutableLiveData 44 00:01:47,730 --> 00:01:50,230 с установлением нового значения, это может обновить и изменить 45 00:01:50,230 --> 00:01:51,570 ваш UI. 46 00:01:51,570 --> 00:01:53,170 Что еще более мощно, так это то, что 47 00:01:53,170 --> 00:01:55,680 Room построена на поддержке LiveData. 48 00:01:55,680 --> 00:01:58,080 Чтобы использовать их вместе, вы просто изменяете DAO 49 00:01:58,080 --> 00:02:00,450 так чтобы возвращать объекты завернутые в LiveData 50 00:02:00,450 --> 00:02:01,360 класс. 51 00:02:01,360 --> 00:02:04,850 Room создаст объект LiveData наблюдающий базу данных. 52 00:02:04,850 --> 00:02:08,258 Тогда вы могли бы писать код для обновления вашего UI. 53 00:02:08,258 --> 00:02:10,959 В конечном счете если вы обновляете вашу Room БД, 54 00:02:10,960 --> 00:02:13,410 эти изменения изменят данные вашего LiveData объекта, 55 00:02:13,410 --> 00:02:15,930 который автоматически включит обновление UI. 56 00:02:15,930 --> 00:02:18,840 Это подводит меня к другой удивительной особенности LiveData. 57 00:02:18,840 --> 00:02:21,344 LiveData осведомлен о жизненном цикле. 58 00:02:21,344 --> 00:02:23,010 Теперь вы можете подумать, что именно представляет собой 59 00:02:23,010 --> 00:02:24,990 осведомленный о жизненном цикле компонент? 60 00:02:24,990 --> 00:02:26,390 Хорошо, я рада, что вы спросили. 61 00:02:26,390 --> 00:02:28,620 Через магическое наблюдение за жизненным циклом, 62 00:02:28,620 --> 00:02:31,160 LiveData знает когда ваша активити на экране, 63 00:02:31,160 --> 00:02:34,200 спит, или разрушена, итак база данных не отправляет 64 00:02:34,200 --> 00:02:36,600 обнавления неактивному UI. 65 00:02:36,600 --> 00:02:38,520 Есть два интерфейса для этого - 66 00:02:38,520 --> 00:02:41,070 Lifecycle Owner и Lifecycle Observer. 67 00:02:41,070 --> 00:02:43,200 Lifecycle Owners это объекты с жизненным циклом 68 00:02:43,200 --> 00:02:44,820 подобным таковым у Activity и Fragment. 69 00:02:44,820 --> 00:02:46,620 Lifecycle Observers, с другой стороны, наблюдают 70 00:02:46,620 --> 00:02:50,509 Lifecycle Owners и уведомляются об изменниях жизненного цикла. 71 00:02:50,509 --> 00:02:52,050 Вот упрощенный взгляд на простой пример кода 72 00:02:52,050 --> 00:02:55,770 для LiveData, который есть также Lifecycle Observer. 73 00:02:55,770 --> 00:02:58,890 Эти методы аннотируются с @OnLifecycleEvent 74 00:02:58,890 --> 00:03:00,970 для заботы об инициализации и остановке, когда 75 00:03:00,970 --> 00:03:04,350 связанный Lifecycle Owner стартует и останавливается. 76 00:03:04,350 --> 00:03:07,530 это позволяет объектам LiveData заботится о своей настройке и 77 00:03:07,530 --> 00:03:09,690 остановке, поэтому UI компоненты наблюдают 78 00:03:09,690 --> 00:03:12,000 LiveData, и LiveData компоненты 79 00:03:12,000 --> 00:03:13,890 наблюдатели Lifecycle Owners. 80 00:03:13,890 --> 00:03:16,380 В качестве заметки для всех вас, разработчики библиотек Android, 81 00:03:16,380 --> 00:03:19,350 вы можете использовать такое же наблюдение за жизненным циклом 82 00:03:19,350 --> 00:03:22,350 для ваших функций настроек и завершения работы, для ваших 83 00:03:22,350 --> 00:03:24,240 собственных библиотек. 84 00:03:24,240 --> 00:03:26,559 Теперь, у вас есть еще одна проблема для решения. 85 00:03:26,559 --> 00:03:29,100 Поскольку ваше приложение используется оно будет в разных состояниях 86 00:03:29,100 --> 00:03:32,070 в onDestroy и onResume, onStart и onStop. 87 00:03:32,070 --> 00:03:34,800 Мы не хотим привязывать LiveData к жизненному циклу 88 00:03:34,800 --> 00:03:36,660 Activity, потому что это вызывает много 89 00:03:36,660 --> 00:03:39,830 случаев не необходимого переиспользования кода. 90 00:03:39,830 --> 00:03:41,910 Примером этого является ваш запрос к базе данных, 91 00:03:41,910 --> 00:03:44,820 каждый раз когда вы поворачиваете телефон. 92 00:03:44,820 --> 00:03:46,300 Итак, что же вам делать? 93 00:03:46,300 --> 00:03:48,750 Хорошо, вы кладете ваш LiveData и другие данные 94 00:03:48,750 --> 00:03:52,230 ассоциированные с UI во ViewModel. 95 00:03:52,230 --> 00:03:55,650 ViewModels это объекты, которые доставляют данные для UI компонентов 96 00:03:55,650 --> 00:03:57,750 и не зависят от изменений конфигураций устройства. 97 00:03:57,750 --> 00:04:01,500 для создания объекта ViewModel, вы наследуетесь от класса ViewModel. 98 00:04:01,500 --> 00:04:03,450 Вы кладете все необходимые данные 99 00:04:03,450 --> 00:04:06,030 для UI вашего Activity во ViewModel. 100 00:04:06,030 --> 00:04:08,850 И с тех пор как вы храните ваши UI-данные во ViewModel, 101 00:04:08,850 --> 00:04:10,590 ваше приложение не будет запрашивать базу данных 102 00:04:10,590 --> 00:04:13,860 A если ваша Activity пересоздана или изменилась конфигурация. 103 00:04:13,860 --> 00:04:16,140 Затем, когда вы создаете ваши Activity или Fragment, 104 00:04:16,140 --> 00:04:18,660 вы можете получить ссылку на ViewModel и использовать его. 105 00:04:18,660 --> 00:04:19,680 Вот и все! 106 00:04:19,680 --> 00:04:21,269 Когда вы впервые получаете ViewModel, 107 00:04:21,269 --> 00:04:23,160 он создается для вашей Activity. 108 00:04:23,160 --> 00:04:24,840 Когда вы снова запрашиваете ViewModel, 109 00:04:24,840 --> 00:04:27,000 ваша Activity получает оригинальную ViewModel 110 00:04:27,000 --> 00:04:28,980 с данными для UI из кеша, так что никаких бесполезных 111 00:04:28,980 --> 00:04:31,410 запросов к базе данных. 112 00:04:31,410 --> 00:04:34,290 Подводя всему итог: новая архитектура блестяща, 113 00:04:34,290 --> 00:04:37,140 мы поговорили о Room, которая является object mapping 114 00:04:37,140 --> 00:04:40,350 library для SQLite, LiveData, который предупреждает вас 115 00:04:40,350 --> 00:04:43,080 если данные изменились, и вы можете обновить ваш IU, 116 00:04:43,080 --> 00:04:45,200 и, что важно, он хорошо работает с Room, 117 00:04:45,200 --> 00:04:47,070 так что вы легко сможете обноовить ваш UI, когда 118 00:04:47,070 --> 00:04:48,820 данные из базы изменились. 119 00:04:48,820 --> 00:04:51,480 Мы также поговорили о Lifecycle Observers и Owners, 120 00:04:51,480 --> 00:04:55,020 которые позволяют не-UI объектам наблюдать за событиями жизненного цикла. 121 00:04:55,020 --> 00:04:57,150 И наконец, мы поговорили о ViewModels, которые 122 00:04:57,150 --> 00:04:58,770 предоставляют вам объекты с данными, которые 123 00:04:58,770 --> 00:05:00,890 сохраняются при изменениях конфигураций. 124 00:05:00,890 --> 00:05:03,710 В целом они составляют набор архитектурных компонентов 125 00:05:03,710 --> 00:05:07,190 для написания модульных, тестируемых, и надежных Android-приложений. 126 00:05:07,190 --> 00:05:08,660 Вы можете, где необходимо, использовать их вместе, 127 00:05:08,660 --> 00:05:10,700 или использовать только то, что вам нужно. 128 00:05:10,700 --> 00:05:12,530 Но это только верхушка айзберга. 129 00:05:12,530 --> 00:05:14,720 Фактически, более функциональное Android-приложение 130 00:05:14,720 --> 00:05:16,310 может выглядеть так. 131 00:05:16,310 --> 00:05:19,150 Для детального изучения, как все работает вместе, 132 00:05:19,150 --> 00:05:20,900 и для понимания этих компонентов, ознакомтесь 133 00:05:20,900 --> 00:05:23,174 со ссылками под этим видео. 134 00:05:23,174 --> 00:05:24,590 Чтобы перейти прямо к коду и начать работу 135 00:05:24,590 --> 00:05:26,090 с этими компонентами, вы можете перейти, 136 00:05:26,090 --> 00:05:27,840 к codelabs и примерам для жизненного цикла 137 00:05:27,840 --> 00:05:29,500 и поддержки сохранности данных. 138 00:05:29,500 --> 00:05:32,180 Хорошего проектирования, и как всегда, не забывайте подписываться. 139 00:05:32,180 --> 00:05:34,330 [ИГРАЕТ МУЗЫКА] 140 00:05:34,330 --> 00:00:00,000

01 09 2017