in my current project there’s an EditText with fixed layout_width and layout_height, called exercise
that is expanded downwards programmatically: One line of text (String) + "n"
is added to the EditText.
Sometimes the line added to the EditText, let’s call it element, is too long to fit inside the full width of the object so it’s splitted into a new line.
The thing is I would either like the lines’ text size in exercise
to be resized to fit the EditText’s width or have a clear visible distance between each line (element), but just not inside the newline due to not fitting inside the exercise
‘s width.
Therefore I googled as much as I could and tried out every possible solution I could find today.
What I tried:
- Using either
EditText
as the object andandroid:autoSizeTextType="uniform"
&android:inputType="textMultiLine|textCapSentences"
as attributes orandroidx.appcompat.widget.AppCompatEditText
, accompanied by the attributesapp:autoSizeMaxTextSize="28sp"
,app:autoSizeMinTextSize="8sp"
andapp:autoSizeStepGranularity="1sp"
(with a device that supports just exactly API 26) - using other types of text objects
- using
lineSpacingExtra
to insert some spacing. This unfortunately also inserted the spacing between the wrapped/ splitted line so the original element’s line that got splitted by wrapping inside the EditText had the spacing aswell.
That’s where I am now. I can’t get the text size be reduced automatically when the line would be too wide for the EditText’s width.
I could supply the full XML, if needed.
I’m grateful for any hint that could help here. Thanks in advance!
2
Answers
you can try something like this
Here’s a really basic
RecyclerView
implementation (using view binding, let me know if you’re not familiar with that – you can justfindViewById
all the things instead):It’s pretty simple – you have a text entry field and a button to add the contents as a new line. The button passes the contents to
addItem
on the adapter, which appends it to the list of lines indata
. TheRecyclerView
just displays all the items indata
, using aViewHolder
layout that has an auto-sizingTextView
to scale each item.Ideally you’d want to persist
data
somehow (e.g. the Add button passes the new data to aViewModel
, stores it somehow, updates the current list which the adapter hasobserve
d so it updates whenever there’s a change) – I just left it as a basic proof of concept. Also, it’s easier to store separate items if they’re kept separate – you can always serialise it by joining them into a single string if you really want! But generally you wouldn’t want to do thatedit – since you’re having trouble with the
setTypeface
thing, this is all it is:The logic is just styling alternate items differently, but hopefully you get the idea. You decide how to style a given item depending on what it is, and then you apply that style by setting attributes as appropriate. It’s always an "if this is true do A, otherwise do B" situation, so you’re always setting the attribute one way or the other. You never only set it for one case, because then you’re leaving old state displayed if it’s not that case.
It’s more complicated, but you also have the option of creating different
ViewHolder
s (with their own XML layouts) for different kinds of item. So instead of having a singleViewHolder
that has to work with everything, where you have to reconfigure things like all the styling inonBindViewHolder
depending on which type of item is displayed, you can just have differentViewHolder
s with different styling, different layouts etc:(You could be a bit more clever than this, but just to illustrate the general idea!)
That’s using the same
item_view.xml
as before, and aheader_item.xml
variation on that (but you could have literally anything, they’re completely separate layouts, completely separateViewHolder
s):So instead of having to "redesign" one
ViewHolder
in code to go back and forth between different item types and their styling, You can just use two differently-styled layouts. It’s a bit more work to set up, but it can be neater and much more flexible when you have completely independent things – especially if you want to give them different functionality. It depends whether it’s worth it to you, or if you’re happy to just have a singleViewHolder
and restyle things in code, hide or show elements etc.