
English: 
[MUSIC PLAYING]
LYLA FUJIWARA: OK, so hi.
My name is Lyla,
and you are here
at the Architecture
Components Training,
so hopefully you're
in the right place.
As I said, my name is Lyla,
and I'm an Android Developer
Advocate.
And today, you are
going to make possibly
your first full app with
the Android Architecture
Components, and you're going
to do that from scratch.
So let's get started.
But in case you don't know what
Architecture Components are,
I'm going to talk a
little bit about that
and just introduce that to you.
So architecture components are
a growing set of libraries.
There will be more
of them coming out,
and they are meant for
creating Android apps.
And the whole point
of these libraries
is to simplify things
that might have
been a little bit challenging
with Android development.
The Android team decided
to create these libraries
by getting feedback from
you all-- the developers--

Hindi: 
नमस्ते, मैं लैला हूँ, और आप उपस्थित हैं
आर्किटेक्चर घटक प्रशिक्षण में.
आशा है आप सही जगह पहुँचे हैं.
जैसा कि मैंने कहा, मैं लैला हूँ 
और एक Android डेवेलपर एडवोकेट हूँ.
और आज हम कोशिश करेंगे
Andriod आर्किटेक्चर घटकों
द्वारा शुरुआत से आपकी एक पूरी ऐप बनाने की.
शुरूआत करते हैं.
यदि आपको आर्किटेक्चर घटक की जानकारी न हो
तो मैं पहले उसके बारे में बताऊँगी.
आर्किटेक्चर घटक लाइब्रेरी का 
बढ़ता हुआ सेट होती है.
आगे और भी आएँगे, और उनका प्रयोग 
Android ऐप बनाने में होगा.
इन लाइब्रेरियों का उद्देश्य 
चीज़ों को सरल बनाना है
जो Android डेवलपमेंट के साथ 
थोड़े चुनौती पूर्ण थे.
Andriod टीम ने इन लाइब्रेरीज का निर्माण 
आप सभी डेवेलपर्स के
फ़ीडबैक के आधार पर किया है...

English: 
and asking sort of what
slowed down your development.
So more specifically, and
from that information,
they started with
two libraries--
a library for
persistence on Android
and a library for Lifecycles
on Android and making
Lifecycle management easier.
So the first one is Room, which
you've hopefully heard of,
and the second one is
the Lifecycle library.
And both of these libraries
reached 1.0 stable in November,
so they are production ready and
you can use them in your apps
safely.
Now, these libraries
were built in a way where
they could be used
alone, or they
could work together just fine.
So if you're only
looking for a solution
to make SQLite databases, you
could easily use Room alone,
without having to use the
other libraries, if you want.
But they're also
designed in a way
to really work well
together, which
is what I'm going to mostly
be talking about today.
I should also
mention that there is
a third library,
which is in alpha,
called the Paging library.
You should definitely check
this out and give myself
or any of the other
Developer Android Advocates
feedback about it.

Hindi: 
...किन कारणों से डेवेलपमेंट धीमा होता है, 
के जवाब के आधार पर.
इसलिए विशेषकर उस जानकारी के आधार पर,
उन्होंने दो लाइब्रेरीज पर काम शुरू...
एक लाइब्रेरी Android पर दृढ़ता के लिए
और दूसरी Android Lifecycle तथा 
Lifecycle प्रबंधन को सरल बनाने हेतु.
पहली है Room, 
जिसके बारे में शायद अपने सुना होगा,
और दूसरी है Lifecycle लाइब्रेरी.
ये दोनों ही लाइब्रेरीज 1.0 stable पर 
पहुँच चूँकि हैं,
इनका उत्पादन भी तैयार है 
इसलिए ऐप में उपयोग के लिए सुरक्षित हैं.
इनका उपयोग एकल या संयुक्त रूप से 
किया जा सकता है.
तो यदि आपको SQLite डेटाबेस पर 
काम कर रहे हैं, तो Room का उपयोग
बिना किसी अन्य लाइब्रेरी के उपयोग के 
कर सकते हैं.
उनका निर्माण ऐसे किया गया है कि 
संयुक्त रूप से भी प्रयोग कर सकते हैं,
जिसके बारे में हम आज 
मुख्य रूप से बात करेंगे.
इनके अलावा तीसरी लाइब्रेरी भी होती है 
जो अल्फा में स्थित होती है,
उसे Paging लाइब्रेरी कहते है.
आप इसे अवश्य ही देखें और मुझे
या अन्य डेवेलपर Android एडवोकेट 
को फ़ीडबैक दें.

Hindi: 
इसका उद्देश्य धीरे लोड होने वाले 
विशाल डेटा सेट को आसान बनाना है.
आर्किटेक्चर घटक का एक विशेष भाग है नवीन 
दस्तावेज़ीकरण.
developer.android.com पर अब 
एक गाइड उपलब्ध है जो Android ऐप को
उपयोग करने के तरीके को समझाती है.
यदि पूर्व से ही कोई आर्किटेक्चरल तरीका 
प्रयोग कर रहे हैं तो उसी को जारी रखें.
लेकिन, यदि आपको यह नया तरीका पसंद आए 
और Android ऐप को आर्किटेक्ट करने का
उन्नत तरीका सीखना चाहें, 
तो संपूर्ण गाइड मौजूद है,
आज हम इसी आर्किटेकचर का प्रयोग करेंगे.
तो आज आप क्या बनाएँगे?
आज हम एक सरल ऐप बनाएँगे 
जो शब्दों की सूची दर्शाती है.
हालाँकि, यह एक सरल ऐप है, आप कई 
आर्किटेकचर घटकों का प्रयोग देखेंगे,
जिससे आप बहुत प्रबल कार्य कर सकेंगे.
अगले एक घंटे में आप SQLite डेटाबेस का 
निर्माण करेंगे, जिसमें सभी सामग्री
SQLite डेटाबेस के 
रीसायकलर व्यू में दर्शाएँगे.

English: 
And its purpose is to simplify
lazily loading large data
sets for you.
So another big part of
Architecture Components
is the new documentation.
On developer.android.com,
there's
actually a guide
now that describes
one way which you can properly
architect an Android App.
If you are happily using
an architecture pattern,
please continue to do that.
But if this might be
new to you and you're
interested in learning
more about one scalable way
to architect Android apps,
there's a whole guide on it,
and that's actually
the architecture
that we're going to
be following today.
So what are you
going to make today?
We are going to make
this very simple app that
displays a list of words.
But even though this
is a very simple app,
you're going to see a lot of
the different Architecture
Components in practice,
and it's going
to do some powerful
things for you.
So in the next
hour or so, you're
going to be building
a SQLite database,
you're going to
be displaying all
of the content in that SQLite
database in a recyclerview.

English: 
You're going have the
ability to insert or add
new words to that database.
And finally, you're
going to create
this in a way that uses a
reactive UI, which means,
in other words, the UI will
be automatically kept in sync
with the database, which is, one
of the powerful things you can
do about that connection between
Room and the Lifecycle library.
So let's go ahead
and take a look
at what the Guide
to App Architecture
says about app
architecture and how we
might architect an Android app.
So one of the big
principles of the guide
is really encouraging
you to have
a separation of responsibilities
for each of your classes.
So I'm going to go through
each of the classes
and talk about what
their responsibility.
So the first class up
there on the screen
is the UI controller,
and that's just
a fancy name for an
activity or a fragment.
Now, the responsibility
of the UI controller
is to display data.
So basically, it's telling views
what to draw to the screen.
Another responsibility
that it has

Hindi: 
इससे आप डेटाबेस में नए शब्द जोड़ 
या डाल पाएँगे.
और अंत में, आप इसे कुछ इस तरह बनाएँगे कि 
यह प्रतिक्रियाशील UI का प्रयोग करेगा,
अर्थात, UI स्वयं डेटाबेस के साथ सिंक 
बनाए रखेगा, यह बहुत प्रबल कार्य होगा,
जो आप कर सकेंगे Room 
और Lifecycle लाइब्रेरी के कनेक्शन के साथ.
अब एक नज़र ऐप आर्किटेकचर गाइड पर डालते हैं
और देखते हैं ऐप आर्किटेकचर पर क्या कहता है
और हम एक Android ऐप को किस तरह
आर्किटेक्ट कर सकते हैं.
गाइड का एक महत्त्वपूर्ण सिद्धांत, 
आपको प्रत्येक श्रेणी की जिम्मेदारियों को
पृथक रखने को प्रेरित करता है.
मैं प्रत्येक श्रेणी पर बात करुँगी 
और उनकी जिम्मेदारियाँ बताऊँगी.
स्क्रीन पर पहली श्रेणी है UI कंट्रोलर,
यह गतिवधि या टुकड़े का अनोखा नाम है.
UI कंट्रोलर का काम है 
डाटा को डिस्प्ले करना.
यह देखने वाले को बताता है कि 
स्क्रीन पर क्या लेकर आना है.

English: 
is capturing things
like user interactions.
So obviously, your
activity is the one
that knows if a user
clicks a button.
So that is, of course, a
responsibility that it has.
But as soon as it gets
that button click, instead
of processing itself, it
will pass on that information
to a new class,
called the ViewModel.
The ViewModel will also
contain another new class
I'll be talking about,
called LiveData.
And I'm going to get into
those much more later.
They're part of the
Lifecycle library.
But for now, what
you should know
is that the responsibility
of the ViewModel class
is to hold all of
the UI data that is
needed for your UI controller.
So the ViewModel will then
be communicating with a class
known as the Repository.
Now, creating a Repository
class is a convention
and it's a suggested
best practice,
but it's not actually
part of the libraries.
It's not a new
Architecture Component.
It's just a best practice.
And simply put, the
Repository class
contains the API through
which you will get access

