hello, Dominic!

how can I help you today?

hey :)

To be honest I wrote questions but have to look for them in my notes

and I was wondering, what kind of phone do you use

um, lots

I have ~20 within arm's reach of where I am sitting

every single with different android version?

every single one*

they pretty much are all Android 5.0 or higher, so there is definitely overlap of versions

but, they are ones that I have picked up either for specific technical capabilities (e.g., in-screen fingerprint reader) or due to specific crashes that I needed to try to reproduce

hello, marekdef!

hi Mark

and Dominic

Dominic: are you still searching your notes?

got it

If SingleModelMotor was referring to some singleton instance of ToDoRepository

we would be out of luck

In elements of Elements of Android Jetpack Version

in testing chapter, what do you mean by that?

that out of luck

ah

first, in the context of that section, by "singleton instance", I am referring to something like a top-level Kotlin `object`

<listening>

we do not control the instantiation of those -- they get created at some point by the language, perhaps when we first reference tehm

er, them

and, for most uses of our app, we want that object to work with the real database or real server or other real things

in a test, though, we often want to control that more, so we can use a test database or test server or mocks or something

but, with a language-instantiated singleton, we do not really have an opportunity to configure it that way

we could expose some sort of API from the singleton to allow our test code to reconfigure it

but that means we probably wind up with test-specific code shipping in our production app, as we may not have a good way of getting rid of that extra code

dependency inversion allows us some of the benefits of singletons, yet gives us a hook to replace the implementation of the singleton in the context of our tests

so most of our test code can test the singleton naturally, and our production code is not exposed to any of this testing stuff

but test initialization code can say "hey, DI engine, use this ToDoRepository instance instead of the one you would ordinarily use"

thanks I think I more or less get it :)

OK

let me take a question from marekdef, and I will be back with you in a bit

marekdef: hi! how can I help you today?

If your app needs to display a scrolling list of elements based on large data sets (or data that frequently changes), you should use RecyclerView as described on this page.

this is on the documentation of recycler view

but If I have a opposite usecase

I have small number of elements, rarely changing or never, and I want them to be displayed in scrollable container

I could place them in LinearLayout for example (and that LL is a part of bigger screen)

yes, and wrap the LinearLayout in a ScrollView or NestedScrollView, to enable the scrolling

still I feel like I lack some kind of adapter that I just submit a list to it and is displayed

that is what recycler gives me

you can still use RecyclerView if you want

well but it does not recycle :)

well, that's not uncommon

thanks guys I think thats all I needed to know for now :) see you :)

for example, you might not know how big the data set is at runtime

(Dominic: have a pleasant day!)

bye :)

so, you use a RecyclerView, but sometimes you are only showing a few items, because that's all the data that there is

this is not a problem

what you do not want to do is use the LinearLayout approach for large data sets, as that forces you to set up all of the views for all of the items up front

so, RecyclerView can scale up and down for varying data set sizes; the LinearLayout approach is only suitable for small data sets

yes make sense

personally, my general rule is: use RecyclerView for large or varying data set sizes; use a NestedScrollView mostly for cases where it's a fixed layout

ok noted

I could use RV there

if I set it to wrap_content then it should be scrollable within (Nested)ScrollView

um, maybe -- I don't know how well RV handles wrap_content

I think it just displays full content

we were talking about that a lot last chat :-)

(if is inside nested)

we have very similar screen in our app

is nested scroll view

it has some labels

and on the bottom there is RV with some images

(vertical)

my tendency for something like that is to put it all in the RV, with different type types based on the content

er, different item types

(I can't type this morning...)

I think that you're right, and there is a recipe for having an RV inside of a NestedScrollView

if I set the RV to some height then first scroll is on the content and to scroll on the RV you either need to scroll recycler to the middle of the screen (grabbing at content top) or you grab at bottom but then only part with Recycler scrolls

I think we should have use RV for full screen

but we did not

agreed -- as a user, I might find that sort of scrolling behavior to be confusing

in theory is only view so should be replacable :)

if we set RV to wrap_content

then it shows all the content, but scroll is nice

unfortunately is not recycling :)

and it takes long time for 500+ images

yeah, I am not surprised that there are problems with wrap_content for large data sets

wrap_content with maxHeight *might* allow recycling to occur, but I'm not certain

yes it would work

Hi!

still you have the double scroll efect

so you scroll content, stop then recycler

yes, which I do not like much

well me neither

let me take a question from sudokai, and I will come back to you in a bit

sudokai: hi! how can I help you today?

allright thanks for the answer!

Hi Mark

I was glancing through Android R's upcoming changeset

And it seems to me that there's a big location access restriction coming

If I read it right, foreground services will no longer get location updates when the app is in the background

Unless the app requests the background location permission

I'm trying to find the page where this is explained, but this is how I understood it at least

I guess I thought that had been a requirement already

Foreground services does get location updates when the app is the background in Android Q I believe

You only need the background location permission if you do not use a foreground service

OK, and you have determined that this is not the case for Android 11?

I saw this in the changelog, somewhere

the only changes that I know of related to location are those listed in https://developer.android.com/preview/privacy/l...

I'm trying to find it so you can take a look whether you understand the same

ah!

That's it!

yes!

so it depends on how the foreground service was started

if you were in the foreground at the time, it looks like the same behavior as before

