hello, Andy

Hi Mark

how can I help you today?

do you have any questions that I can try to answer?

"You can have a large screen with a lower dp than a smaller screen" -- no

you can have a large screen with a lower *screen density* than a smaller screen

however, 1dp is 1/160 of an inch, all the time

so, screen sizes measured in dp are no different than screen sizes measured in inches or millimeters

can you clarify the difference between dp and screen density. Does something with high dp mean high density, or not? Thank you

dp = density independent pixels

"high dp" isn't really a term we would use

a screen that measures 640dp by 480dp might have a low screen density or a high screen density, because a screen that measures 640dp by 480dp is a screen that measures 4 inches by 3 inches

dp is just another unit of distance, like an inch, a millimeter, or a light-year

(though we tend not to measure screen sizes in light-years :-)

oh ok, so it is size. Screen density == screen resolution aka how clear the picture is?

screen density != screen resolution

screen density is how many pixels there are per inch

a higher screen density can help with how clear the picture is, though that may also depend on where the picture is coming from

screen resolution is how many pixels are shown

so, for example, a 1080p device has a resolution of 1920 pixels by 1080 pixels

however, that device could be a phone, a television, or anything in between

resolution is mostly for marketing purposes -- programmers tend to worry about screen size and screen density

we care about screen size so our layouts make effective use of the space

we care about screen density so our icons and other artwork are consistently sized on screens with different densities

oh ok, so you can have a high screen resolution but still have low quality picture because the screen size may be huge. Therefore the screen density is low because there are a low number of pixels per inch?

correct

thanks

if you have another question, feel free to ask!

i've been reading and working with fragments and custom views(a view that simply extends from a ViewGroup and inflates an xml). In my experience it seemed harder to restore state using the custom view than the fragment. What are some good guidelines to decide which to pick

most of the time, you will be better off using fragments

IMHO a custom View is for cases where you have a pure bit of UI that you want to reuse -- in other words, you really do want to create a custom widget

in particular, if the bit of UI is small, a custom View might be more appropriate than a fragment -- for example, we cannot put fragments inside rows of a RecyclerView very easily

for example, a custom progress indicator, like https://github.com/2hamed/ProgressCircula, makes sense as a custom View, as it takes up little space, needs to be embedded in lots of things, and has no business or domain logic

interesting

I feel that using a custom view is particularly good if there is some business logic because it becomes a useful reusable component. For example, if I have rows in a recyclerview, I can easily accomplish the same thing by just declaring the item_view xml. On the other hand if I have a view that has behavior, say an edittext that exists to validate whether the user guessed the entered number correctly, and lights up it is a convenient way to reuse something

IMHO, there are better ways to do the reuse than a custom view, such as by having some sort of reusable presenter, controller, or viewmodel

but, you are certainly welcome to create custom views for business scenarios, and I know that there are developers who do that -- it's just not the mainstream approach

I was browsing (I think the jetpack book) you are writing that is still in progress. One part that was of particular interest to me was your mention of a Repository in the data layer that handles caching. If I understand what you allude to, the 1st layer is callable by the application to retrieve data. Once it retrieves data via a network request, the Repository can cache it to serve it up. Therefore, the front layer method signature changes from "getPersonDetails(String id(" to "getPersonDetails(String id, boolean useCache)

I'll be expanding on the repository pattern in *Elements of Android Jetpack* when I get to the chapter on Room, though it will be a couple of months before I get there

the *Exploring Android* series of tutorials will have a repository

you can read more about the repository pattern now in *Android's Architecture Components*, one of my first-generation Android books

OK thank you. I'll look for it to see how exactly you manage the new vs old data

I don't think that I get into caching strategies specifically, as that is *very* dependent on lots of factors

so a repository can (and ideally does) implement caching, but the details will vary a lot by situation

ok

that was all I had today. Are you able to answer questions about RxJava 2 or Dagger 2, or is this limited to the android SDK

you can ask, though my Dagger experience is fairly limited, so I probably cannot help on that topic

OK have a good afternoon! :)

you too!