Office Hours — Today, February 13

← Thursday, February 11

Feb 13
3:55 PM
Mark M.
has entered the room
Mark M.
turned on guest access
Kai H.
has entered the room
Kai H.
Hello Mark
Mark M.
hello, Kai!
how can I help you today?
Kai H.
Do you have an idea why, in Kotlin, lateinit doesn't work for "primitiv" data types like "Int"?
Mark M.
I think that has to do with how these things get mapped to the underlying Java types
a Kotlin Int maps to a Java int, not a Java Integer
Kai H.
Also, I read that Kotlin has no primitives, only classes, to then later read that lateinit doesn't support primitives X)
Mark M.
*Kotlin* does not have primitive types, but it *maps to* primitive Java types (for Kotlin/JVM)
Kai H.
I thought the standard was boxed, so it wouldn't matter.
Mark M.
I don't think so, but I'm not really a Kotlin internals guy
but, where we have Java primitives, we have Kotlin oddities (e.g., IntArray)
4:00 PM
Mark M.
so, I assume that the way they wanted to generate Java bytecode (e.g., for performance) led them to use primitives, and that led to a few problematic cases, like lateinit
Kai H.
Ok
We have a lot of "Up navigation" arrows in tool bars in our app and they usually go back to the main activity, which often feels wrong.
Mark M.
on the whole, "up" drives me nuts
Kai H.
For example when going into settings, then a subsetting, the "up navigation" arrow would leave the settings, going back to the main activity displaying whatever.
Mark M.
that does not sound ideal
4:05 PM
Mark M.
for most conventional in-app navigation, up and back often do the same thing
Kai H.
How is the whole thing meant to be? I feel that, most of the time, the "up arrow" (which points to the left) is supposed to do the same thing the "back navigation" of the system would do.
Only when you jump into an activity from the outside would the up arrow do something else, while "back navigation" would leave the screen again.
Mark M.
that's pretty much the story in a nutshell
now, really complicated apps might choose something else
Kai H.
I think that already answers my question.
Mark M.
but for most apps, up == back if it is all purely in-app navigation, and up perhaps != back when we are cross app boundaries
Kai H.
Ok
Mark M.
the primary in-app case where up might != back is search within a complex structure
for example, suppose we have an email client that tracks conversations and messages in a conversation
4:10 PM
Mark M.
and suppose that the UI has a list of conversations on one screen, a list of messages in the conversation on the next screen, and an individual message on a third screen
when flowing from the first to the third screen, up would be the same as back for returning
now, suppose that the app also has a search option
so, the first screen has a search option, and filling that in brings up a separate screen with search results, and tapping on a search result takes you to the message
in this case, up might not be the same as back
back from the message would take you to the search results
up from the message might take you to the conversation in which that message resides
Kai H.
I don't think we have any cases that would warrant such a thing.
But I understand the use case.
Mark M.
yeah, I suspect that most apps don't have a need for it
Kai H.
In "Exploring Android", page 220, you write to get a findNavController() by going "supportFragmentManager.findFragmentById(R.id.nav_host).findNavController()", but then the code example shows "findNavController()...) only. Why?
And what is the difference between those "findNavControllers"?
4:15 PM
Mark M.
what version are you looking at?
(of the book)
Kai H.
2.0 apparently
Mark M.
the snippet at the top has your supportFragmentManager.findFragmentById(R.id.nav_host).findNavController() syntax
so, when you write "but then the code example shows...", what example are you referring to?
Kai H.
The next one.
Mark M.
ah, OK
I'm not quite certain why those are different
it's possible that up navigation is broken there
Robert
has entered the room
Mark M.
I will take a look at that and try to clean it up in the next update
Kai H.
I think so too. I think I stumbled over this in my own app, using the shorter "findNavController()", which didn't work.
Mark M.
yeah, I probably didn't test up navigation :-(
thanks for pointing this out!
Kai H.
yw
Mark M.
and, as a reward... let me take a question from Robert, and I'll be back with you shortly :-)
Robert: hi! how can I help you today?
4:20 PM
Robert
Mark, hi!
4:20 PM
Kai H.
:*( ;-)
Robert
I would like to know if a view is currently visible. I have a NestedScrollView containing a ConstraingLayout. Somewhere in the constraintLayout I have another ConstraintLayout. I want to know if in onViewCreated of my fragment my inner ConstraintLayout is visible
Mark M.
by "visible", do you mean that it is on-screen, based on the scroll position of the NestedScrollView?
Robert
If I can see it on screen, I consider it visible. else it is not visible
Mark M.
OK, I just needed to confirm that you weren't referring to the standard visible/invisible/gone property of a view
Robert
I tried comparing to View.VISIBLE and calling isShown() but sometimes it tells me it is there and it is not
Mark M.
yeah, those are properties of the view itself and are independent of whether it is scrolled onto the screen
Robert
so without scrolling it is not visible but android says isShown is true or it is View.VISIBLE
Mark M.
that is expected
4:25 PM
Mark M.
however, I do not know of a recipe for readily determining whether a child is rendered on-screen or not
4:25 PM
Mark M.
partly, that's because "rendered on-screen" is a complex concept
for example, suppose that a single row of pixels from that view is peeking above the bottom edge of the screen
from a practical standpoint, that is not visible -- however, one could argue that it is visible, at least in part
Robert
sorry I didn't understand your explanation above "properties of the view itself". If a view's visibility is View.VISIBLE why can't I see my view
Mark M.
that property is better thought of as "it could be seen, if it is being drawn on-screen"
Robert
I tested it for a view that could not possibly be visible because I had to scroll a long time to see it visually
Mark M.
outside of scrolling containers, that property will map to what your eyeballs see
with a scrolling container, a view can be eligible to be visible, yet be scrolled off the screen
Robert
oh ok
Mark M.
to use a Web analogy, the previous lines of this chat that have scrolled off the screen are visible but are not being rendered in this scrolling viewport thingy
https://stackoverflow.com/q/4628800/115145
Robert
I see. So it is drawn so isShown() returns true and it is View.VISIBLE, but I have not scrolled to it yet
Mark M.
right
that link is for ScrollView, rather than NestedScrollView, though some of the techniques there may work
4:30 PM
Mark M.
a few of the answers specifically reference NestedScrollView
Robert
I tried that solution and it didn't work for me. Doesn't it to determine if an ENTIRE view is displayed via Rect? Partially visible if sufficient for my case
Mark M.
https://stackoverflow.com/a/37677667/115145
Robert
if part of my view is displayed I consider it
Mark M.
that particular example shows three outcomes: fully visible, partially visible, and not visible
Robert
ok thanks
Mark M.
I'd start with those -- I don't have a better recipe, as I have not had to worry about this problem personally
Robert
sure I can try it
Mark M.
on the whole, neither ScrollView nor NestedScrollView make this especially easy
let me take another question from Kai, and I will be back with you in a bit
Robert
sure!
Mark M.
Kai: back to you! do you have another question?
Kai H.
I didn't get the difference between "findNavController()" and "getSupportFrag.....findNavController()". Do you happen to know?
Both exist, but using the first one fails.
4:35 PM
Mark M.
it has to do with that FragmentContainerView
the first paragraph on that page contains a link to https://stackoverflow.com/a/59275182/115145, where Ian Lake posted the recipe for getting the NavController when you are using a FragmentContainerView
whatever algorithm the activity-level findNavController() uses under the covers, it can't find the NavController associated with a FragmentContainerView
which really feels like a library problem, but apparently they punted on trying to handle that seamless
er, seamlessly
as a result, my book has seams
Kai H.
Ok, thx.
Mark M.
it's one of those places where I really wish I had a better answer
I hate the sections of my books where I have to basically write, "OK, here we have some really goofy code, but that is what we need because that is what Google decided and ¯\_(ツ)_/¯"
4:40 PM
Mark M.
OK, let me take another question from Robert, and I'll try to get back to you before the end of the chat
Robert: back to you! do you have another question?
Robert
View paste 
Yes; I want to understand the definition of DisplayMetrics heightPixels: its documentation states "The absolute height of the available display in pixels". 


