Hello

hello, Kai!

how can I help you today?

I was wondering if there is a premade solution for "editable TextViews", TextViews whose text the user can select and that turn into an EditText, preferably with some "save/cancel" type of buttons.

it's possible that the Android Arsenal has a library for that

By premade I mean preferably by google :)

I am not aware of a Google-endorsed option

Do you use anything like I described in any product?

no, sorry

I have seen the question pop up from time to time in Stack Overflow

So it's not a much used thing in the Android world?

I don't see many apps going that route

and, it's not hard to implement, if you wanted it

Do you have an idea why few apps go that route?

It seems quite useful to edit in place

Instead of opening a dialog or a new view just for some simple text.

to me, the bigger question is: when are you actually committing the change, and to what scope?

few things are *just* a piece of text, after all

I don't really get the question

so, if you have a screen with various bits of text, and they all have pencil icons to allow you to edit them, when do you save the changes? as each one gets submitted? when the user exits the screen? sometime else?

I think the pencil icon would turn into two icons, save and cancel

And only one of the bits of text can be editable at a time

And each one gets submitted when it's saved or canceled.

But how do you control the "only one is editable at a time" state?

And what if the user edits some text, then doesn't save it and exits the screen?

presumably, your hosting activity/fragment is keeping track of what is editable

so, in terms of "only one is editable at a time", if there is an already-editable item when the user goes to edit another one, the activity/fragment could cancel the original item

That seems like a lot of state that needs to be held :D

well, it's your proposed UX -- don't shoot the messenger :-)

in terms of "then doesn't save it and exits the screen", typically if you have a positive "submit" option, then exit implies "cancel"

I am just thinking loud

Btw, do you use material design a lot?

well, that depends on what you mean

It seems to have textfields with some edit functionality, even though not exactly as I wanted: https://material.io/develop/android/components/...

the stock widgets in Android use Material Design "out of the box"

OK, you are referring to Material Components for Android

I don#t really get the difference.

Material Design is the "design language" describing what a UI could look like

it is independent of any particular platform

Google, for example, uses it for Web and Android

Material Components for Android is a specific library that implements part of the Material Design specification, particularly for things "over and above" what Theme.Material offers in Android itself

So why is there "material design components" when it's already applied to the stock widgets in Android?

because Android only bothers with a small subset of Material Design elements

You answered before I questionered ;)

for example, Material Design has a "snackbar" UI element

Android does not have that, but Material Components for Android does

on the whole, particularly for UI stuff, Google is getting away from having much of that in the framework and is more delegating it to libraries

why Material Components for Android is separate from the Jetpack stuff is a mystery to me

I was about to ask that :D

Material Components for Android is based on Android's classic view-based UI system

It's a bit of a shame that Android is so fragmented; that there (have to be|are) so many libraries and so many ways to do something.

well, some of that is simply a mix of age plus rapid development

the UIs from Android 1.0 look, um, crappy :-)

I remember X)

as phones got more powerful, particularly in terms of GPUs, and we as an industry learned more, we built better options

but, backwards compatibility is a pretty big deal

and that's why you wind up with all this layered stuff (framework -> AppCompat -> Material Components for Android)

that's also why Google is trying to replace the view-and-fragment UI system with Jetpack Compose, so we can jettison a lot of this historical baggage

Will Jetpack Compose dispose of View and Fragment?

mostly, yes

I can't even imagine :D

fragments may stick around for a bit, while we work out how best to route from screen to screen in a Compose-centric app

That is actually the other question I had for today: I know some ppl avoid fragments like the plague. Why is that?

well, in the early days, fragments were kinda buggy

and, since the focus was on using the framework implementation of fragments on Android 3.0+ devices, you couldn't get away from those bugs

that improved over time, of course

and now, the framework fragments are deprecated, with the library implementation being the official one

but, all those blog posts from the earlier days are still out there

so, while fragments now are about as stable as they're going to get (and are fairly decent overall), some will avoid them because of the earlier problems

I didn't even know that Fragments are in a library of their own (now)

And wonder which version we use in our app.

if the import is android.app.Fragment, that is the framework edition

if it is something else, in the androidx or android.support packages, then it is coming from a library

I see

It's funny how you alternate between "Android programming is fun!" and "Android programming is contrived and hard" in your books btw ;-)

yeah, well, "contrived and hard" frequently is the outcome of a long series of decisions that left us in a weird place

But it's being worked on to get some of that out of the way

Even though we might end up with components called "ViewPager2" ;-)

in some cases, yes, such as Jetpack Compose

in other cases, such as the whole "scoped storage" mess, will remain a mess

There's no news on that?

news on what?

scoped storage

well, Android R is shuffling the deck again, somewhat

in a nutshell, READ_EXTERNAL_STORAGE works again

(at least, mostly)

so for some apps, they are going to need to deal with messy stuff just for Android 10 -- code that worked for Android 9 might work on Android 11

Grrr

That can be quite frustrating.

so, some things improve with time, and some... just get weird

Luckily we have ppl working out how stuff works, like you, and write blog posts about it.

yes, and there are a lot more such people now than in the early days, which helps

which means we're about due for a major problem, like Medium going out of business, or a pandemic, or...

:-)

Murphys law? ;-)

story of my life

How many ppl work on Android?

You once mentioned that the Android team is smaller than one would think

(And I also wonder why that is the case. It's not like google doesn't have money).

it's probably bigger now then when I last made that statement :-)

I think that was three weeks ago

OK, I don't remember making that comment that recently, though I have definitely said it a few times over the years

and it also depends a bit on how you want to define "work on Android"

so, for example, a lot of the people that we see are in developer relations

how much they contribute to core Android stuff varies by engineer

conversely, a lot of the engineers we rarely see, because they don't deliver Google I|O talks and stuff

but, in the early years, it was a pretty small team

Ok

as in "could probably fit in a good-sized conference room" sort of small

How big is it nowadays?

I have no way of offering a number

but my guess is over a 100 now

That doesn't seem like a lot

For such a big and widely used system.

partly, it's where you draw the lines, and partly, it's because some stuff is not done by Google

there are device manufacturers, and JetBrains, and just ordinary developers who pitch in on AOSP, and...

Ok

I didn't know Jetbrains is actively working on Android too

well, they work fairly closely with Google on Kotlin with respect to Android

plus, Android Studio is built on top of IntelliJ IDEA

Well sure, if you take that aspect

I was thinking about Android as a Framework. But yea

and that's part of the problem: where do you draw the lines?

for example, I suspect that there is a team that is purely focused on working with major hardware vendors, from Qualcomm to Samsung and so on

leastways, I assume there has to be such a team

but, they aren't working on framework classes, though they might be contributing some to the lower-level OS stuff

Huh

and I haven't the foggiest notion whether that team is 50 people, 5, or one person working part time

(though probably not that latter one)

I hope not :D

So much we don't know

Thanks for your insights

sure!

and, that's a wrap for today's chat

next one is Tuesday at 8:30am US Eastern

Stay health and have a good time

you too!

thx