DAN GALPIN: Hi, again, live from the Android Developer Summit
sandbox.
You are tuning into the #AskAndroid livestream,
and we'd like to welcome Yigit Boyar and Jisha Abubaker
to the next and final session of the #AskAndroid livestream.
LYLA FUJIWARA: Oh, final session.
DAN GALPIN: I know.
LYLA FUJIWARA: All right, but this is a good one.
So Yigit is the Lead on Architecture Components.
He would also like you to know that he has
a very cute dog named Frieda.
Jisha is the Architectural Components Product Manager.
She, alas, has no cute dog, but she
does have a very cute child.
[LAUGHTER]
Right.
Anyways, regardless of dogs and children, what both of them
have is a lot of architecture components knowledge.
So if you'd like to ask a question
during this final segment, go ahead
and use the #AskAndroid hashtag.
And we're watching them all in the livestream now.
All right, Dan, want to get started?
DAN GALPIN: Yeah.
So @Ihwan_ID asks, "Is View Binding
much better than Data Binding?"
LYLA FUJIWARA: Straight up with that.
DAN GALPIN: From-- definitely, here's
the author of data binding.
What do you think?
YIGIT BOYAR: So they are different things.
So view binding, like, provides you compile time safety
when you talk to your layouts.
And it's super nice.
You should definitely use it.
So there is no point in doing find view by ID.
On the other hand, data binding does
have the same functionalities.
Plus, it allows you to declare your UIs,
so what data do you want to show.
But you may or may not want to use it
depending on your application architecture.
And also, view binding is very cheap to do.
Like, it doesn't slow down your compilation,
versus data binding.
Because it analyzes your code, it takes more time.
So you get some more benefits from data binding
and pay a bigger cost, versus you get less benefits from view
binding and pay less cost.
So they are different things.
DAN GALPIN: Yeah.
You know, who cares about build speed, anyway?
Right?
That's like--
YIGIT BOYAR: We don't.
No, it's important.
DAN GALPIN: I know.
YIGIT BOYAR: It's not like data binding is slow.
Like some code, you're right, if you are writing it
for you, of course.
DAN GALPIN: Yeah.
Yeah.
I use data binding a lot.
I really enjoy it.
So I-- all right.
LYLA FUJIWARA: Are there any use cases where
you would use both of them?
Or is it really one or the other?
YIGIT BOYAR: Data binding is a superset of view binding.
So if you are using data binding,
you don't have to use view binding.
Actually, they use the same infrastructure.
So there is no point in--
I mean, actually, think about it.
You may want to use them together.
So, like I say, if you have a layout file where you want
to access the views, whatnot, but you don't really
want to set any variables, then you
may use view binding as sort of data binding, just
per that layout in your project.
This will also help us avoid generating
[INAUDIBLE] costs that does the binding
because there is no binding.
So yes, you can use them together.
LYLA FUJIWARA: Sure, yeah, but definitely, it's
a per-layout thing, at the very least.
YIGIT BOYAR: Yeah.
Yeah, exactly.
LYLA FUJIWARA: All right, cool.
All right, so next question.
"Can we have something like startFragmentForResult
for the Navigation Controller?"
That is Sbo3000.
JISHA ABUBAKER: Yeah, so for the navigation library, what we've
been really trying to do is like just abstract away
from activities, fragments, or like if you're
using custom destinations.
So, in this case, I would say yes.
The teams really like working on this
from just trying to understand, like, how can we
kind of abstract away from all these different callbacks
that you have right now, like the startActivityForResult,
startFragmentForResult, and like there will be a navigate
to result. So how can we kind of clean that up and provide
a much cleaner API?
So stay tuned is what I would say.
Team's on it.
We appreciate your patience.
LYLA FUJIWARA: There was definitely
some up-voted feature requests, I
would say, like related to that.
JISHA ABUBAKER: Exactly, and so, yeah.
LYLA FUJIWARA: And I know that you--
JISHA ABUBAKER: Team's really looking into it, yeah.
LYLA FUJIWARA: --and Ian, Yigit, really pay attention to this.
JISHA ABUBAKER: The remainder, really looking into it.
YIGIT BOYAR: We don't, per this feature,
but we are working on it.
DAN GALPIN: All right, so we got a bunch of comments around,
what's up with Paging 3.0?
JISHA ABUBAKER: Wow.
DAN GALPIN: What's up with that?
YIGIT BOYAR: Paging Jisha.
JISHA ABUBAKER: Yeah, I know.
Wait, what's up with Paging?
Well, I think Yigit touched on this at the last I/O.
And we talked about how we had planned--
like rework the Paging API.
Kind of, we've taken a lot of the developer feedback
around like, well, what do-- how does
this work when I have, like, network and a database
use case?
And, like, how do I kind of propagate all my errors up
correctly?
And so those are really like all the problems
we're trying to solve with the Paging 3.0 plan.
And you know, like it's, again, out in the open in terms
of commits.
So if you're really interested, check out [INAUDIBLE]..
I think that's a great place to see what the progress is.
But the plan is, like, how can we leverage Kotlin coroutines,
provide a simplified interface, provide
a lot of this error handling and so forth out of the box?
So, yeah, stay tuned again, I would say.
YIGIT BOYAR: Oh, process.
JISHA ABUBAKER: Yeah.
LYLA FUJIWARA: Come back to the next #AskAndroid
to be asking questions about some of these things.
All right, cool.
So @Streetsofboston asks, from Twitter--
it's more of a feature request, but I'm also
kind of curious about this, so live feature request.
"A Room-like API for ContentResolvers,
removing the need for explicitly handling
Cursors and ContentValues."
Have you heard that request before?
Is it already done, and I don't know it?
JISHA ABUBAKER: Do you want to talk to that, Yigit?
It's like--
YIGIT BOYAR: Actually, yes.
So Samir is looking into this problem, right now.
We actually did the extra research
to understand, like, what are the patterns, where
we can improve.
It's partially related to scope storage as well.
So we want to make it easier if they
know what they really want, a feature request will
be really nice.
And then we can connect them with Samir
and talk more about it.
But we know there can be improvements here,
but there's nothing yet.
LYLA FUJIWARA: So you're mentioning a feature request,
and we've said that a couple more times.
How does one who has never made a feature request
make a feature request?
Like, what are the--
YIGIT BOYAR: So you go to issuetracker.google.com.
JISHA ABUBAKER: Yeah, I think the easiest way might be if you
go to d.android.com/jetpack/community.
There are instructions there on how
you can kind of file an issue for the architecture
components.
LYLA FUJIWARA: Yeah, and I think you can star other issues?
JISHA ABUBAKER: Yes.
LYLA FUJIWARA: And the team really pays attention
to that as we've been saying before.
JISHA ABUBAKER: Yes, a lot of attention.
YIGIT BOYAR: Actually, I've used those stars for prioritization.
DAN GALPIN: So Arif asks, "How do we
solve the multiple time LiveData observer and notify issue?"
YIGIT BOYAR: These questions are so hard, coming in.
[LAUGHTER]
LYLA FUJIWARA: If you keep asking hard questions,
maybe Yigit will cry on camera.
DAN GALPIN: Tears.
[LAUGHS]
YIGIT BOYAR: So there is--
what I see most of--
like, this is a problem.
We understand that it's not very easy.
But the mistake people usually make
is you think something is an event.
But most of the time, if you can structure it as a state,
then things get easier.
So all this data-driven architecture,
you want to have your UI represent what the state is.
So this usually happens where remodel wants to do something.
How do I do it?
So I dispatch a single live event.
DAN GALPIN: Yeah.
YIGIT BOYAR: Don't use it.
The problem there is your remodel doesn't have a view.
You don't do a know if the view is there.
Like, you are not able to do those.
All you can do is you can change your state.
Like, maybe your state is, my sign-up is complete.
And then your UI can take care of moving you
to the other screen when they respond and when it comes back.
There's also like something-- so with actually
introduction of Kotlin channels and their fan-out behavior,
there is a way to implement this much nicer,
using the common pattern, where you can anchor these requests
and you can have your UI consume these.
So that's what I recommend people
to look at if they're finding themselves in a situation,
like, where something needs to be handled
and that needs to happen by the UI,
they can totally use this common pattern
to handle this communication in a well described way.
DAN GALPIN: Now, do you see something in navigation that
would actually help would help users
have to eliminate the need for kind of a live event?
Is that something worth thinking about?
YIGIT BOYAR: There's some explorations in that area
because navigation kind of has a state where
we could expose a part of this, but nothing concrete yet.
It's not very trivial because, I mean,
navigation works in the historical world of Android,
so it's not always very trivial to apps like these things.
DAN GALPIN: Great.
LYLA FUJIWARA: All right so Jann asks through the YouTube
livestream, "How do you ensure proper use of LiveData
from ViewModels?
Are you supposed to have a private MutableLiveData
and expose a different field as a LiveData?"
LiveData map and LiveData so, "And how does this
apply to map and switchMap?"
YIGIT BOYAR: You can't--
LYLA FUJIWARA: Sorry, I should say a little bit slower?
YIGIT BOYAR: Yeah, I didn't get the question part.
JISHA ABUBAKER: Yeah.
LYLA FUJIWARA: So I think it's basically,
they're asking whether--
is OK to expose a MutableLiveData?
DAN GALPIN: From your ViewModel?
LYLA FUJIWARA: From your ViewModel,
or should you keep that private and expose a LiveData field?
YIGIT BOYAR: It's better than not
to expose a MutableLiveData.
JISHA ABUBAKER: Yeah.
YIGIT BOYAR: You're basically, in that case,
like if you're exposing a MutableLiveData,
that means you expect them to edit it.
But it's your data.
Like, you don't have public variables everywhere, right?
You usually have private variables.
It's the same mentality.
So if you don't want them to edit it,
don't expose it as mutable.
LYLA FUJIWARA: Sure.
JISHA ABUBAKER: Yeah.
Yeah, [INAUDIBLE].
LYLA FUJIWARA: Yeah, in a lot of the samples,
I think we showed that in our ViewModels,
properly encapsulating it.
So you can take a look at those.
They were asking for the map and switch map cases.
In both of those cases, I believe just the LiveData
is exposed anyways?
DAN GALPIN: Yes, exactly.
LYLA FUJIWARA: There's not a MutableLiveData exposed.
So that hopefully solves the situation for you.
DAN GALPIN: All right, from Twitter also,
Chow asks, "Should I use Flow instead of LiveData
on Room when I want to reflect up-to-date data to other layers
that can change anytime?"
JISHA ABUBAKER: Do you want to make a call on that, Yigit?
[LAUGHTER]
DAN GALPIN: Hi, LiveData author.
YIGIT BOYAR: We love it.
JISHA ABUBAKER: Yeah.
YIGIT BOYAR: We love Flow.
JISHA ABUBAKER: Yeah, we do.
YIGIT BOYAR: That right?
JISHA ABUBAKER: No.
So in this context I think with like Room and the the Flow use
case, like, Dan, you had a talk on this yesterday, which
I definitely do think, like, yes, you know,
there is a path like leverage a lot
of what you try to do there with Flows.
But to like, is there a LiveData and is there a world
where you're kind of using the LiveData
with the Flows combined?
What is your take on it?
YIGIT BOYAR: I mean, from the perspective of Flow,
if you already made the transition to coroutines
and Flow, I think it just all makes sense to use Flow.
JISHA ABUBAKER: Yeah.
DAN GALPIN: Yeah.
YIGIT BOYAR: The biggest difference here
is with the structured concurrency and all
the lifecycle scope things we have added in at 2.2
of Lifecycle, it's actually very easy
to consume a flow in a lifecycle constraint way as well.
So these are coming very hot, like it's
just only RC, right now.
So it may take some time to stable,
but it's completely fine to return a Flow from Room.
Probably I will do that, still do that.
From your vim, like you can convert a Flow to LiveData.
You could still do that in your ViewModel,
so your UI code doesn't have much asynchronous stuff.
But, yeah, I think it all makes sense.
DAN GALPIN: I really like that pattern.
I like the pattern of not having LiveData coming from Room,
and having LiveData just coming from ViewModel, in general.
I feel like that's a nice way-- sorry about that.
In general, it's a nice way of doing that.
YIGIT BOYAR: Yeah, it's a transition, period.
These libraries are new.
Like, AUTOflow is a preview and experimental.
Before we can fully recommend something,
we need them to stabilize, right.
DAN GALPIN: Yeah, exactly.
LYLA FUJIWARA: All right, so going back to navigation,
@Tialaw asks, "When is on-demand dynamic features
support for Navigation component coming?"
DAN GALPIN: Ah!
[LAUGHTER]
YIGIT BOYAR: Minus--
[INTERPOSING VOICES]
DAN GALPIN: Yeah, I was going to say.
LYLA FUJIWARA: This was asked a few days ago, so.
JISHA ABUBAKER: But I think it's important to also,
I think, understand from the dynamic feature module and beat
navigation support, what we're really trying to also
addresses is, how do we handle that kind of installation
of that module, even, that happens on demand?
How do you make sure your app behaves
as expected when you navigate to it,
even if that module doesn't get installed or, you know,
it fails?
At the same point, you know, we have
tools like Navigation Editor.
And, like, how do we make sure all that
is like a good seamless experience?
I think, so Ben and Wojtek from Android DevRel,
they have been doing a lot of work in this space,
and I think they did share like a sneak peek
into like where they are and possibly a way for you to kind
of provide feedback on it.
I think it was like at 9:30 this morning PST.
But, yeah, I highly encourage checking out that talk.
And I think that if you're interested in giving feedback,
they would be all ears for it.
DAN GALPIN: I think that's one of the cool things
about the navigation component is
that we actually wrote the Navigator
in a very generic way.
So we simply had to write a navigator that
supported this particular kind of flow,
and it just kind of works, which is cool.
"Is there any plans to support a trigger in Room
by marking a method in the Dao as a trigger?"
And this is from @Alhuthifi1.
YIGIT BOYAR: So I take this two ways, then.
You can add triggers in Room.
You cannot do it through Dao, but you can, like,
add a create callback and add your triggers.
I'm not fully sure what they are asking here,
but if they're asking for the function to
where, when a trigger happens in the database,
can I call this Kotlin function, unfortunately,
the answer is no because--
so SQLite has this API, where you can normally
call a C function, but it's not exposed in the framework.
So we have no way of doing that connection.
Plus, even if we did, that will be kind of expensive.
So, right now, they cannot get a callback to their Java
function, so the activity needs to be scoped as a SQLite
trigger, unfortunately.
DAN GALPIN: All right.
LYLA FUJIWARA: All right, so we actually
started talking about this a little in the last segment,
but we were wondering, what can developers expect to see when--
basically, like Dagger and architecture components,
what is your work here?
What is the Jetpack Dagger initiative?
We've seen a lot of questions on the livestream about just
Dagger, in general, and I know that you guys are
doing some work around that.
YIGIT BOYAR: Yeah, so we have been,
for the last couple of months, we've
been working closer with the Dagger team to understand.
Like we know there is demand.
We know there is a problem, like, developers
are struggling with this.
We're trying to figure out, how can we help.
And we did a user experience research
on how people use Dagger or like other dependency injection
libraries, to find where we can be helpful.
And we have a plan.
We are working with the Dagger team
to still use Dagger, but provide a much more open-data structure
around this so you need to learn the theory
of dependency injection and like all the [INAUDIBLE] to start
using it.
So we're trying to, basically, decrease that entry barrier
so it's much easier to start.
And also, it's trying to provide first class
support for everything we have.
So if you are like a work manager, it just works.
You don't need the--
all right, this callback here and then configure
this thing on time.
So we're trying to get to a state
where you'll start using this new Jetpack DI, whatever
we call it, and everything is taught
for the most common case.
And then as you scale, you can start using Dagger
because we know it scales very well, from Google.
JISHA ABUBAKER: Yeah, and I think
I just want to add on this.
As Yigit mentioned, when we did the user experience
research, one area that I felt we heard a lot was, like,
you know, error handling.
And like, how do we make sure you're not
spending a couple of days trying to figure out a Dagger error?
So that's something we're definitely eyes-on as well as,
like, how do we improve just, like, you spent a lot of time
with the setup, which we really want to simplify.
At the same point, it's like debugging
and, like, just making sure you're
able to manage Dagger within your app
is also another area we're looking at.
YIGIT BOYAR: We're also trying to improve the Kotlin support.
Actually, Dennis Santiago from our team,
he has been doing a lot of Kotlin improvement
so that Dagger understands the Kotlin codes
and, like, just works better.
LYLA FUJIWARA: Awesome.
I'm excited about that.
DAN GALPIN: OK, so last question.
"How best should I keep up-to-date with what's going on
with architecture components?"
Maybe?
[LAUGHTER]
YIGIT BOYAR: I ask my PM.
JISHA ABUBAKER: Yeah.
LYLA FUJIWARA: How do you keep up to date?
[INTERPOSING VOICES]
DAN GALPIN: I get this question, too, so.
LYLA FUJIWARA: --so much.
YIGIT BOYAR: That's how I stay up-to-date.
JISHA ABUBAKER: I say, we have a great Android DevRel team.
[LAUGHTER]
I would highly recommend--
I think what we have done lately with, like, you know,
the [INAUDIBLE] courses, with like the Building Your
Apps with Kotlin, like we've been really focused
on making sure you have great code labs, which
are like hands-on tutorial experiences.
And at same point, I mean, yeah, like stay tuned to Android
Developers is what I would say, and you know it's--
DAN GALPIN: Definitely watch Android Dev at Medium,
I would say.
We put on a lot of posts there early, and so that's helpful.
Any comments for you on this one?
Or watch for Yigit's talk.
YIGIT BOYAR: No, because--
[LAUGHTER]
JISHA ABUBAKER: Yeah, [INAUDIBLE]..
LYLA FUJIWARA: So I have one, actually.
So on DAC, actually, there is a page that
gets into the nitty-gritty.
Whenever there's a release, it gives the release
notes for all of the different architecture component
libraries.
So depending on how deep of a dive that you want to get in,
you can see when libraries get updated,
when they move between alpha, stable, beta phases.
So I'd say--
YIGIT BOYAR: Also--
LYLA FUJIWARA: Yeah.
YIGIT BOYAR: Sorry, don't forget,
like, we're developing all of this in the open.
Everything is on AndroidX.
Like, you can see every single CL or all the conversations
we have there.
So if you are interested, then join us.
Some people send pull requests.
We become very happy when we see them.
So depends how much you want to be involved.
DAN GALPIN: Yeah, exactly.
That's awesome.
LYLA FUJIWARA: You could be making the updates.
DAN GALPIN: Right.
YIGIT BOYAR: Yeah, like apply for a job.
JISHA ABUBAKER: Yeah.
[LAUGHTER]
LYLA FUJIWARA: All right, so thank you so much.
Those are, unfortunately, all the time
that we have for questions today.
So, again, thank you very much, Yigit and Jisha for joining us
for these last 20 minutes.
And thank you, also, so much for joining us
on the #AskAndroid livestream.
DAN GALPIN: Yeah.
Well, again, this concludes our last #AskAndroid segment
during this Android Dev Summit livestream.
So thank you, everyone, who've been watching the livestream
and asking us questions on Twitter and on the YouTube
chat.
Please leave us a comment, and let us know which segment
you like best.
And we're hoping we can do this again.
LYLA FUJIWARA: Yeah, as you can see,
we love your feedback, whether it's
on architectural components or even the type of material
that we're producing.
So we hope that you enjoy the rest of Android Dev Summit
2019.
Again, if you like what you see, give us some feedback.
Don't forget to subscribe to the Android Developers YouTube
channel.
And until next time, happy coding.
[MUSIC PLAYING]