If I'm looking at an emulator, does that start at the top of the viewable area (top of status bar containing clock and battery) all the way to the bottom of the viewable area (top of hardware back and home buttons).
Mark M.
beats me, in part because the story is not even as simple as those options
split screen, free-form multiwindow, etc. make things even more complicated
Robert
sorry, story?
ok
Mark M.
I desperately try to avoid using DisplayMetrics for size information wherever possible
and so I forget the current DisplayMetrics rules
Robert
I'm trying to measure the height of a portion of my screen
Mark M.
"my screen" is a complex concept, taken across the entire Android device ecosystem
Robert
true. I guess I mean a standard portrait phone screen
Mark M.
Google's general advice has been: worry about the sizes of containers (e.g., a ConstraintLayout), not the size of the screen
4:45 PM
Robert
ok
Mark M.
if you specifically need size information related to the status and navigation bars, the window insets APIs can help there, though I have not used them personally
Robert
I'm trying to determine scroll depth as a percentage of my NestedScrollView. I see a y position is available and I want to divide by the visible height to get my percent value
Mark M.
wouldn't you be using the height of the NestedScrollView for that, though?
Robert
good point
trocchietto_Ivano
has entered the room
4:50 PM
trocchietto_Ivano
Hello
Mark M.
Robert: let me take a question from Ivano, and I'll see if I have time to get back to you before we run out of chat
Ivano: hi! how can I help you today?
Robert
sure. It's kind of complicated because I actually don't want my entire scrollable region but part of it.
trocchietto_Ivano
Hi Mark I am in a painful update from a clean architecture package going trough every kind of errors, but not need help, need to train a bit
just lurking
Mark M.
OK
at this point, if anyone has any questions, go ahead!
trocchietto_Ivano
mmh I do not get the selling point of Navigation
I saw also your guide, but AFAI Understand is just to have some navigation graph in the UI and to manage the EXTRA and back navigation right?
Mark M.
for new development, Navigation is not too bad as a way to structure a UI, particularly for newcomers to Android
trocchietto_Ivano
ah I see
thank you I understand is a tool to simplify
Mark M.
trying to convert an existing app to use Navigation is likely to be painful
trocchietto_Ivano
actually I do not like things under the hood
want to have granular control
Mark M.
and a very complex app might run into problems with Navigation
right
trocchietto_Ivano
yes is exactly what I wanted to do to show off some skills to my team
THANK YOU
Mark M.
um, you're welcome! :-)
4:55 PM
Robert
as a follow up my NestedScrollView contains a long ConstraintLayout. I don't want to calculate my scroll percentage based on my entire ConstraintLayout, but only say the first half. Can you recommend a strategy to do this?
Mark M.
um, divide the height of the ConstraintLayout by 2? :-)
more seriously, you are going to need to determine what "only say the first half" means in concrete terms
for example, if there is some widget that is your dividing line, you can find its Y offset within the ConstraintLayout
Robert
bad example; yea basically I want to calculate up to a certain view being seen on screen
ok yes
that's what I was looking for
I'll look into it; thanks Mark!
5:00 PM
Mark M.
OK, that's all for today's chat
the transcript will appear on https://commonsware.com/office-hours/ shortly
Robert
bye everyone
Kai H.
Have a good time
trocchietto_Ivano
have a good time everybody!
Mark M.
the next chat is Tuesday in the 7:30pm US Eastern slot
have a pleasant day/evening/whatever!
Kai H.
has left the room
Robert
has left the room
trocchietto_Ivano
has left the room
Mark M.
turned off guest access

← Thursday, February 11

 

Office Hours

People in this transcript

  • Kai H.
  • Mark Murphy
  • Robert
  • trocchietto_Ivano