Office Hours — Today, May 16

← Thursday, May 14

Mark M.
has entered the room
Mark M.
turned on guest access
Kai H.
has entered the room
Mark M.
hello, Kai!
Kai H.
Hello There
Mark M.
how can I help you today, while I yell at Android R?
Kai H.
Hehe
I have a strange bug with an EditText and the soft keyboard.
One Fragment with a TabLayout and a ViewPager2, serving three "child" Fragments
All of those have one or more EditTexts
Now if I click in one of those EditTexts, the soft keyboard comes up
And won't go away anymore, unless I go from the first to the third Fragment or the third to the first.
Mark M.
you mean the system BACK button/gesture does not collapse the keyboard?
Kai H.
There is some "Buttons" (ConstraintLayout views that serve as such) and clicking on those won't make it go away either
Those do work
But clicking on something else or going into another Fragment doesn't collapse the keyboard, which I'm pretty sure it should.
May 16
4:00 PM
Mark M.
typically it does
Kai H.
I can even click into an EditText in the second Fragment, go to the third, click a real button that opens up a Dialog and the keyboard will stay visible under the dialog
yes, typically it does and it totally should. But it doesn't in this case and I have no idea why.
Mark M.
it may be a matter of focus
give me a minute to run some tests
Kai H.
I think so too, but I don't understand why it happens. I have read about focus in your book(s) and played around with getActivity().getCurrentFocus() and requestFocus(), but that hasn't done anything either for me to understand the whole matter.
Mark M.
for example, I just fired up https://gitlab.com/commonsguy/cw-jetpack-kotlin..., one of my no-logic ConstraintLayout samples from *Elements of Android Jetpack*
it has an activity with a layout containing two TextViews, two EditTexts, and a Button
Kai H.
I can even produce a state where the usual "hideSoftINputFromWindow"-method of hiding the window won't work anymore.
yes?
Mark M.
OK, that's a little strange, though make sure you are using a valid window
4:05 PM
Mark M.
anyway, in that sample, once displayed, the soft keyboard does not go away on its own
even if I tap a label or the button
Kai H.
So it might be something with the ConstraintLayout?
Mark M.
conceivably, but I can't imagine how
similarly, in the Contacts app, I can tap on a "More fields" button, and the soft keyboard stays up
Kai H.
All my Vies are ScrollViews and/or LinearLayouts. The only ConstraintLayout is the "RadioButtons" on the first Fragment.
Does that also use ConstraintLayout?
Mark M.
I have no idea -- it's Google's app
it's just one that I had on this R device that I knew had EditTexts
when transitioning between activities/fragments, needing to manually collapse the soft keyboard is fairly typical
and frankly right now I guess I forget the rules for when it auto-collapses
Kai H.
It is? Huh.
I think I'll join your yelling, even though I'll just yell at Android in general, not a specific release...
Mark M.
the rules for those transitions are unclear, but let's just say that I have the hideSoftInputFromWindow() call in a utility function in every one of my client projects
because inevitably we wind up in a case where we transition from Foo to Bar and the keyboard doesn't go away
4:10 PM
Mark M.
it's one of those things that, to an extent, I gave up on trying to make sense of, and just settle for hammering the keyboard down when needed
Kai H.
Damn
Mark M.
in terms of your hideSoftInputFromWindow() failure problem... I haven't seen that
Kai H.
How is it that so many details in Android fail?
Mark M.
heinous complexity, I imagine
Kai H.
Or rather, that it has so many places where things don't work as they should.
Mark M.
also, bear in mind that "as they should", like beauty, lies in the eyes of the beholder
there are any number of things where my definition of "as they should" differs from Google's
Kai H.
Maybe it's the optimism of my youth, but I do imagine that one could formulate pretty universal rules about when the keyboard should hide and whe not?
Mark M.
oh, it wouldn't surprise me if there are such rules
it's just that those rules aren't what you and I might want
Kai H.
lol
Mark M.
I have a ton of "Works as Intended" tickets in the Google issue tracker that stands a testament to differences of opinions
Kai H.
When will "Android MME" come out? (MME = Mark Murphy Edition) ;-)
Mark M.
yeah, that's way outside my skill set
I settle for occasionally kibitzing with developers who do custom firmware
4:15 PM
Kai H.
Could you share your utility function to hide the keyboard with me?
Mark M.
your project is Java?
Kai H.
I have put our version into the onResume() of all three Fragments but the keyboard manages to stay open in certain circumstances.
ofc :D
Mark M.
let me see if I still have a copy of that in Java floating around somewhere...
4:20 PM
Mark M.
View paste 

  private void hideSoftInput() {
    if (getCurrentFocus()!=null && getCurrentFocus().getWindowToken()!=null) {
      ((InputMethodManager)getSystemService(INPUT_METHOD_SERVICE))
        .hideSoftInputFromWindow(getCurrentFocus().getWindowToken(), 0);
    }
  }
