Office Hours — Today, June 30

← Sunday, June 28

Jun 30
8:25 AM
Mark M.
has entered the room
Mark M.
turned on guest access
Marek D.
has entered the room
Mark M.
hello, Marek!
how can I help you today?
Marek D.
hello :)
you know I have this custom keyboard ...
1st question loosely related
if I read attributes from xml
obtainStyledAttributesm then getString on TypedArray
the linter gives me warning to recycle this array
what would be the best way to do it
try {} finally { ta.recycle}
there is ktx extension use
https://android.github.io/android-ktx/core-ktx/...
which does not do finally
Mark M.
did you check the implementation?
8:30 AM
Mark M.
yeah, they didn't use try/finally: https://androidx.tech/artifacts/core/core-ktx/1...
that's disappointing
Marek D.
there is an issue but closed
https://github.com/android/android-ktx/issues/193
Mark M.
of your two choices, I would be happier with the try/finally one
Marek D.
I understand that exception there is a serious bug, so maybe is better to crash the app
but you always can catch it higher
Mark M.
but then use() is pointless
because you still need to manually recycle() the TypedArray
(in the finally block)
Marek D.
right
and if I have multiple values to read from TypedArray
8:35 AM
Marek D.
I wonder If I should wrap each call to tpedArray.get*
Mark M.
well, you do not have to rely on the return value from use()
I would put all of them in a single try block, with a finally that recycles
Marek D.
well if some attribute is not read correctly I guess the whole view is not usable
Mark M.
yes, but then the answer is to gracefully exit the activity/fragment that is using it, not crash the app
though, in that case, the try/finally would need to reside somewhere else
this is one of the reasons why I'm not a fan of custom views -- there are too many levels of indirection
Leora
has entered the room
Mark M.
which makes this sort of exception handling difficult
let me take a question from Leora, and I will return to you in a bit
Leora: hi! how can I help you today?
Marek D.
go ahead
Leora
Hiya Mark!
I was wondering which is faster
8:40 AM
Leora
to have a regular txt file, parse it once into a hashmap, and then look up the values by key
or xml string file and search for the string
Kai H.
has entered the room
Kai H.
Hi everyone
Leora
Hi Kai!
Mark M.
Leora: I do not understand the second one -- do you mean literally searching an XML string? or do you mean parsing the XML like you were proposing to do for the text file?
(BTW, hello Kai!)
Leora
literally searching for the R.string.x
Mark M.
but, then, how would you get the corresponding value? manually grab it out of some MatchResult from a regex?
Leora
i don't understand
Mark M.
it looks like you are trying to find the value associated with a key
leastways, that is what your first scenario was ("look up the values by key")
Leora
ahhh sorry i got confused
the xml option is an array of strings
8:45 AM
Mark M.
then, what are you looking for in the array? just a boolean of whether the string exists? are you looking for an index into the array? something else?
Leora
so i pull the array and have a for loop to find the string
Mark M.
so, you are parsing the XML
Leora
only if it's found in the list yes
yes
Mark M.
in your original scenario, you parsed the text file once and held onto the results for multiple lookups (as I understood it)
is that what you are doing in the XML scenario as well? or are you proposing re-reading the XML each time you need to do a lookup?
Leora
let's say i do that once as well
Mark M.
in that case, the two variables are: how efficient is the parsing, and how efficient is your resulting data structure
Leora
:)
Mark M.
using either data representation (plain text vs. XML), you should be able to organize the results into a data structure that works well for whatever your lookup needs are
there is nothing intrinsic about XML parsing, for example, that says you need to live with some inconvenient data structure in the end
so for "how efficient is your resulting data structure", they should be equivalent, because they should be the same data structure
8:50 AM
Mark M.
in terms of whether parsing a plain text file vs. XML is faster, you would need to benchmark that
Leora
ok thanks Mark
Mark M.
I can see arguments either way
sorry that I did not have a clearer answer for you!
Leora
ok then i won't worry about it :)
Mark M.
let me take questions from the others, and I will come back to you in a bit
Leora
that WAS clear
Mark M.
Kai: over to you! how can I help you today?
Kai H.
If Marek has a question atm, I would let him go first
Mark M.
he was in first, so he already had his first question
Kai H.
Ok
Mark M.
I can still switch back to him if you like, but you are next in rotation
Marek D.
I have question :)
Kai H.
What is the current approach to multi pane ui?
Mark M.
you mean like the master-detail pattern?
Kai H.
I guess?
Opening a new Fragment on the phone but show the Fragment "in-place" on a Tablet
Mark M.
see the images here: https://stackoverflow.com/questions/11773433/an...
Kai H.
That is what I mean
Mark M.
(they aren't the greatest, but they are what is coming up quick in a Web search)
Kai H.
Yes :D
Mark M.
Google has been backing away from that pattern, mostly because they want a seamless UI transition for resizeable windows (e.g., on Chrome OS)
Kai H.
Would you still have different layouts for the different cases and then simply decide in code which way to go?
Oh, ok
The app I'm maintaining relies heavily on that for tablet :D
Mark M.
and, IMHO, there is nothing wrong with it
8:55 AM
Kai H.
A list on the left, Details on the right.
I agree. It seems quite sensible, given the screen space. I actually prefer our app on the tablet for that reason.
Less switching back and forth between screens.
Mark M.
I agree with Google's concern about resizeable windows, but that's just not a case that developers care much about, on the whole
the classic approach to master-detail involved layout resources for the different screen sizes
so, for example, suppose it is at 800dp current width when you want to switch from "phone UI" to "tablet UI"
in res/layout/, you would have a layout for the activity that had a pane for a single fragment
in res/layout-w800dp/, you would have the same layout, with panes for two fragments
Kai H.
Ok, so that still holds
And then decide in the code which one to load?
Mark M.
in Java/Kotlin, after inflating the layout, you would see whether you have the second pane, and react accordingly, both for the initial screen population and then what happens when the user clicks on a list item
while the code is older, I have a chapter on this in *The Busy Coder's Guide* that goes through a number of implementation approaches
(and, that chapter will still use "master-detail" as the name, for historical reasons, though we really need to come up with another term for that...)
Kai H.
So I guess our app is still current in that regard. I was just wondering if something more "automagic" has come along in the meantime, where you don't need to differentiate in code how to load your second pane.
Mark M.
nope
it's possible that the Navigation component has some stuff to simplify this
Kai H.
I actually had a look into busy coders guide for that :)
9:00 AM
Kai H.
Heh, we are quite a bit away from using something as modern as that ;-)
Mark M.
let me take questions from the others, and I will come back to you a bit later
Kai H.
I guess that answers my question. Thanks.
Mark M.
Marek: back to you! I think you said that you had another question!
Marek D.
yes, I would like to have autoSizeTextType behavior
in EditText
Mark M.
I have not tried that, but since EditText extends from TextView, I would have hoped that "it just works"
Marek D.
unfortunately :\
Mark M.
what are the results? is it basing the font size based on the initial EditText contents?
Marek D.
I also want singleLine behavor
I am wonder how can I share screenshot
the EditText goes into multilinemode
Mark M.
in the column on the right, towards the bottom, there is "Upload a file"
Marek D.
ok I see it
https://prnt.sc/t95c0s
it seems my screenshot software has the possibility
Mark M.
in terms of the multiple lines, do you have android:maxLines="1" in the <EditText> element?
Marek D.
View paste 
        android:lines="1"
        android:maxLines="1"
        android:minLines="1"