Hindi: 
इसका दूसरा काम है कैप्चर करना, 
जैसे की यूजर इंटरेक्शन को.
तो आपकी स्वाभाविक गतिविधि होगी, 
जानना कि यूजर ने बटन क्लिक किया या नहीं.
तो यह भी इसकी एक जिम्मेदारी है.
जैसे ही बटन क्लिक होगा, 
यह खुद काम नहीं करके
जानकारी को नई श्रेणी 
ViewModel को पहुँचाएगा.
ViewModel में एक और श्रेणी होगी, LiveData.
जिसके बारे में बाद में बताऊँगी.
वे Lifecycle लाइब्रेरी का एक हिस्सा हैं.
अभी आपको ViewModel श्रेणी की जिम्मेदारी की
जानकारी होनी चाहिए,
जो कि UI कंट्रोलर के लिए आवश्यक 
UI डाटा को सहेजे रखना है.
फिर ViewModel, Repository नामक एक श्रेणी
के साथ संपर्क करता है.
Repository, बनाना एक प्रथा है, 
जिसे उत्तम अभ्यास मन गया है,
परन्तु वास्तव में यह लाइब्रेरी का 
एक भाग नहीं होता है.
यह एक नया आर्किटेक्चर घटक नहीं है.
यह सिर्फ एक उत्तम प्रचलन है.
सरल शब्दों में कहें तो Repository 
श्रेणी में API होता है

English: 
to all of the app's data.
And in this case, our sort of
data layer is pretty simple.
We're just going to have a
SQLite database, which you're
going to build using Room.
And Room manages all of the
local persistence in the SQLite
database.
Now, Room is a little
bit more complicated
than just one class.
It contains a bunch
of different classes
that work together, including
entities, a DAO, and a database
class.
And it's built on top of SQLite,
as I've mentioned a few times,
and we're going to get
into those details very,
very shortly.
So another core principle
that I want to point out-- so
we have separation of
responsibilities, but we also
have the idea that the classes
only reference the class
directly below them.
So what I mean is for your UI
controller or your activity,
that class is only going to have
a reference to the ViewModel.
The ViewModel, though,
will not have a reference
back up to the activity.
And in addition, the
activity won't reference

Hindi: 
जिससे ऐप के सम्पूर्ण डेटा का 
एक्सेस मिलता है.
यहाँ पर डेटा परत बहुत सरल है.
हम सिर्फ SQLite डेटाबेस रखेंगे, 
जिसका निर्माण Room की मदद से किया जाएगा.
Room SQLite डेटाबेस की स्थानीय 
जड़ता को संभालता है.
Room एक श्रेणी से कहीं अधिक जटिल है.
इसके अंतर्गत विभिन्न श्रेणियाँ काम 
करती हैं जिनमें DAO, डेटाबेस क्लास
और एंटिटी शामिल हैं.
जैसा की मैंने कहा, 
यह SQLite के ऊपर बना होता है
और हम जल्दी ही उस विवरण को जानेंगे.
मैं एक और कोर सिद्धांत की ओर 
ध्यान केंद्रित करुँगी...
जिम्मेदारियों का विभाजन, 
हम जानते है की श्रेणियाँ अगली
श्रेणियों का सिर्फ सन्दर्भ मात्र देती हैं.
अर्थात, UI कंट्रोलर या गतिविधि श्रेणी
सिर्फ ViewModel का एक सन्दर्भ होगी.
लेकिन ViewModel, पिछली किसी भी 
गतिविधि का कोई सन्दर्भ नहीं देगा.
साथ ही गतिविधि किसी भी Repository 
या डेटाबेस का सन्दर्भ नहीं देगा.

Hindi: 
इस सख्त नियम से आप गतिविधि से डेटाबेस 
या आर्किटेक्चर के विभिन्न भागों का सन्दर्भ
नहीं देगा, जिससे सुनिश्चित होगा कि 
सभी कुछ मॉडुलर रहे
और आपकी ऐप निर्भरता की उलझन से दूर रहे.
इसका अर्थ यह भी है कि यदि बाद में कभी 
आप अपने ऐप में कुछ बदलाव करना चाहें...
जैसे Room डेटाबेस को किसी और 
चीज़ से बदलना...
तो आसानी से हो जाए, 
आपको बस Repository में
सन्दर्भ बदलने होंगे ना की पूरा ऐप.
इससे टेस्टबिलिटी भी बढ़ेगी.
कभी कभी आप कोई जानकारी इस डायग्राम के
निचले स्तर से ऊपर की ओर भेजना चाहेंगे.
उदाहरण की लिए, 
अगर डेटाबेस का डेटा बदलता है
तो आप उसे UI को सूचित करना चाहेंगे.
लेकिन डेटाबेस को इसकी कोई जानकारी 
नहीं होगी, तो इसे कैसे किया जाए?
इसके लिए आब्जर्वर पैटर्न का उपयोग करेंगे,
विशेषकर LiveData का,
जिस पर हम बाद में विस्तार में बात करेंगे.

English: 
the repository or the database.
This sort of strict rule of
avoiding strong references
from the activity
to the database
or in different parts
of your architecture
makes sure that you
keep things modular
and that your app doesn't
become a tangle of dependencies.
And what this means is
that if, at a later point,
you want to rewrite a
portion of your app--
say, you want to replace
the Room database
with something else--
you can easily do that,
and you would only
need to change references
in the Repository
and not your entire app to
be able to do that update.
It also makes things
more testable.
So in some cases,
you're going to want
to be able to communicate
information back from a lower
level on this diagram back up.
For example, if some data
changes in your database,
you're going to want to be
able to communicate that
back up to the UI.
But the database doesn't
know about the activity,
so how do we do that?
Well, you will be using
the observer pattern,
and more specifically,
you will be
using LiveData,
which I'm also going
to talk about more, later.

Hindi: 
पूर्व में, शायद आपने कॉलबॉक्स का 
प्रयोग किया होगा,
पर LiveData और ऑब्जरवेशन ने 
उसकी जगह ले ली है.
अब आपको ऐप आर्किटेक्चर गाइड की 
ऊपरी जानकरी हो गई है,
अब इसे करके देखेंगे कि 
वर्ड ऍप में कैसे काम करेगी.
आपने सभी नामों को श्रेणियों में तब्दील
कर दिया है, जिनका निर्माण आप करेंगे.
साथ ही, आप एक नई श्रेणी न्यू वर्ड 
एक्टिविटी का निर्माण भी करेंगे,
इसका उद्देश्य उस टेक्स्ट को एडिट करना है 
जहाँ आप नए शब्द डालेंगे.
आप इन शब्दों को recylerview में 
दर्शाएँगे इसलिए आपको recylerview के लिए
एक एडाप्टर की आवश्यकता होगी.
शायद आपको इसकी जानकारी पहले से होगी.
तो यह इसकी सामान्य संरचना थी.
अब आगे बढ़ते हुए नीचे से ऊपर की ओर जाएँगे 
सभी कॉन्सेप्ट्स को समझते हुए.
शुरुआत करते हैं Room से.
Room, SQLite की 
ऑब्जेक्ट मैपिंग लाइब्रेरी है,
और यह ऐप के लिए स्थानीय डेटा 
की जड़ता को संभालता है.

English: 
In the past, you might
have used callbacks,
but LiveData and observation
will replace that.
So now that you have
a general idea of what
the Guide to App
Architecture's architecture is,
let me show you what
that's actually going
to look like for your Word app.
So now we've
transformed those names
into the names of the classes
that you will actually
be creating.
In addition, you're going to
create a class called, New Word
Activity, and the whole point of
that class is just to edit text
where you enter in new words.
Also, you're displaying these
words in a recyclerview,
so you're going to
need to make an adapter
for that recyclerview.
But hopefully, this stuff
is pretty familiar to you,
already.
So that's our general structure.
And we're going to go ahead
and work from the bottom
back up with all the
concepts along the way.
So let's go ahead and
start off with Room.
So Room is a SQLite
object mapping library,
and it takes care of local
data persistence for an app.
And Room has a lot of advantages
over using the framework

English: 
classes, and you'll actually
notice in our documentation,
we're switching
over to Room instead
of talking about the
framework SQLite classes.
So, for example, instead of
using SQLite over Helper,
use Room, and it will
make sure that you
write a lot less boilerplate.
And one of the ways
that it does this
is that it maps database rows
to objects, and vice versa.
So you don't have to
use intermediate values
like cursors or content values.
You can get rid of all
of those for your app.
So that's cool.
Room also does a handy thing
where it validates your SQLite
queries at compile time.
So it actually won't let
you compile invalid SQL.
And it will also give you
a helpful error message
so that if you wrote
your SQL incorrectly,
you'll know how to fix it.
Finally, Room has support
to work well together
with LiveData and RxJava
for that observability,
and I'll be talking
about that later.
So the fact that you don't have
to write a lot of boilerplate
is because Room generates
a lot of code for you,
and it does this
using annotations.

Hindi: 
फ्रेमवर्क श्रेणी के बनाम Room के 
कई फायदे है,
आप डॉक्यूमेंटशन में देखेंगे कि 
हम फ्रेमवर्क SQLite श्रेणी
की जगह Room की बात कर रहे हैं.
इसलिए, Helper की जगह SQLite प्रयोग
करने के बजाय Room का उपयोग करें,
उससे बॉयलरप्लेट पर कम से कम लिखना पड़ेगा.
ऐसा करने का एक तरीका है कि यह डेटाबेस 
पंक्ति से ऑब्जेक्ट और विपरीत मैप करता है.
इसलिए आपको इंटरमीडिएट वैल्यू जैसे कर्सर 
या कंटेंट वैल्यू के प्रयोग की ज़रूरत नहीं.
अपनी ऐप के लिए इन सभी से 
छुटकारा पा सकते हैं.
Room एक और सुविधाजनक काम करता है कि वह
सभी SQLite प्रश्नों को 
संकलित काल में मान्य करता है.
इसलिए वह अमान्य SQL को 
संकलित नहीं करने देगा.
और आपको त्रुटि संदेश देकर सूचित करेगा 
यदि आपने गलत SQL लिखा है तो,
ताकि आप उसे ठीक कर सकें.
अंतः, Room में ऑब्ज़र्वेबिलिटी के लिए 
LiveData और RxJava के साथ करने के लिए
आवश्यक सहायक मौजूद है, 
जिस पर बाद में चर्चा करेंगे.
आपको कम से कम बॉयलरप्लेट लिखनी पड़े 
इसलिए Room अनेक कोड,
एनोटेशन की मदद से उत्पन्न करता है.