that's a method in an activity
this is from the *Exploring Android* to-do app, back when that book was in Java
Kai H.
It seems the problem is that after switching to another Fragment there is no View that has focus.
So hideSoftInput() won't do anything.
Thanks for the paste.
Mark M.
yeah, that might get interesting in your scenario
I usually try to call that function before the transition to the next screen, not after
in your case, you're not in charge of the transition
4:25 PM
Mark M.
you could try it in onPageSelected() of an OnPageChangeCallback on your ViewPager2, but that might be too late as well
Kai H.
Interestingly, on another phone it works consistently. There I do get a View with getActivity().getCurrentFocus(); all the time
Mark M.
device manufacturers do tweak the view system from time to time, though focus would be an odd thing for them to mess with
(one of the reasons why I am interested in Jetpack Compose: as a library, nobody can mess with it)
Kai H.
The phone that doesn't work is on Android 9, the other one on 7.
Mark M.
OK, so there could be OS version differences as well, and that's somewhat more believable for focus, though still a bit odd
Kai H.
On the phone with Android 7 it actually finds the RecyclerViewImpl having the focus
While on the phonne with Android 9 it finds... nothing.
Mark M.
that's strange, insofar as RecyclerView is from a library and I wouldn't expect its focusability to be different
Kai H.
view = androidx.viewpager2.widget.ViewPager2$RecyclerViewImpl{77a43ad VFED..... .F....ID 0,0-1440,1944 #4}
"View view = getActivity.getCurrentFocus()" comes before that
Mark M.
you could try setOnFocusChangeListener() on the EditText widgets and collapse the keyboard when they lose focus, if you only have one EditText per fragment
Kai H.
I have a couple
Mark M.
phooey
you might get in a collapse-vs.-show keyboard fight
4:30 PM
Kai H.
I was thinking something like that too.
So is the best solution here to quit being an Android dev and become a gardener? ;-)
Mark M.
that depends on whether garden centers are open in your state
Kai H.
They are not at the present time
Mark M.
that would put a bit of a crimp in gardening
have you tried other lifecycle methods in your fragments? I'
I'm not certain which ones all get called with ViewPager2
Kai H.
What that give me a View that has focus?
4:35 PM
Kai H.
I don't get the question tbh.
Mark M.
onResume() is kinda late
specifically, that is called when you gain the input focus
and touch events, etc. will get directed at your content
(at least at the activity level -- fragments, as with many things, get weird)
Kai H.
But that should be a good thing, as the chance of having an element that actually has the focus should rise?
Mark M.
no, because nothing necessarily starts with the focus
which is another route you could go: try to forcibly give something the focus
Kai H.
I was thinking into that direction as well
It would be a pretty ugly hack
But well
Mark M.
yeah, welcome to Android
Kai H.
How do you manage?
Mark M.
some days, I don't, to be honest
today, with my R problems, is one of those days
Kai H.
Is iOS similar?
Mark M.
but, while there are hacks needed for Android, there are hacks needed for every other platform I've worked on
I haven't done iOS, though from some people I follow on Twitter, it seems like they have their own set of hacks
anyway, back to your problem: the cleanest solution is to try to get a callback before your old fragment's UI gets torn down and the focus goes "poof", and hide the keyboard at that point
4:40 PM
Mark M.
in navigation that you control (e.g., user presses the X button and you navigate), that's easy to do
in your case... try other fragment lifecycle methods, or listeners on the ViewPager2, or listeners on the TabLayout, and hope
Kai H.
Well, I just tried adding a <requestFocus/> element to my layouts. That didn't do squat :D
Mark M.
yeah, I have had mixed results with that particular approach
but make sure you put it on something that is focusable
so, for example, if I understand your implementation correctly, your semi-fake radio buttons might not be focusable
Kai H.
I did put it in all on its own... X)
The actually have "clickable" and "focusable" on true.
Mark M.
also add android:focusableInTouchMode="true"
(focus management is another one of those areas of Android that was weak at the outset and didn't get a lot better)
Kai H.
It seems like it
One of those basic things that imo should just be there, but aren't
4:45 PM
Mark M.
well, focus is predominantly a keyboard thing, and Android isn't very keyboard-centric
I was surprised that they didn't overhaul the focus stuff when they started getting Android onto Chromebooks, though
Kai H.
You mean hardware keyboard centric?
Mark M.
yes, sorry
(and it's a bit ironic, considering that the first few Android devices all had side-slider keyboards...)
Kai H.
Very much so
When implementing something, I usually start with best intentions and a drive to make it nice and clean
And quite some time later, I arrive at "I just want it to work somehow."
4:50 PM
Mark M.
in the words of the great American philosopher, Mike Tyson: "everybody has a plan, until they get punched in the mouth"
Kai H.
"no plan survives contact with reality"
Mark M.
that too
Kai H.
Is there a donate button for you btw?
Mark M.
you subscribed! your donation was greatly appreciated! :-)
Kai H.
Well...
I surely got my moneys worth, having been at 7 or so office hours, 4 of which I had all to myself.
Mark M.
these used to be crazy-crowded in the early years
Kai H.
I really wonder what changed.
Mark M.
now, not so much, due to fewer subscribers and more support sources
4:55 PM
Kai H.
I do like having an expert to talk to
And I prefer books over having to assemble the information from different sources all over the place
So subscribing should have been the first thing after I started my job as a soon to be Android dev.
Mark M.
there are lots of books and online video options, and I don't have a marketing bone in my body
Kai H.
I hope you're still doing fine.
Mark M.
well, CommonsWare has gone from "side hustle" to "full-time-plus endeavor" to "side hustle"
5:00 PM
Kai H.
I guess you still will find a lot of work for quite some time ;-)
Mark M.
I suspect that I'll keep busy
but, that's a wrap for today's chat
Kai H.
thanks for the help
Have a good weekend.
Mark M.
sorry I didn't have a complete solution for you
you too!
Kai H.
has left the room
Mark M.
turned off guest access

← Thursday, May 14

 

Office Hours

People in this transcript

  • Kai Hatje
  • Mark Murphy