9:05 AM
Marek D.
View paste 
        android:autoSizeTextType="uniform"
        android:autoSizeMinTextSize="5sp"
        android:autoSizeMaxTextSize="33sp"
        android:autoSizeStepGranularity="2dp"
Mark M.
that feels like a bug
I can see autosize not working dynamically based on text entry, but it should not somehow break the line count limits
Marek D.
View paste 
<!-- Specify the type of auto-size. Note that this feature is not supported by EditText,
        works only for TextView. -->
        <attr name="autoSizeTextType" format="enum">
Mark M.
well, that's disappointing
Marek D.
View paste 
<!-- Makes the TextView be at most this many lines tall.

        When used on an editable text, the <code>inputType</code> attribute's value must be
        combined with the <code>textMultiLine</code> flag for the maxLines attribute to apply. -->
        <attr name="maxLines" format="integer" min="0" />
I just noticed that
but since I want single line
I guess textMultiLine is not needed
Mark M.
I have not needed that for single-line input in the past, but perhaps I am mis-remembering
Marek D.
Ok I guess I need to find a library for that
Mark M.
if you mean autosize for EditText, you can try
I suspect that you will be out of luck
Marek D.
unless maxLines lines is a big
bug
Mark M.
if you remove the autoSize* attributes, does the single-line behavior work?
Marek D.
no it does not
9:10 AM
Mark M.
that's very strange
Marek D.
https://stackoverflow.com/questions/10978038/re...
inputType=text
solves it
so now it has singleline behaviour
Mark M.
OK, that matches my experience
but I do not have a solution for you for autosize -- sorry!
Marek D.
sure no problem
I pass the token
(for the next person)
Mark M.
next in our "token ring" is Leora... Leora: do you have another question?
Leora
yes, follow up to before and layout q
so in the case i need to look up a string from the resources, i assume it is more expensive than searching for the key-value from a hashmap?
Mark M.
by "look up a string from the resources", do you just mean getString(R.string.whatever)? or do you mean something else?
Leora
yes getString
Mark M.
resources are cached by the framework
I do not know the details of exactly how string resources get cached
Leora
oh!
Mark M.
but there should not be incremental I/O for additional getString() calls
Leora
oh nice
Mark M.
so, unless you are doing thousands of these things, I suspect that speed is not going to be a major deciding factor
Leora
ok cool
may i ask the layout q?
9:15 AM
Mark M.
if it's quick, go ahead
Leora
I have a bottom toolbar i built with constraintLayout
it goes past the left and right boundaries of the screen on a few devices
a
as in, the left and right icons are cut off
Kai H.
I don't have anymore questions btw, so she can have the remaining time if it comes to me
Mark M.
(Kai: OK!)
Leora
i advised with someone who said they hate constraint (don't feel the reason for it), and told me to put it in linearLayout
LL works perfectly of course
Mark M.
then CL could handle it, but there was something off in your constraints, most likely
Leora
but i've come to love constraintLayout and feel like I'm not 'getting' something if it doesn't work
like what? it's a very basic bottom bar, match-parent width, fixed height
Mark M.
how are the icons set up? if the bar itself is a CL, did you set up a chain for those icons?
Leora
yes
Mark M.
OK, then I am really surprised that the chain somehow went over the CL boundaries
you said that the bar is "match-parent width" -- what is the bar inside of?
Leora
View paste (5 more lines) 
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:id="@+id/toolBarLayout"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:layout_width="match_parent"
    android:layout_height="@dimen/toolbarHeight"
    android:background="@color/colorPrimary"
    android:paddingTop="@dimen/toolbarLayoutMarginTop"
    android:paddingBottom="@dimen/toolbarLayoutMarginBottom">


    <ImageView
        android:id="@+id/toolbarLogo0"
        style="@style/ToolbarItemStyle"
        android:layout_marginStart="15dp"
...
Mark M.
I am guessing that you are using <include> to pull that into another layout
9:20 AM
Leora
it's inside a frameLayout with math-parent
since it is loaded dynamically
(switched out at runtime per lite or full)
the frameLayout is part is inside CL
Mark M.
so, you are inflating this toolBarLayout yourself via a LayoutInflater?
Leora
yes
Mark M.
do you have a device that reproduces the problem? or is this just coming from reports from users?
Leora
emulators yes
Mark M.
then I would check to make sure that the LayoutInflater logic is working as expected and that its FrameLayout container is also working as expected (not overflowing the screen)
Leora
hmmm
Mark M.
neither of those would explain why a LinearLayout works where the ConstraintLayout does not
Leora
right
Mark M.
but it would be where I would look for debugging purposes, at least as a starting point
Leora
most pixels it looks perfect
Mark M.
rolling back to the advice that you were given, LL has a worse reputation than is warranted
so IMHO if you wanted to use a LL here, that should be fine
but a CL should be able to handle the situation, and if it cannot, that is probably a bug
Leora
ok, but how can i check if FL is overflowing? i need to have images in it....
Mark M.
Layout Inspector in Studio would be one possibility
9:25 AM
Leora
i used to love LL, just trying to be a good ANdroid soldier as usual
Mark M.
or, toggle on the view-bounds stuff in Developer Options to draw boxes around everything
the problems with LL come in when you have lots of them in a scrolling container
Leora
hmmm ok
Mark M.
for a fixed-position toolbar, LL's performance issues won't be a problem
Leora
i see
great I'll test away then Mark
Thank you!
Mark M.
OK, we're running out of chat time -- if anyone has any final questions, fire away!
Kai H.
Why does my AlertDialog title have a low contrast on some Samsung devices? :D
Mark M.
only on some devices? your activity theme should be controlling that, assuming you are creating the AlertDialog using an Activity as your Context
Kai H.
Hm ok
Thanks :D
Leora
Have a great day everyone!
Marek D.
thank you for the chat
Kai H.
Same
9:30 AM
Mark M.
OK, that's a wrap for the chat, then!
next one is Thursday in the 7:30pm US Eastern slot
have a pleasant day, and stay healthy!
Marek D.
has left the room
Leora
has left the room
Kai H.
has left the room
Mark M.
turned off guest access

← Sunday, June 28

 

Office Hours

People in this transcript

  • Kai Hatje
  • Leora
  • Marek Defecinski
  • Mark Murphy