English: 
So by using annotations and
generating this code for you,
it makes it easy
for Room to create
a simple API for your database.
So let's go ahead and
look at those annotations.
So the first annotation
is the Entity annotations.
The Entity annotation
defines the structure
of a table in your database.
The next annotation
is the DAO annotation,
which stands for
Database Access Object,
and it's an interface that
defines all of the read
and write operations
that your app will need.
And finally, we
have an annotation
called the Database Annotation
that is placed on the database
holder object.
So let's go ahead and
start by taking a deep dive
into the Entity class.
So our data for this
app is very simple.
The only piece of data that
we're storing is a word,
and it is a single string.
So I tried to create
a visual for you here
of what that table looks like.
So it just has one column in
it, and it's for a string word.
That column is the primary key.
The word is the primary key.
And that's about it.

Hindi: 
एनोटेशन और कोड उत्पन्न करने से Room 
आपके डेटाबेस के लिए सरल API निर्मित करेगा.
अब एनोटेशन पर एक नज़र डालते हैं.
पहला एनोटेशन है एंटिटी एनोटेशन.
एंटिटी एनोटेशन आपके डेटाबेस के 
टेबल की संरचना को परिभाषित करता है.
अगला एनोटेशन है DAO एनोटेशन, 
जिसका अर्थ है डेटाबेस एक्सेस ऑब्जेक्ट,
यह वह इंटरफ़ेस है जो ऐप के 
पठन एवं लेखन संचालन को परिभाषित करता है.
और आखरी एनोटेशन है डेटाबेस एनोटेशन, 
जो डेटाबेस होल्डर ऑब्जेक्ट पर स्थित होगा.
अब हम एंटिटी श्रेणी को विस्तार से जानेंगे.
इस ऐप के लिए डाटा बहुत सरल है.
यहाँ हम सिर्फ शब्दों को स्टोर कर रहे हैं,
जो एक ही स्ट्रिंग में है.
टेबल कैसे दिखता है उसका मैंने यहाँ 
एक दृश्य निर्माण करने की कोशिश की है.
इस टेबल में केवल एक कॉलम है 
जिसमें एक स्ट्रिंग शब्द है.
कॉलम का नाम प्राइमरी की है.
वह शब्द है प्राइमरी की.
और बस इतना ही है.

English: 
So what does that look like?
So here is a plain, old
object for the Word class
that I just described to you.
And now it's an Entity class.
That was pretty simple.
We just added a
couple annotations.
So the first annotation
that I want to point out
is the Entity annotation.
All entities in your app
need this Entity annotation
to make it an Entity.
And again, that
says this is going
to define the schema for
a table in my database.
Now, I've also added an
optional property here,
and that is to name the
database table, Word Table.
Now, this is optional
because if you didn't use it,
it would just name the database
table the name of the class.
So it would have named
it Word, but now it's
Word Table instead.
Now, when you mark a
class as an Entity,
it goes to all of your
fields and it says,
hey, these fields are going to
be the columns of my database
table.
So in this case, we
only have one field,
which is that Word
field, so it's only
going to have one column.
And it takes the fact
that the type is string,

Hindi: 
तो, यह कैसा दिखता है?
यह है वर्ड श्रेणी के लिए सरल 
ओल्ड ऑब्जेक्ट, जो अभी अापने समझा.
अब वह एंटिटी श्रेणी है.
यह बहुत आसान था.
हमने बस कुछ एनोटेशन जोड़े.
पहला एनोटेशन जिस पर ध्यान केंद्रित 
करना चाहूँगी वह है एंटिटी एनोटेशन.
ऐप की सभी इंटिट्यों को एंटिटी एनोटेशन 
की ज़रूरत है उन्हें एंटिटी बनाने के लिए.
और इससे यह भी स्पष्ट है कि यह डेटाबेस के 
टेबल की योजना को परिभाषित करता है.
मैंने इसमें एक वैकल्पिक गुण जोड़ा है,
डेटाबेस टेबल का नाम, वर्ड टेबल.
यह वैकल्पिक है क्योंकि यदि आप नाम ना दें,
यह डेटाबेस टेबल को श्रेणी का नाम दे देगा.
तो इसका नाम हुआ होता वर्ड, 
पर अब वह वर्ड टेबल है.
जब आप श्रेणी को एंटिटी चिन्हित करते हैं, 
तो वह सभी क्षेत्रों पर लागू होता है,
और उसका अर्थ होता है कि 
यह क्षेत्र डेटाबेस टेबल के कॉलम होंगे.
यहाँ पर केवल एक क्षेत्र होगा, वर्ड,
तो कॉलम भी एक होगा.
यह इस तथ्य को ध्यान में रखते हुए कि 
टाइप स्ट्रिंग है,

English: 
and it makes the database of
the appropriate type there, too.
Now, if you have an object or
a value in your Entity class
that you do not want to be a
column in the table-- let's
say, you have a bitmap
image or something--
you can mark it with
the @ignore annotation,
and that will not become a
column in your database table.
So then we wanted to showcase
a couple of other annotations
off.
The primary key
annotation is important
because every single Entity
needs exactly one primary key.
Because we only
have one field, it's
going to be the primary key.
Here are a couple other sort
of optional annotations.
The not null annotation
says, hey, this field
is never going to
contain a null value.
And the column info
is also basically
similar to the table name
value that you have up there.
It says that I want to
name this column "Word,"
and if we didn't include
this optional annotation,
it would just name
it, MWord, which is
the name of the variable there.

Hindi: 
वहाँ टाइप के लिए उपयुक्त डेटाबेस बनाता है.
अब यदि आपके पास एंटिटी श्रेणी में 
कोई ऑब्जेक्ट या वैल्यू हो
जिसे टेबल के कॉलम में रखना नहीं चाहते...
जैसे बिटमैप इमेज...
उसे @ignore एनोटेशन से चिन्हित कर सकते हैं
जिससे वह डेटाबेस टेबल का कॉलम नहीं बनेगा.
फिर जब आप कुछ अन्य एनोटेशन 
टेबल में दिखाना चाहें.
तो प्राइमरी की 
एनोटेशन महत्त्वपूर्ण होती है
क्योंकि प्रत्येक एंटिटी को एक प्राइमरी की
की आवश्यकता होती है.
यहाँ पर केवल एक क्षेत्र है,
इसलिए वही प्राइमरी की होगी.
ये हैं कुछ वैकल्पिक एनोटेशन.
नॉट नल एनोटेशन अर्थात,
इस क्षेत्र में कभी भी नल वैल्यू नहीं होगी.
तथा कॉलम जानकारी भी टेबल के नाम के वैल्यू 
की तरह होगी जो ऊपर बनाया गया है.
यह बताता है कि कॉलम का नाम 'वर्ड' है 
और यदि हम वैकल्पिक एनोटेशन ना जोड़े,
तो इसका नाम MWord रखा जायेगा, 
जो यहाँ एक वेरिएबल का नाम है.

Hindi: 
यह सुनिश्चित करने के लिए कि 
एंटीटियाँ सुचारु रूप से काम करें,
Room को पठन एवं लेखन का 
एक्सेस मिलना ज़रूरी है.
ऐसा तीन तरीकों से कर सकते हैं.
पहला तरीका है माय फील्ड इस प्राइवेट.
इसे एक कन्स्ट्रक्टर प्रदान करुँगी,
जिसमें क्षेत्र का सटीक नाम है
पैरामीटर के तौर पर, 
और साथ ही एक गेटर भी दूँगी.
यह एक तरीका हुआ करने का.
यदि आप चाहें तो अपने सभी क्षेत्र
पब्लिक कर सकते हैं या कुछ क्षेत्र.
या आप गेटर और सेटर प्रदान करके सकते है.
लेकिन आपको Room को एक्सेस देना होगा.
क्योंकि इसके बिना वह टेबल का निर्माण
नहीं कर सकेगा.
एंटीटियों को परिभाषित करेने के बाद, 
आप DAO ऑब्जेक्ट निर्मित कर सकते हैं.
DAO ऑब्जेक्ट, आपकी ऐप के लिए आवश्यक 
सभी डेटाबेस ऑपरेशन्स को परिभाषित करता है.
अब उन पर बात करते हैं.
यहाँ शब्दों की एक सूची है.
हमें उन्हें डेटाबेस से प्राप्त करने का
कोई तरीका ढूँढना है.

English: 
So another important
thing to make sure
that your Entities
work properly is
that Room needs to be able
to have read and write access
to all of them.
And you can accomplish this in
basically three different ways.
The first way, which
I'm showing here,
is that my field is private.
But I provide a constructor to
it, which has the exact field
name as a parameter, and then
I also provide a getter for it.
So that's one way
that you could do it.
You could also make all of your
fields public, if you wanted,
or some of your fields public.
Or you could provide
getters and setters,
and then you don't have to
worry about the constructor.
But you have to allow Room
to have access to these.
Otherwise, it can't do
all the table creation
that it does for you.
All right.
Now once you have
your entities defined,
you could go on to
building the DAO object.
So again, the DAO object defines
all of the database operations
that you need for your app.
So let's talk about
what those are.
Well, here we're
showing a list of words.
So we probably
need some way to be

English: 
able to get that list of
words from the database.
We're also inserting
a single word here,
so we probably need a way
to insert a single word.
And then finally, it's
probably good to have a method
to sort of flush
out our database
and delete all of the words.
And put very simply, that's
all the functionality
right there in our DAO.
Importantly, at the
top of your DAO,
you need to mark it with
the @DAO annotation.
And the class or interface
that you have either
needs to be an abstract class
or interface so that Room
can go ahead and generate
and provide the full method
implementations for you.
Now there are three convenience
annotations that you can use--
Insert, Delete, and Update.
And these create the commands
to insert, delete, and update
objects, like the one
that I'm showing you here
for inserting a single word.
And this actually shows off
Room's powerful object mapping
capabilities.
So in this case,
I'm simply passing
it an object as a
parameter, and then Room's
taking care of putting
that in my database for me.