if you start the service from the background, you would need ACCESS_BACKGROUND_LOCATION to have location access

Mmm, but even if you started the service in the foreground, it says that when your app is minimized, you don't get the location updates

If the user has granted the ACCESS_BACKGROUND_LOCATION permission to your app, the service can access location all the time. Otherwise, if the user has granted the ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION permission to your app, the service has while-in-use access to location.

my interpretation of "while-in-use" is "so long as your process is running", but that language is a bit confusing

Do you understand this the same way I do??

Yeah, the language is super confusing

But it's potentially a Breaking change with a capital B

If interpreted the way I interpreted it

yeah, I'll make a point of trying some experiments when I work on *Elements of Android R* next

Okay thanks, I'll try to ping some Android Dev Advocate on Twitter for clarifications

That was my question thanks!

the only additional material I see on this is https://issuetracker.google.com/issues/158814176

I'll let the rest of you guys ask questions

Thanks

and that basically ends with the update to the documentation that we are grumbling about

I'll file another issue to try to get that clarified

I'll swing back to you later if there is time

Dominic: you're back! :-) do you have another question?

Tbh I think I found a small typo in exploring android

it wouldn't be the first typo! :-)

In chapter about instrumental tests, last part

it says "Add these two test functions to SingleModelMotorTest :"

it should be ToDoRepositoryTest

(I think)

yes, I think you are correct

I reordered these testing chapters in Version 1.3 and have had some bugs as a result

no, wait

oh, OK -- just to confirm, this is Step #5 of "Testing the Repository"?

yes

OK, I have fixed it for the next update, and I will file an errata notice shortly

if you want to claim this under the Book Bug Bounty program, send me an email to bounty@commonsware.com

thanks!

let me take questions from the others, and if there is time, I will come back to you

marekdef: your turn! do you have another question?

I pass the token further

OK -- sudokai: do you have another question?

I mean sudokai can ask the question

Not at this time Mark

OK, if anyone has any questions, go ahead!

I'll try to clarify this issue I brought up earlier

Because we rely on location updates heavily

More like I have a suggestion

would you say that DataBinding is popular?

marekdef: I don't know that I would go all the way to "popular", but it is used by a lot of developers

I just read on some blog: DB ... will eventually become obsolete. DataBinding is pretty much legacy today.

we used it quite a lot and think we want to use it even more :)

but maybe I am in the bubble

well, data binding is tied to layout resources

Jetpack Compose is the long-term UI direction for Android, and it does not use layout resources

(though you can integrate Compose UI with layout resources if needed, as part of migrating to Compose)

for a project that has not started using data binding, I would recommend not investing in data binding

for a project that already has it, it may be better to keep using it, to keep the implementation of your UI consistent

Will you write a book on Jetpack Compose Mark?

(BTW, sudokai: I just filed https://issuetracker.google.com/issues/167581940 for clarity on "while-in-use")

I dislike this technology change for the sake of it

Thanks I'll star it lol

sudokai: I have plans for a book on Jetpack Compose

Suddenly, RxJava is not cool anymore, now it's all Flow and coroutines. LiveData is not cool, something something StateFlow.

This mindset is toxic imo

it is definitely a challenge to keep up at times

the stuff in android seems to be changing very fast

however, you are conflating two separate things IMHO

there is the fact that coroutines, Flow, and StateFlow were introduced

and there is the fact that "thought leaders" are endorsing them

it's tough to blame JetBrains for developing coroutines, Flow, and StateFlow -- those are Kotlin things, not Android things

and Kotlin has uses beyond Android

in isolation, it is tough for me to blame the thought leaders for recommending newer alternatives, as they do solve problems from their predecessors (e.g., RxJava learning curve)

Yeah, the problem is with the "thought leaders" definitely

however, I do think that we as an ecosystem need to be doing a better job of building bridges from old approaches to new ones

rather than just bouncing from one to the next to the next

that's one of the reasons why, for example, I still cover Java in *Elements of Android Jetpack*

Yeah, our app is still 75% Java

partly, it's for those who are new to Kotlin, and partly, it forces me to discuss non-Kotlin solutions

may I ask, if I were to create new project

should I use data binding? or stuff like kotlin synthetic?

I would not invest in data binding, but I do prefer view binding over Kotlin synthetic accessors

fortunately, view binding only requires a line in Gradle to set up and no layout changes

Also, Mark have you considered doing udemy course?

it's an extra line or so at most to set up the binding when inflating the layout in code

do you mean teaching one?

yes exactly

To be honest, I did an udemy course before

by Tim Butchalka and it was OK

but it lacked the "ecosystem"

I think that your books create whole ecosystem of android learning

you have everything covered in your resources referencing one another

I can't rule out Udemy, but if I were to do video-based training, I would be more likely to do something part of the Warescription program, for the reasons that you cite

right now, I'm just trying to make it through 2020 :-)

There's a huge "hole" in Android video training

exactly

Like, web dev is well covered

And even Swift for iOS

there is project odin for web dev

But Android video courses are very lacking atm

so true

sorry, but I need to wrap up today's chat

I think that is a great niche

Thank you!

Okay thank Mark!

for answering have a nice day

good bye people!

the next chat is Saturday at 4pm US Eastern

have a nice day

have a pleasant day, all!

You too