Hindi: 
हम यहाँ एक शब्द डाल रहे हैं, 
इसलिए एक शब्द डालने का तरीका चाहिए.
और फिर एक तरीका सभी शब्दों को 
डेटाबेस से हटाने का, डिलीट करने का.
सरल शब्दों में, DAO का यही फंक्शन है,
DAO के ऊपर @DAO एनोटेशन 
चिंहित करना महत्त्वपूर्ण है.
और श्रेणी या इंटरफ़ेस अब्स्ट्रक्ट श्रेणी 
या इंटरफ़ेस होना चाहिए ताकि Room निर्मित
और प्रदान कर सके 
पुरे मेथड का इम्प्लीमेंटेशन.
हमारे पास तीन सुविधा एनोटेशन उपयोग के लिए 
उपलब्ध हैं... इंसर्ट, डिलीट और अपडेट.
ये इंसर्ट, डिलीट और अपडेट ऑब्जेक्ट के लिए 
कमांड तैयार करते हैं,
ठीक वैसे जैसे मैं दिखा रही हूँ एक शब्द को 
इंसर्ट करने के लिए.
यह Room की दमदार ऑब्जेक्ट मैपिंग 
काबिलियत को दर्शाता है.
यहाँ, मैं ऑब्जेक्ट को 
पैरामीटर के तौर पर ले रही हूँ,
फिर Room उसे मेरे डेटाबेस में डालेगा.
इसके अलावा कुछ और नहीं करना है.

English: 
I don't need to do
anything besides that.
Similarly, up above, you
can see that I'm saying,
hey, this method is going
to return to me words,
and room is able to do that
conversion for me, as well.
And I can also return a list
of words by just saying, hey,
I want a list, instead
of a single word.
And Room can take care of all
the appropriate conversions
for that object.
So finally, if you need
to make any methods that
are doing reading
from your database
or you have a more
complicated query operation,
you can use the
@query annotation,
and this basically lets you
just write some straight SQL
commands in your DAO.
So one more thing I wanted
to point out about the DAO.
So actually, there's a little
bit of extra functionality.
So we want the
following to be true.
When I add a new word
to the list of words,
I want the database
to automatically tell
the UI that it has updated.
And so, because I
do that, it will

Hindi: 
इसी तरह ऊपर आप देखा सकते हैं कि 
यह तरीका मुझे फिर वर्ड पर ले आएगा,
और Room यह रूपांतरण भी करेगा.
और मैं शब्दों की सूची देकर कह सकती हूँ कि 
मुझे एक नहीं अनेक शब्द सूचीबद्ध करने हैं.
Room ऑब्जेक्ट के लिए 
सभी आवश्यक रूपांतरण करेगा.
अंत में, यदि आपको कोई तरीके चाहिए हो 
जिससे डेटाबेस से पठन हो सके
या कोई जटिल प्रश्न ऑपरेशन हो
तो आप @query operation का प्रयोग करें,
जिससे आप DAO में सीधे 
SQL कमांड लिख सकते हैं.
DAO सम्बंधित एक और बिंदु है पर ध्यान दें.
इसकी और भी फंक्शनलिटी है.
हम चाहते हैं कि निम्न सत्य हो.
जब मैं नया शब्द सूची में जोड़ती हूँ, 
तब चाहती हूँ डेटाबेस अपनेआप
UI को सूचित करे कि वह अपडेट हो गया है.
ऐसा करने से स्पष्ट होगा की UI की स्थिति

Hindi: 
डेटाबेस की स्थिति से साथ सिंक में है,
जो अद्भुत होगा.
तो ऐसा करने के लिए हम Lifecycle लाइब्रेरी
श्रेणी, LiveData का प्रयोग करेंगे,
इसके बारे में विस्तार से बात करेंगे.
मूल आईडिया... 
मूलतः मैंने आपको यह दिखाया था.
जब आप इस मेथड को बुलाएँगे 
वह आपको सूची की तात्कालिक स्थिति बताएगी.
अब अगर मैं एक छोटा सा बदलाव करती हूँ,
कहती हूँ कि LiveData पर 
वापस जाना चाहती हूँ,
तो यह आपको यह ऑब्जेक्ट देगा 
जो शब्द सूची पर ले जाएगा
जो अपनेआप डेटाबेस में बदलाव पर 
अपडेट होता है.
इस पर हम बाद में और बात करेंगे, 
जब UI को डाटा लेयर के साथ जोड़ेंगे.
यह है Room डेटाबेस का आखरी भाग,
यह डेटाबेस होल्डर श्रेणी कहते हैं
जैसा कि पहले बताया था.
इसे @डेटाबेस से एनोटेट किया जाता है 
और इसका अब्स्ट्रक्ट होना चाहिए
और श्रेणी Room डेटाबेस को 
विस्तृत करना चाहिए.
यह श्रेणी डेटाबेस टेबल का निर्माण करती है

English: 
mean that I can always
keep the UI state exactly
in sync with the database's
state, which is great.
So to do that, we're going to
go ahead and use the Lifecycle
library class called
LiveData, and I'm
going to talk much more
in-depth about this.
But the basic idea is--
so here's what I
originally showed you.
When you call this
method, it gets you
the current state of the list.
Now, if I make this tiny
little change and just say,
hey, I want you to
return to LiveData back,
instead, it's getting
you this object
that returns a list of words
that automatically updates
itself when the
database changes.
And again, I promise
I'll talk to you
more about this later, when
we hook up the UI to the data
layer.
So here's the final part
of our Room database,
and it is the
database holder class
that I talk to you about before.
It is annotated with @database,
and very importantly, it also
must be abstract and extend
the class Room database.
So this is the class that's
generating your database
tables for you, so
you need to tell it

English: 
about all of the Entities
that you have created
as an attribute, as seen here.
And you also have to
provide an abstract getter
method for the DAO.
So this is the
code that actually
creates that database for you.
It's a builder class for
creating your Room database.
And this code will
either return to you
a link to a new database if
the device doesn't already
have one, or it
will return to you
a connection to a preexisting
database, if one already
exists on the device.
And importantly, I want
to point out this one line
that we chose to add in there.
So in this case,
what I'm saying is,
if the database
schema is updated,
I just want you to wipe out
all of the data on the device.
It's the most simple
way to do a migration,
is to just be like, hey,
forget everything else
and update my schema.
And because this
is a simple app,
I'm not going to
get into migrations,

Hindi: 
इसलिए यहाँ आपको सभी एंटीटियों के बारे में
बताना होगा जो अापने बनाई है, 
एक एट्रीब्यूट के रूप में.
साथ ही DAO के लिए एक अब्स्ट्रक्ट गेटर
मेथड भी देना होगा.
यह वो कोड है जो आपके लिए 
डेटाबेस तैयार करता है.
यह Room डेटाबेस बनाने के लिए
बिल्डर श्रेणी है.
यह कोड आपको एक नए डेटाबेस की लिंक देगा
अगर डिवाइस में पहले से मौजूद ना हो तो
या मौजूद डेटाबेस का कनेक्शन देगा, 
अगर डिवाइस में मौजूद हो तो.
ज़रूरी है कि मैं इस लाइन पर आपका 
ध्यान खींचू जिसे हमने यहाँ जोड़ा है.
यहाँ मैं समझाना चाहती हूँ कि 
यदि डेटाबेस योजना अपडेट होती है,
तो मैं चाहूँती हूँ, आप डिवाइस का 
सारा डाटा मिटा दें.
यह माइग्रेट करने का सबसे आसान तरीका है, 
पुराना सब भूल जाओ और नई योजना अपडेट करो.
यह बहुत सरल ऐप है इसलिए मैं माइग्रेशन पर 
ज्यादा बात नहीं करुँगी,

English: 
but do be aware that
there is a migration class
and there are tons
of options for making
more complicated migrations
of this very simple just flush
and delete everything.
So the next question
you might have is,
OK, you showed me the code
to construct a database
or get a connection
to a database.
Where does this actually live?
Well, creating a database is
actually a relatively expensive
process, and you normally
don't need multiple instances
of a database.
So the recommended practice
is to actually create
a singleton for your database--
a static variable Singleton,
and ensure that you only
instantiate it once.
So that's the code to do that.
You'll be able to copy
and paste in the Codelab,
so you don't need to take
notes on all of this right now.
But one thing that I
did want to point out
is that down here,
that's that code
that I showed you
earlier, which actually
creates the connection.
So that's pretty
much what you need
to know about Room to complete
the steps in the Codelab.
So you will complete the steps
now to make that database.
They are steps two to seven.
There is a short link
for you, so that you

Hindi: 
लेकिन याद रखिए कि एक माइग्रेशन श्रेणी है 
जिसमें कई विकल्प है जटिल माइग्रेशन को
आसानी से साफ करने और मिटाने के.
अगला सवाल आपके दिमाग में होगा कि 
डेटाबेस बनाने के कोड या डेटाबेस कनेक्शन के
बारे में बताया, 
पर वास्तव में यह कहाँ होता है?
डेटाबेस निर्मित करना एक महंगी प्रक्रिया है
आमतौर पर अधिक डेटाबेस उदाहरणों की
ज़रूरत नहीं होती.
आमतौर पर डेटाबेस के लिए 
सिंगलटन निर्मित करने का चलन है...
स्टैटिक वेरिएबल सिंगलटन,
और ध्यान रहे कि उसे सिर्फ एक बार 
ही दर्शाना है.
इसे करने का यही कोड है.
कोडलैब में सब कुछ कॉपी पेस्ट हो जायेगा,
अभी नोट्स लेने की आवश्यकता नहीं है.
यहाँ पर ध्यान दिलाना चाहुँगी, 
यह वही कोड है जो पहले दिखाया था,
जो कनेक्शन निर्मित करता है.
कोडलैब में क्रम पूरे करने के लिए 
Room की कितनी जानकारी पार्यप्त है.
आप डेटाबेस बनाने के लिए 
क्रम को पूरा करेंगे.
यह हैं क्रम दो से सात.

Hindi: 
आपके लिए कोडलैब तक पहुँचने के लिए 
एक संक्षिप्त लिंक है,
क्या सभी टी.ए. हाथ उठाकर हिलाएँगे?
यदि आप चाहें तो पीछे देखें.
वहाँ कुछ टी.ए. उपस्थित हैं.
कोडलैब आप घर पर भी कर सकते हैं, 
यहाँ आने का मुख्य फायदा है
जानकारों की उपस्थिति समस्याऐं 
सुलझाने के लिए.
यदि आपके कुछ सवाल हैं तो 
कृपया हाथ उठाकर पूँछें.
यहाँ हम 20 मिनट के लिए रुकेंगे, 
इस मुद्दे को ध्यान से पढ़े और समझे,
फिर हम कोडलैब में Lifecycle जानेंगे.
अब मैं Room की उन फीचर्स पर बात करुँगी
जिन पर कोडलैब के अंतर्गत बात नहीं हुई.
उन में से एक है आईडी ऑटो जनेरेट
करने की क्षमता, जो बहुत सरल है.
प्राइमरी की के बगल में एनोटेशन एट्रिब्यूट 
ऑटो जनेरेट इस्तमाल कर सकते हैं.

English: 
can get to the Codelab,
and there are-- actually,
can all of the TAs just
raise their hands and wave
around a bit?
And if you want to
look around, you
can see in the back of the room.
We have a of TAs.
You can do this
Codelab at home, so one
of the useful things
about being here
is that you actually
have knowledgeable people
around to help you.
So please, if you
have any questions,
go ahead and raise your hand.
So we're going to be out
20 minutes right now.
Go ahead and get through as
much as you can, and then we'll
start the Lifecycle portion
of the lecture in Codelab.
[MUSIC PLAYING]
So I want to talk about a
few more additional Room
features that weren't covered,
necessarily, in the Codelab,
itself.
So one is the ability
to auto-generate IDs.
So if you want Room to
auto-generate IDs for you,
that's pretty simple.
Right next to your
primary key, you
can just use the annotation
attribute auto-generate.
Set it to True.

Hindi: 
उसे True पर सेट करें.
यह 1 से इन्क्रीमेंट करना शुरु करेगा,
और ऊपर जाएगा जैसे जैसे
आप नए ऑब्जेक्ट निर्मित करेंगे.
Room DAO के मेथड को भी समर्थन करता है
जटिल प्रश्नों के लिए कुछ पैरामीटर के साथ,
जैसे कि आप यहाँ देख सकते हैं 
व्हेअर क्लॉज़ के साथ.
यह प्रश्न उन शब्दों को दिखता है 
जो सबस्ट्रिंग में हैं.
आप देख सकते हैं, वास्तविक प्रश्न में ही,
आप कॉलम का नाम वर्ड उपयोग करते हैं,
फिर जब आप पैरामीटर इस्तमाल करते हैं, 
उसे क्वेरी स्ट्रिंग से रेफेर कर सकते हैं
कोलन को पैरामीटर के सामने लगाकर.
इस तरह आप क्वेरी का उपयोग 
स्ट्रिंग में करते हैं.
आप देख सकते हैं, यहाँ एक पैरामीटर हैं, 
सबस्ट्रिंग,
उसे क्वेरी स्ट्रिंग से रेफेर करुँगी, 
उसके आगे कोलन लगाकर
और उसे पलाइन टेक्स्ट की तरह लिखकर.
अंतः, मैं बताया है कि Room का एक फीचर है
कम्पाइल टाइम चेकिंग.
ये है सक्रिय क्वेरी, पर मान लीजिए 
मैं थकी हुई हूँ और कुछ गलत टाइप करती हूँ,

English: 
It'll start incrementing from
1, and just go up for you
as you create new objects.
Now, Room also
supports DAO methods
with parameters for
more complex queries,
such as the one that you see
here with this where clause.
This query returns words that
start with a given substring.
As you can see, within
the actual query itself,
you just use the
column name as a word,
and then when you're actually
using the parameters,
you can refer to it
in the query string
by putting a colon in front
of the exact parameter name.
And that's how you would
use a query in your string.
So as you can see, we
have a single parameter
called substring here,
and I'm referring
to it in my query string just by
putting a colon in front of it
and writing it as plain text.
So finally, I mentioned that
Room has this cool feature
of Compile Time Checking.
So here is our working
query, but let's say
that I was jet lagged a bit, and
I typed something incorrectly,

English: 
like doored, which is
not a column that exists.
If I do that and
I try to compile,
I'll actually get an error
that looks like this.
And maybe some of you saw
this if you typed something
incorrectly.
But that tells you exactly
what the problem is,
and then you could
go and resolve that
before running into
a runtime error.
So that finishes up
the basics of Room.
There's plenty more to
learn, and I encourage you
to check out our documentation.
But I'm going to talk a little
bit about the Repository class
next.
So we're moving up
in our diagram here.
The Repository
functions as a clean API
for handling all
data operations.
In our app, because our data
back end is pretty simple--
it's just a database--
it's just going to be
communicating with the DAO
and making the database for you.
But in a more complicated
app, the Repository functions
as a mediator between
different data sources
like you might have.
So you might be able to
imagine an example where
you're getting both data
from your network server

Hindi: 
जैसे डोरड, ऐसा कोई कॉलम नहीं है.
यदि मैं उसे कम्पाइल करूँ, 
तो मुझे कैसा दिखने वाला एरर मिलेगा.
शायद आपमें से किसी ने ऐसा एरर देखो हो 
कुछ गलत टाइप करने पर.
पर यह आपको गलती की जानकारी देता है, ताकि 
रन टाइम एरर होने से पहले ही ठीक कर सकें.
इसके साथ Room के बेसिक खत्म होते हैं.
इसमें और भी बहुत कुछ है सीखने की लिए 
और डॉक्यूमेंटेशन पढ़ने को प्रेरित करुँगी.
अब Repository श्रेणी पर बात करेंगे.
हम डायग्राम में ऊपर की ओर बढ़ेंगे.
Repository सभी डाटा ऑपरेशन्स को 
सँभालने के लिए एक API फंक्शन है.
हमारी ऐप में क्योंकि डाटा बैक एन्ड 
बहुत सरल है...
सिर्फ डेटाबेस है... वह DAO से 
संपर्क कर डेटाबेस बनाएगा.
लेकिन अधिक जटिल ऐप में, Repository
एक मध्यस्थ की तरह
आपके विभिन्न डाटा स्त्रोतों के 
साथ काम करता है.
आप एक उदहारण की कल्पना करिए जहाँ आप डाटा
नेटवर्क सर्वर और 
लोकल डाटा कैश से ले रहे हो.

Hindi: 
तथ्य कि नया डाटा सर्वर से लेना है
या लोकल कैश से और कब लेना है...
इन सभी जटिलताएँ Repository में होंगी.
इसका मतलब ये है कि अगर UI कोड को 
डाटा की ज़रूरत है,
तो वह बस कहेगा शब्द सूची दो.
फिर उसे किसी भी जटिलता की चिंता 
नहीं करनी होगी कि, नेटवर्क से लेना है
या लोकल डाटा कैश से या कहीं और से.
यह ऐप में डाटा कहाँ से प्राप्त हो रहा है, 
जैसी जटिलता को छुपा देता है.
Repository के बारे में इतना ही है.
Repository लाइब्रेरी का भाग नहीं है.
यह बस एक उत्तम प्रचलन है.
इसे कोडलैब में जानना ज़रूरी था क्योंकि हम
आर्किटेक्चर का अनुसरण कर रहे हैं.
अब आगे बढ़ते हैं और Lifecycle लाइब्रेरी 
को समझते हैं.
इसमें दो कोर श्रेणियाँ और संकल्पनाएँ हैं 
जिनका प्रत्यक्ष प्रयोग नहीं होगा
पर जानकारी आवश्यक है.
पहला है, अब Lifecycle लाइब्रेरी में 
ऑब्जेक्ट होता है जो Lifecycle का
प्रतिनिधित्व करता है Android में,

English: 
and you're also getting data
from a local data cache.
The logic about whether to
grab new data from the server
or use the local cache data and
when to do additional fetches--
all of that complexity would
be inside of the Repository.
And what this means is that when
your UI code needs some data,
it just says, hey, get
me the list of words.
And it doesn't have to worry
about all the complexity of,
should I get this from
the network or should
I get this from local
data cache or whatever
else you might have there.
So it hides that complexity
of where the data is actually
coming from from the
rest of your app.
And that's actually
it for the Repository.
The Repository isn't
part of the libraries.
Again, it's just
a best practice.
But we're going to have
you do that in this Codelab
because we're following
the architecture.
So let's go ahead and jump
into the Lifecycle library.
So there's a couple of
core classes and concepts
that you're not going
to use directly,
but you should be
generally aware of.
The first of those is that
in the Lifecycle library,
we now have an
actual object that
represents a
Lifecycle in Android,

Hindi: 
जिसे दी Lifecycle या Lifecycle कहते हैं.
उसी तरह Lifecycle owner की एक आईडिया है.
Lifecycle owner एक ऑब्जेक्ट है 
जिसमें Lifecycle होती है.
उदाहरण के लिए एक गतिविधि या खंड.
और 26.1, एक सहायक लाइब्रेरी की तरह,
ऐप कॉम्पैक्ट एक्टिविटी Lifecycle owner है.
चाहें तो, इसमें से आपको 
Lifecycle ऑब्जेक्ट प्राप्त हो सकता है.
और आखिर में 
Lifecycle ऑब्जरवेशन का सिद्धांत.
आप एक Lifecycle आब्जर्वर बना सकते हैं.
यह एक इंटरफ़ेस है Lifecycle को 
ऑब्जर्व करे लिए.
यदि कभी आपको लिस्ट्नेर्स मिलें हो 
या ऐसी सेवाएँ जिनके लिए onStop में
क्लीनअप कोड लिखना पड़ा हो,
तो वो लिस्टनेर और सेवाएँ, क्लीनअप के लिए
Lifecycle ऑब्जरवेशन का उपयोग करती हैं.
इसलिए एक डेवलपर के तौर पर 
आप लाइब्रेरिएस का प्रयोग करते हैं,
पर आपको स्वयं करने की ज़रूरत नहीं है.
यह इस प्रकार की श्रेणियाँ लिखने के लिए है.

English: 
and it's just called the
Lifecycle, or Lifecycle.
Similarly, we have the
idea of a Lifecycle owner.
A Lifecycle owner is an
object that has a Lifecycle.
For example, an
activity or a fragment.
And as a support library,
26.1, app compat activity
is a Lifecycle owner.
So you could actually get
its Lifecycle object from it,
if you'd like.
Finally is the concept
of Lifecycle Observation.
So you can actually make
a Lifecycle Observer.
It's an interface for
observing Lifecycles.
So if you've ever had
listeners or services that
require you to write some
cleanup code in onStop,
those listeners
and services could
be using Lifecycle
Observation to be
doing that clean-up for you.
So you, as a dev that is
using those libraries,
don't have to do it yourself.
So that's something, if you
were writing classes like that.
And you'll also see
an example of how

Hindi: 
इसका उदाहरण हम देखेंगे जब हम Lifecycle
ऑब्जरवेशन करेंगे LiveData पर बात करते समय.
अब आगे बढ़ेंगे और ViewModel पर बात करेंगे.
यदि अापने मेरे द्वारा मटेरियल देखा है 
और उसका प्रयोग किया हो
तो आपको ज्ञात होगा कि ViewModel 
घटकों के लिए UI डाटा प्रदान करता है,
साथ ही कॉन्फ़िगरेशन में बदलाव के 
बाद भी बना रहता है.
कॉन्फ़िगरेशन में बदलाव का सामान्य उदाहरण है
अपने डिवाइस को रोटेट करना या भाषा बदलना.
क्योंकि ViewModel कॉन्फ़िगरेशन के 
बदलाव के बाद भी बना रहता है
इसलिए वह Async टास्क लोडर की 
जगह ले सकता है.
अधिक महत्वपूर्ण बात यह है कि वे 
जिम्मेदारियों के विभाजन को बढ़ावा देते हैं
जिस पर मैंने पहले बात की है.
कई शुरुआती Andriod डेवेलपर्स 
या संभावित मध्यवर्ती Android डेवलपर
पाते है कि वे कई सारे कोड 
अपनी गतिविधि श्रेणी में डालते हैं
और परिणामवश एक बड़ी 
गतिविधि श्रेणी बनाते हैं.
इसलिए यह आर्किटेक्चर सुझाव देता है कि किस

English: 
we do this Lifecycle
observation later
when we talk about LiveData.
So let's go ahead and move
up and talk about ViewModel.
So if you've
watched the material
that I've written and
put out into the world,
you probably know that
ViewModels provide UI data
for components while also
surviving configuration
changes.
A common example of a
configuration change
is rotating your device or
changing languages as well.
So because ViewModels survive
configuration changes,
they can replace
Async Task Loaders.
More importantly,
though, they encourage
you to have this separation
of responsibilities
that I was talking about before.
So one of the comments that
early Android developers
or potentially intermediate
Android developers might find
is that they end up
putting a bunch of code
in their Activity
class, and they end up
with a very bloated
Activity class.
So what this
architecture suggests
for you is how you
might be able to

English: 
divide out that code a little
bit more intelligently.
So in the ViewModel
class, we suggest
that you have all
of your UI data,
and then leave the
activity class,
just to be responsible for
actually drawing that UI data.
So why is that useful for us?
Well, let's go back to a
time before ViewModels,
when you had your
activity instance,
and it contained all of its
variables and UI data, itself.
The thing about
activities is that they
don't live for a very long time
if configuration changes are
happening.
So let's say that the
user rotates the phone.
This means that the activity
instance is destroyed,
and then it's recreated.
Now, the Android
framework is smart,
so it will attempt to
save some UI data for you.
So for example, the
current text in a Text View
is automatically bundled up
for you and on saved instance
state, and it's delivered
to the recreated activity.

Hindi: 
तरह बुद्धिमत्ता के साथ 
कोड का विभाजन किया जाए.
इसके लिए ViewModel में सारा UI डाटा 
गतिविधि श्रेणी में रख कर छोड़ दें,
जिसकी जिम्मेदारी होगी 
UI डाटा प्राप्त करने की.
यह हमारे लिए किस तरह लाभदायक है?
समय में पीछे जाते हैं 
जब ViewModels नहीं थे,
जब एक्टिविटी इंस्टैंस था जिसमें सारा 
UI डाटा और वेरिएबल्स होते थे.
यदि लगातार कॉन्फ़िगरेशन बदलते रहे 
तो एक्टिविटीज लम्बे समय तक नहीं टिकते.
मान लीजिए उपयोगकर्ता फ़ोन घूमता है.
इसका मतलब है 
कि एक्टिविटी इंस्टैंस नष्ट हुआ,
और फिर निर्मित हुआ.
Android फ्रेमवर्क चतुर है, इसलिए वह कुछ 
UI डाटा बचाने की कोशिश करेगा.
मान लीजिए टेक्स्ट व्यू का टेक्स्ट अपनेआप 
जमा होकर सेव्ड इंस्टैंस स्टेट में जाता है,
और पुनर्निर्मित गतिविधि में पहुँचता है.

English: 
But if you have some UI data
which is specific to your app
and is not necessarily
immediately shown
in one of the UI
components, that
won't be automatically
bundled up for you.
So most of you have probably
used unsaved instance state
to save this data,
but it requires
you to do that manual
bundling up, serializing
and deserializing of that
data, which can be annoying.
but if you forget to
do it, you will end up
in this state, where
you have not actually
passed your full UI state on
to the recreated activity,
and that will create
bugs for your end user,
potentially even
crashing the app.
So a simpler way
to do this would
be to use the ViewModel object,
where this is not a problem.
So as you can see
here, my activity data
is no longer in my activity.
I've moved it over
to the ViewModel,
and my activity gets
the data that it
needs to be able to display
itself by communicating
with the ViewModel.
Now, as I said
before, ViewModels
survive rotation or all
configuration changes.
So if a configuration
change happens,
activity still dies and is
recreated, but importantly,

Hindi: 
लेकिन अगर आपके पास कुछ ऐप विशेष UI डाटा है
जो UI घटक में तुरंत दिखाया नहीं गया,
वो अपनेआप जमा नहीं होगा.
आप में से कई लोगों ने इस डाटा को 
सेव करने के लिए अनसेव्ड इंस्टैंस स्टेट का
प्रयोग किया है, पर उसके लिए 
आपको डाटा स्वयं जमा करना,
क्रमबद्ध करना और क्रम तोड़ना पड़ता है, 
जो बहुत कष्टकारी होता है.
लेकिन अगर आप ऐसा करना भूलें तो इस तरह 
की स्थिति में होंगे जहाँ UI स्टेट पार कर
गतिविधि पुनर्निर्मित नहीं हुई है,
जिससे उपयोगकर्ता के लिए बग्स निर्माण होंगे
और ऐप क्रैश होने ही आशंका भी होगी.
इसे करने का एक आसान तरीका है 
ViewModel ऑब्जेक्ट का उपयोग करना
जिसमें ऐसी स्थिति निर्माण नहीं होती.
जैसा कि आप देख सकते हैं, गतिविधि डाटा, 
अब मेरी गतिविधि में नहीं है.
मैंने उसे ViewModel में डाल है, 
और गतिविधि को डिस्प्ले हेतु डाटा
ViewModel से संपर्क से प्राप्त होता है.
जैसे पहले बताया, ViewModel सभी रोटेशन
या कॉन्फ़िगरेशन में बदलाव को बचाए रखता है.
यदि कॉन्फ़िगरेशन में बदलाव होता है 
तो गतिविधि खत्म होकर पुनर्निर्मित होती है,

English: 
that activity UI data
did not go with it.
And all that my newly
recreated activity has to do
is reestablish a connection
with the same ViewModel, which
continued living throughout.
So here's an example of what
the ViewModel code looks like.
Importantly, to make
something a ViewModel,
you either have to extend
ViewModel or Android ViewModel.
And the only difference
is that Android ViewModel
gets a reference in its
constructor to the application
class, if you need it.
So as we saw, the diagram--
the ViewModel knows
about the Repository,
which is why we have a
variable for that there.
And ViewModels also
contain all of the UI data.
Well, what UI data do
we need for this app?
The list of words.
Therefore, that list of
words is in the ViewModel.
And because we're essentially
creating a one screen app,
we're doing the
shortcut where we're
creating the Repository
in the ViewModel.
But in cases where you have more
than one screen per app, which
is probably the case for all of
the apps that your working on,

Hindi: 
और महत्त्वपूर्ण यह है कि गतिविधि UI डाटा 
उसके साथ ख़त्म नहीं होता.
नवनिर्मित गतिविधि को ViewModel के साथ 
संपर्क साधना होता है, जो बरक़रार रहता है.
यह एक उदाहरण है ViewModel कोड का.
यदि आपको किसी की ViewModel बनाना हो 
तो उसे ViewModel तक विस्तृत करें
या Android ViewModel तक.
दोनों में बस इतना ही अंतर है कि Android 
ViewModel रेफेरेंस एप्लीकेशन श्रेणी के
कंस्ट्ररक्टर से प्राप्त करता है, 
अगर ज़रूरत हो तो.
जैसे कि डायग्राम में देख सकते हैं...
ViewModel को Repository का ज्ञान है,
इसीलिए उसके लिए वहाँ एक वेरिएबल है.
ViewModel में संपूर्ण UI डाटा होता है.
इस ऐप के लिए कौन सा UI डाटा चाहिए?
शब्द सूची.
इसलिए शब्द सूची ViewModel में है.
हम एकल स्क्रीन ऐप बना रहे हैं,
इसलिए ViewModel में Repository के पास
शॉर्टकट बनाएँगे.
लेकिन जब एक से अधिक ऐप स्क्रीन होती है,
जैसे कि आप ज़्यादातर बना रहे हैं,

English: 
you probably also want to make
a singleton for the Repository,
and use dependency injection to
get it inside of the ViewModel.
Using dependency injection
means that you can easily
mock the Repository, which
makes the ViewModel incredibly
easy to test.
And I was hiding this
code from you before,
but you will also
additionally have
the getter there and
probably this insert method.
So your activity needs to
be able to actually access
the data.
So because my LiveData list
of words up there is private,
I'm creating a getter for it.
Notice how it is
returning LiveData,
and it's not returning
just the list of words.
This is important
later, because you're
going to be accessing the
LiveData in the activity.
Similarly, you will have methods
for dealing with any user
interaction that the user
might have with your activity.
So the activity will not
be responsible for doing
any of the processing, itself.
When you insert a word,
it will immediately
tell the ViewModel, hey,
a word has been inserted.
And then it will be the
ViewModel's responsibility

Hindi: 
आप एकल Repository के लिए बनाना चाहेंगे 
और डिपेंडेंसी इंजेक्शन की मदद से
ViewModel तक पहुँचेंगे.
डिपेंडेंसी इंजेक्शन के प्रयोग से 
Repository को आसानी से हटाया जा सकता है
जिससे ViewModel की जाँच करना 
बहुत आसान होता है.
यह कोड अब तक छूपाकर रखा था, 
पर यहाँ पर एक गेटर और शायद
एक इन्सर्ट मेथड भी आपको मिले.
आपकी गतिविधि को डाटा का एक्सेस 
मिलना ज़रूरी है.
यहाँ मेरी LiveData शब्द सूची निजी है,
इसलिए मैं उअके लिए गेटर बना रही हूँ.
ध्यान दें किस तरह LiveData दे रहा है
न कि सिर्फ शब्द सूची.
यह महत्त्वपूर्ण हैं क्योंकि बाद में 
आप गतिविधि में LiveData को एक्सेस करेंगे.
इसी तरह आपके पास हर तरह के 
उपयोगकर्ता के इंटरेक्शन से निपटने के
तरीके गतिविधि में होंगे.
गतिविधि किसी भी तरह की कार्यवाही 
खुद नहीं करेगी.
जब आप शब्द इन्सर्ट करेंगे, 
वह ViewModel को उसकी जानकारी देगा.

Hindi: 
यह ViewModel की जिम्मेदारी होगी 
आगे क्या करना है.
आप देखेंगे कि मुख्य गतिविधि को 
ViewModel की जानकारी है.
अब देखते हैं, कैसे?
इस संपर्क को साधने के लिए 
कोड ऐसा होगा.
आप देखेंगे कि आप वहाँ 
नया ViewModel नहीं बना रहे हैं.
यह कोड onCreate पर बनता है.
आप नया ViewModel नहीं बना रहे है.
आप प्रदानकर्ता श्रेणी का प्रयोग करते हैं
जो आपको सही ViewModel रेफ़्रेन्स देता है,
क्योंकि, गतिविधि को पुनर्निर्मित करते समय
सही ViewModel से साथ 
फिर संपर्क साधना पड़ता है.
ViewModel प्रदानकर्ता दिए गए Lifecycle 
स्कोप के लिए ViewModel प्रदान करते हैं.
जो कि मूलतः दी गई एसोसिएटेड गतिविधि है.
यह जानने के लिए कि किस गतिविधि के लिए 
ViewModel चाहिए,
आपको उसे पैरामीटर में डालना होगा.
यहाँ पर हमें मुख्य गतिविधि के लिए
ViewModel चाहिए.
और अंतः यह बताना है कि कौनसी 
ViewModel श्रेणी चाहिए.

English: 
to decide what to do with that.
And you'll notice
that our main activity
knows about our ViewModel.
So let's see how it does that.
So the code to set up that
association looks like this.
And you'll notice that
you're not constructing
a new ViewModel there.
So this code happens
at onCreate, and yeah.
You're not constructing
a new ViewModel.
You're using a provider
class, and that's
getting you the
correct ViewModel
reference, because remember,
when we recreate the activity,
we need to reestablish
a connection
to the correct ViewModel.
So ViewModel providers provide a
ViewModel for a given Lifecycle
scope.
So basically, a given
associated activity.
And to identify
what activity you
want to get the
ViewModel for, you
have to put it in
there as a parameter.
And in this case,
we're saying, hey,
I want the ViewModel
for this main activity.
And finally, you
just need to tell it
which ViewModel class you want.

Hindi: 
ये कुछ अन्य जानकारी है 
ViewModel Lifecycle पर.
ViewModel कॉन्फ़िगरेशन के बदलाव से बचते हैं
पर गतिविधि समाप्त होने पर समाप्त होते हैं.
वे स्थाई नहीं होते हैं.
वे गतिविधि Lifecycle से जुड़े होते हैं 
पर ऐप Lifecycle से जुड़े नहीं होते.
तो जब गतिविधि ख़त्म होती है, 
जैसे यदि उपयोगकर्ता बैक बटन दबाता है
या Overview स्क्रीन पर जाता है 
और गतिविधि को स्क्रीन से मिटाता है,
तब ViewModel नष्ट हो जाता है.
इसलिए ViewModel डेटाबेस की जगह 
नहीं ले सकता और ना ही डाटा बना सकता है.
यह बहुत अस्थाई है.
यदि आप ऐप में बग्स नहीं चाहते तो, यह जानना
ज़रूरी है कि ViewModel,
onSaved इंस्टैंस स्टेट की जगह नहीं आयेगा, 
हालाँकि, दोनों सामान दिखते हैं.
ऐसा इसलिए है क्योंकि onSaved...
यदि आपके डिवाइस पर बहुत भार है
क्योंकि मेमोरी कम है 
और ऐप बैकग्रॉउंड में है,
तो OS आपकी ऐप को ख़त्म कर सकता है.

English: 
So I have a couple of additional
notes about the ViewModel
Lifecycle.
So ViewModels survive
configuration changes,
but they don't survive the
activity being finished,
So they're not a permanent
thing that stays around forever.
They're linked to an
activity Lifecycle,
but they're not linked
to the app Lifecycle
or anything like that.
So when the activity finishes,
such as if the user presses
a Back button or if they
go to their Overview screen
and actually swipe your
activity off the screen,
the ViewModel will also
be destroyed as well.
So a ViewModel does not
replace having a database
and persisting your data.
It's pretty transitory.
An important thing
to realize, too,
because I want you guys to
avoid having bugs in your app,
is that ViewModels
are not a replacement
for onSaved instance state,
even though they seem similar.
And that is because onSaved--
so if your device
is very stressed out
because there's a lot of
memory constraints going on,
and your app is
in the background,
it's possible that the OS
will just kill your app.

Hindi: 
onSaved इंस्टैंस स्टेट ऐसी स्थिति में,
ऐप को नष्ट होने से बचती है.
पर ViewModel ऐसी स्थिति बच नहीं सकता.
वह में नष्ट हो जाता है.
इस तरह के मामलों में आपको onSaved 
इंस्टैंस स्टेट की आवश्यकता होती है
UI स्टेट जिस स्थिति में थी 
उसमें वापस लेन में.
यह थोड़ा जटिल है, इसलिए मैंने एक
ब्लॉग पोस्ट लिखी है, किस तरह पर्सिस्टेंस
onSaved इंस्टैंस स्टेट और ViewModel को 
साथ प्रयोग कर रिस्टोर किया जाए.
यदि आप चाहें तो उसे पढ़ सकते हैं.
आखरी पड़ाव है यह देखना कि ऑब्जरवेशन का 
उपयोग कर ऐसा संपर्क साधें
जिससे ViewModel अपने UI को संपर्क कर 
डाटा गतिविधि तक फिर पहुँचे.
यह संभव होता है LiveData से, 
जैसा कि हमनें पहले भी समझा है.
DAO हमने पहले भी समझा है.
हम जानते है कि हम यहाँ 
LiveData का प्रयोग करते हैं.
LiveData एक ऑब्जेक्ट है डाटा होल्डर 
श्रेणी में, और इसे Lifecycle का ज्ञान है.

English: 
And onSaved instance
state is actually
useful for surviving this
total app destruction.
ViewModels do not survive this.
They also get destroyed.
Therefore, in those
cases, you still
need to use onSaved instance
state to get your UI state back
to what it was before.
So this is fairly
complicated, so I've
written a blog post that talks
about how you use, together,
persistence onSaved instance
state and a ViewModel
to be able to
restore that state.
And you can go ahead and read
that if you're interested.
So the final step is to see how
we get this connection where
the ViewModel is actually
communicating its UI data back
up to the activity
via Observation.
And it does this with LiveData,
which I've mentioned about 100
times at this point.
So in your DAO, we had a
little bit of foreshadowing.
We already saw that we're
using LiveData here.
So LiveData is an object
that is a data holder class,
and it's also Lifecycle aware.

Hindi: 
यह डाटा को ऑब्सेर्व करने 
की अनुमति प्रदान करता है.
इसका क्या अर्थ हुआ?
कई लोग आब्जर्वर पैटर्न से परिचित हैं, 
पर मैं एक नज़र डालूंगी
उनके लिए जिन्हें जानकारी नहीं है.
आब्जर्वर पैटर्न में आपके पास एक 
ऑब्जेक्ट होता है जिसे सब्जेक्ट कहते हैं.
इस सब्जेक्ट में एसोसिएटेड ऑब्जेक्ट्स की 
सूची होगी जिसे ऑब्सेर्वेर्स कहते हैं,
ये सब्जेक्ट के साथ रजिस्टर होकर 
उसे सूचित करते हैं.
और कहते हैं कि बदलाव की सूचना दो.
जब सब्जेक्ट की स्टेट बदलती है...
किसी घटना की वजह से, उसे आब्जर्वर सूची
की जानकारी होती है, 
और उन्हें सूचित करता है.
इसके लिए वह एक मेथड का प्रयोग करेगा
जो आब्जर्वर ऑब्जेक्ट में है.
LiveData इस पैटर्न का 
अक्षरशः अनुसरण करता है.
यहाँ पर LiveData सब्जेक्ट है और आप 
ऑब्जेक्ट निर्मित करेंगे जो आब्जर्वर होंगे,
ये कहाँ पर स्थित होंगे... आब्जर्वर
ऑब्जेक्ट सामान्यतः मुख्य गतिविधि में,
यदि आप UI अपडेट की बात करें तो.
आब्जर्वर ऑब्जेक्ट 
मुख्य गतिविधि में निर्मित होंगे,

English: 
It also allows for
data to be observed.
And what do we mean by that?
Well, many of you might already
be familiar with the observer
pattern, but I'm going
to go over it quickly,
in case you aren't.
So with the observer
pattern, you
have an object called a subject.
And that subject will have
a list of associated objects
called observers that basically
register with the subject
and say, hey, I'm
interested in you.
Please tell me when you change.
So then, when the
subject's state changes--
some event causes
it to change, it
knows about that
list of observers,
so it will notify all of them.
And it will usually do that by
calling a method that is inside
of that observer object.
So LiveData follows this
pattern almost exactly.
So in our case, the
LiveData is the subject,
and you will be creating
objects called Observers,
which are the Observers.
As far as where these
things are located--
Observer objects will usually
be located in the main activity,
if we're talking
about UI updates.
And Observer objects will be
created in the main activity,

English: 
and LiveData is obviously
located in the ViewModel,
in this case.
So in the main
activity, you will
call Observe on LiveData,
which will set up
that connection between the
observer and the LiveData,
and you will create a
new observer object.
Then, because we've set up our
LiveData to work with Room,
when the database state
changes, the LiveData updates.
And then the LiveData will
tell all of the Observers
that it's updated,
and the Observers
will call this onChanged method.
Now, because we have our
Observers being instantiated
in our main activity,
at least in this case,
those Observers
can easily update
the UI of the main activity.
So what the end
state of this is,
is whatever the database state
changes, that our main activity
is updating its
UI automatically,
without us having to call
anything else at that point.
So the observation
code looks like this.
Remember how I said that
getter in our ViewModel
is returning a LiveData?
Well, it's doing
that because we need

Hindi: 
और LiveData ViewModel में स्थित होगा,
इस केस में.
आप मुख्य गतिविधि में ऑब्ज़र्व को 
बुलाएँगे LiveData, जो आब्जर्वर
और LiveData के बीच संपर्क स्थापित करेगा, 
फिर नया आब्जर्वर ऑब्जेक्ट निर्मित करेंगे.
क्योंकि, LiveData को Room के साथ 
काम करने के लिए स्थापित किया है
जब डेटाबेस स्टेट बदलेगा,
LiveData अपडेट होगा.
LiveData सभी ऑब्सेर्वेर्स को सूचित करेगा 
फिर आब्जर्वर onChanged मेथड को बुलाएगा.
क्योंकि, हमने ऑब्सेर्वेर्स को 
मुख्य गतिविधि में दिखाया है,
ऑब्सेर्वेर्स आसानी से UI की मुख्य गतिविधि
को अपडेट करेंगे.
तो अंत में स्थिति कैसी होगी,
जैसे जैसे तरह डेटाबेस स्टेट बदलेगा,
मुख्य गतिविधि अपनेआप UI को अपडेट करेगी,
बिना किसी सहायता के.
ऑब्जरवेशन कोड ऐसा दिखेगा.
याद है मैंने बताया था ViewModel का 
गेटर LiveData प्रदान करेगा?

English: 
the LiveData in the activity.
So here, we are
getting the LiveData.
We are calling that Observer
method, which sets up
the Observation relationship.
We're making a new
Observer object,
and when we make a
new Observer object,
we have to define
the onChanged method.
And in that onChanged method,
we're doing a UI update.
And this means that whatever
database data changes,
that method is
going to be called.
And as you can see,
it's taking our adapter
and telling it to
update the list of words
that it's showing.
And you'll also notice
how the type of LiveData
determines the parameter
of that onChanged method
of the type of Observer that
you have there, and it matches.
Now, one more thing
that you might notice
is that the Observer
takes in your activity.
So why is it taking in
your activity, also known
as a Lifecycle owner?
Well, that's because of this
other property of LiveData,
which I mentioned
very sort of quickly,
which is that it
is Lifecycle aware,

Hindi: 
वह ऐसा इसलिए करेगा क्योंकि 
हमें गतिविधि में LiveData चाहिए.
यहाँ हम LiveData ला रहे हैं.
हम आब्जर्वर मेथड को बुलाएँगे 
जिससे ऑब्जरवेशन सम्बन्ध स्थापित होगा.
हम एक नया आब्जर्वर ऑब्जेक्ट बना रहे हैं,
और जब नया आब्जर्वर ऑब्जेक्ट बनता है
तो हमें onChanged मेथड को 
परिभाषित करना पड़ता है.
और उस onChanged मेथड में 
म UI अपडेट कर रहे हैं.
अर्थात, जो भी डेटाबेस बदलाव होगा, 
उस मेथड को बुलाया जाएगा.
आप देख सकते हैं कि वह एडाप्टर को दिखाई गई
शब्द सूची को अपडेट करने को कह रहा है.
आप देख सकते हैं कि किस तरह LiveData
आब्जर्वर टाइप के onChanged मेथड के
पैरामीटर को सुनिश्चित करता है 
और वह मेल खाता है.
अापने देखा होगा, आब्जर्वर आपकी 
गतिविधि को भाँपता है.
वह आपकी गतिविधि जिसे Lifecycle ओनर 
भी कहते हैं, को क्यों भाँप रहा है?
इसका कारण है, LiveData की अन्य विशेषता 
Lifecycle अवेयर, जिस पर थोड़ी ही बात की है,

English: 
and this has to do with
Lifecycle Observation, which
I mentioned before.
So LiveData actually uses
Lifecycle observation.
It observes Lifecycle
to make sure
that it only notifies observers
when they are in a started
or resumed state.
So what this means in practice
is that because you associated
your activity with
that specific Observer,
it will only update
your activity
if it is in an active state,
if it is actually on screen.
So it will never notify
your activity of UI changes
if it's off screen,
which is probably
what you want because you
don't want your offscreen
activity to be updating its UI.
In addition, the
LiveData knows how
to clean up Observers when
they're no longer needed.
So if the activity that's
associated with the Observer
is destroyed, the Observer
will clean itself up,
which means that you
are never in a case
where your LiveData is
updating a destroyed activity.
And this makes it so that you're
not going to have memory leaks.

Hindi: 
इसका सम्बन्ध Lifecycle ऑब्जरवेशन से है, 
जैसा कि पहले बताया.
LiveData वास्तव में Lifecycle ऑब्जरवेशन का
प्रयोग करता है.
वह Lifecycle को ऑब्सेर्व करके 
तभी सूचना देता है
जब आब्जर्वर स्टार्टेड 
या resumed स्टेट में हो.
इसका अर्थ यह हुआ कि क्योंकि अापने 
गतिविधि को विशेष आब्जर्वर के साथ
असोसिएट किया है, वह आपकी गतिविधि को
तभी अपडेट करेगा जब वह एक्टिव स्टेट में हो,
वास्तव में स्क्रीन पर हो.
यह कभी भी UI में बदलाव की गतिविधि को
ऑफ स्क्रीन होने पर सूचित नहीं करेगा,
क्योंकि आप नहीं चाहेंगे कि आपकी ऑफ स्क्रीन
गतिविधि से UI अपडेट हो.
साथ ही LiveData जानता है कि किस तरह 
अनावश्यक ऑब्सेर्वेर्स को साफ करना चाहिए.
तो यदि कोई आब्जर्वर से सम्बंधित गतिविधि 
समाप्त हो गई हो तो आब्जर्वर
अपनेआप साफ हो जाते हैं,
इसका अर्थ यह हुआ कि कभी भी LiveData
किसी ख़त्म हो चुकी गतिविधि को 
अपडेट नहीं करेगा.
वह ऐसा करता है ताकि आपको कभी 
मेमोरी लीक्स का सामना ना करना पड़े.

Hindi: 
यह ऑब्सेर्व मेथड बहुत शक्तिशाली है.
वह ऐसे सम्बन्ध स्थापित करता है कि 
आब्जर्वर और गतिविधि में आपसी लिंक हो,
और आपका LiveData, Lifecycle अवेयर हो.
दोहराते हुए, LiveData के कई फायदे हैं.
वह प्रतिक्रियात्मक UI का निर्माण 
करने के लिए ज़रूरी है,
ऐसे UI जो डाटा में बदलाव के साथ 
अपनेआप बदलते हैं.
वह Lifecycle अवेयर होता है, ताकि UI को 
तभी अपडेट करे जब UI स्क्रीन पर हो,
और फिर उसे अपनेआप साफ करे दे.
अापने देखा होगा कि कोई onStop मेथड नहीं है
जो कहे, Lifecycle ऑब्ज़र्व करना बंद करो.
यही Lifecycle ऑब्जरवेशन है.
यदि आप अपनी लाइब्रेरी बना रहे हों 
और किसी को onStop में कोई मेथड बुलानी हो,
तो आप Lifecycle ऑब्जरवेशन का प्रयोग 
कर सकते हैं, ठीक LiveData की तरह
इस प्रकार की क्षमता पाने के लिए.
अंतः, वह डेटाबेस को पिछले किसी भी UI
कंट्रोलर से संपर्क करने में सहायक होता है
बिना डेटाबेस UI कंट्रोलर के बारे में जाने,
यह बहुत लाभकारी होता है

English: 
So this Observe method is
actually pretty powerful.
It's, again, setting
up that relationship so
that your Observer and your
activity are linked together,
and your LiveData can be
Lifecycle aware of it.
So to reiterate, LiveData
actually has a lot of benefits.
It is important for
creating reactive UIs, which
are UIs that
automatically change
when underlying data changes.
It's also Lifecycle
aware, so it only
updates the UI when the UI
is actually on the screen,
and it cleans itself
up automatically.
You'll notice how there was
no onStop method that said,
Lifecycle, stop observing,
or anything like that.
That's that Lifecycle
Observation.
And actually, if you were
creating your own libraries
and people need to call
some method in onStop,
you could use the same
Lifecycle observation
that LiveData does to get
that same sort of capability.
And finally, it allows
for the database
to be able to communicate
back up to any sort of UI
controllers without the database
needing to know about those UI
controllers, which is
very powerful when your UI

English: 
controllers are being
potentially destroyed.
Cool.
So this, again, is our
whole architecture there.
And with that, you're going
to go ahead and continue on
in the Codelab, and
actually implement
LiveData and ViewModel now.
[APPLAUSE]
[MUSIC PLAYING]

Hindi: 
जब UI कंट्रोलर नष्ट हो रहे हों.
तो यह था सम्पूर्ण आर्किटेक्चर.
इसके साथ अब आप कोडलैब में काम करते हुए
LiveData और ViewModel क्रियान्वित करेंगे.
