Hello

hello, Kai!

how can I help you today?

I have so many questions :D

For example about sharing encrypted content, as in this question: https://stackoverflow.com/questions/60256293/fi...

hey, those comments look familiar... :-)

I am a bit astounted that google offers no reliable way to provide content to the outside, especially given that they now promote data encryption in jetpack: https://android-developers.googleblog.com/2020/...

Yes, thanks for the comments :)

I was just wondering if my case is so special that it's just not needed?

I would phrase it more as: your case is not yet common

the AndroidX Security library shipped less than a year ago, IIRC

so, their focus was on in-app use of the encrypted data

And it was in beta when I started using it

right

while we like to think of Google as having this vast army of developers, it is a smaller group than you might think

Still, providing streaming content was a thing for some ppl. I read one SO question about providing "mingled" files in an unmingled version.

one hopes that they will offer their own FileProvider + Jetpack Security solution

Then again, with the way file handling is going, this might not be needed anymore in the somewhat close future.

if anything, using a ContentProvider to share content will become more important

and that would always have been a requirement if that content were encrypted

my point is that Google can't solve all problems at once

Sure. I do expect a lot of them ;-)

I am sure that you are not the only person with this itch, and somebody -- in Google or outside -- will scratch it eventually

or, perhaps you will scratch that itch yourself, if you choose to

I would not know how, actually.

I was thinking about that. How I could implement something like a "seekable ParcelFileDescriptor" or a similar solution.

theoretically, you could use: https://stackoverflow.com/a/60564953/115145

as I note in my comment on that answer, I did not have a lot of luck working with ProxyFileDescriptorCallback when I tried it three years ago

but, perhaps others have figured out how to make it work from Java/Kotlin better

the problem that you are trying to solve -- or at least the read-only side of it -- is one that I have poked at off and on for 6-7 years

I think I have stumbled upon this question before in my search and didn't really take it into consideration as an answer

well, that answer just showed up yesterday, as it turns out

it's one of the reasons I was able to get the link for it so fast :-)

I see

I think I'll have a look at it at work next week.

I am a bit satisfied with knowing that I have the somewhat optimal solution for the time being.

read-write, in particular, is a difficult problem

I started as a junior developer around 8 months ago and there are a lot of difficult problems ;-)

if you have gotten as far as your SO question suggests, you have already gotten further than a lot of senior developers might

Well, I actually "inherited" a Java app.

So I am just poking and extending, but I couldn't write a basic app myself

still, I suspect fewer than 5% of Android app developers have worked with ParcelFileDescriptor, for example

I see

I do try to build an app in my spare time, to better learn and grasp the fundamentals and to get up to the current developments.

One thing I recently stumbled over was a somewhat simple way to implement concurrency.

I wanted to get a list of chapters from a website and display them in a list.

I ended up using normal Threads, but it feels kinda messy.

a lot of modern Android app development focuses on "reactive" frameworks for concurrency: RxJava and, if you are using Kotlin, coroutines

I am still using Java, because that is what I use at my job

And I wanted to do a simple solution first, before diving into RxJava or something similar

one could argue that there are no simple solutions with concurrency, only "this hard thing" and "that hard thing" :-)

But trying to make it simple might have maded it more complicated ;-)

Good point. So I guess going into RxJava might be a good idea, even at the start?

um, well, RxJava definitely has a learning curve

But if there are no better "simple solutions", then I will need to use it, I guess

Or dive into kotlin right away as an alternative (given that coroutines are easier to grasp)

"right away" is a strong phrase, but eventually you will want to learn Kotlin and coroutines

for the purposes of a weekend experimental app, whatever you are doing with threads may be sufficient for your needs

you aren't being judged on what the code is, or even what it does

you are judging yourself on how comfortable you feel with Android app development, if anything

I do judge my code myself

And my current solution just feels icky. Having a "runOnUiThread" with an anonymous Runnable() in my MainActivity is not what I imagine good architecture looks like ;-)

I would describe that approach as "vintage" :-)

in the early days of Android app development, that sort of approach was common

we have been improving, but slowly

According to the google docs one should now use "java.util.concurrent" for background stuff.

To replace AsyncTask in Java

they probably are referring to various forms of Executor

and Executor does not know anything about Android's main application thread

so you would need to pair the Executor with something that does

for example, you might have an Executor-based thread expose its results via LiveData

and have your activity or fragment observe the LiveData -- all observed messages get delivered on the main application thread

I think I just realized what my problem is. I do initialize an RecyclerView.Adapter in my MainActivty and later need to call "notifyDataSetChanged" on it

Do you think one should start with such concepts earlier than later?

LiveData I mean, and RxJava

LiveData on its own is not particularly complicated

Because I tried to keep my private app as simple as possible and have it grow in iterations, learning on the way.

I cover the use of LiveData in *Elements of Android Jetpack* -- it is a pretty foundational piece of Jetpack-based app development

I think I'll have a look then and will refactor my app using it

Thanks for the books btw

thanks for subscribing! :-)

as Google leans more into Kotlin and coroutines, expect that LiveData will change or be replaced by something more coroutine-based

but, LiveData will still be relevant and usable for a few years, at least

And I guess understanding the concept and thinking about why it exists will remain

most likely

the main application thread will still be "a thing"

and configuration changes are likely to still be around in some form as well

those are the problems that LiveData helps to address

As I maintain and extend the app at work, I am constantly overwhelmed by it, in different dimensions

There are a ton of Android concepts I do not yet know

And a lot of them are used in strange and mysterious ways

yup, sounds like Android app development :-)

Also, because it is rather old, there is lots of AsyncTask, jumping around with "onPostExecute", hard to follow inheritance and the like

maintaining older code in a swiftly-changing platform is challenging

And I have two problems with that: It's really hard to understand, making my job very challenging and frustrating sometimes, and it's really old, lowering my worth as an app developer.

Do you have any best practices on dealing with legacy code?

== code you didn't write, that has a certain complexity and is thoroughly undocumented.

umm... I'm a fan of Excedrin for headaches :-)

I see

but, more seriously, that's as much a discussion to have with your team as with an outsider like me

Well, I am my team

oh, I assumed that the "inherited" reference meant that this was something that a team was maintaining and that you joined the team

The guy who wrote the app is my team lead, who I can fortunately ask, but unfortunately he has kinda little time.

Nope. It's mine now :D

OK

in that case, ideally, you budget X% of your time addressing "tech debt", replacing the older approaches with newer ones

your problem, since you are new to Android, is that you are still coming up to speed with the older *and* the newer approaches

Exactly

and for that, there is no great solution, other than patience and fortitude

I feared as much

That is why I started a personal project, to get experience with newer solutions as well

that's a fine plan

and, if there is an opportunity for you to work on a "green field" app at work, consider trying to do so

I would like that, but at the same time I fear it, as there is so much to do wrong

there are two types of "wrong": it is wrong for the user and it is wrong for you

the focus should be on avoiding "wrong for the user", and fixing it when it crops up

"wrong for you" merely means that things become "tech debt" faster than you would like

that's fairly common when learning a new technolgogy

er, technology

I do focus on architecture quite a bit, which might be more of a hindrance at the start

Especially if one has very little experience and probably don't know yet what good architecture looks like ;-)

also, bear in mind that what constitutes "good architecture" changes with time

I guess "make it work" first and "make it good" later does apply when starting?

when you are learning? sure

I mean, where practical, try not to do things intentionally awful, but don't worry about whether the architecture is perfect

because today's perfect architecture is tomorrow's tech debt

right now, "good architecture" means "does it's worke somewhat well" and "is extremely readable" to me

that's not a bad target to aim for

over time, you may change your mind as to what you like, and that too is perfectly normal

I mean, I cringe when I look at some of my book examples from my first-generation books

I might also change my mind on what "extremely readable" is ;-)

I know the feeling

But there is also code I am still kinda proud of

So I guess I'll focus more on making the code work and less on how the underlying architecture is for now

And I guess replacing tech debt at work will have to wait until I know *how*

you may already know how for some things

and, at the risk of sounding self-important... you could do worse than reading *Elements of Android Jetpack* or *Exploring Android* to see how modern development works

I do have ideas, but I have trouble understanding the old code entirely

I am already having those books open and am reading them :D

cool! they should help show how the various Jetpack pieces plug together

One thing I stumbled over was that the books seem to be going into a similar direction

Bot for beginners, both about building an example app

*Elements of Android Jetpack* is a traditional programming guide, and shows both Java and Kotlin

*Exploring Android* is tutorial based, and only shows Kotlin

I see

but in terms of technology, they cover the same ground

it's merely a matter of how you prefer to learn

I remember being confused when reading into one and then the other, thinking "isn't this what the first book does as well?"

And trying to find out the difference between them

I think I covered the differences in the prefaces

if I didn't, I need to fix that

I will have to read them again (or for the first time, might have skipped in one case)

Nah, you have it covered

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

the transcript will show up in https://commonsware.com/office-hours/ shortly

Thank you for your time

you're welcome!

the next chat is Tuesday at 8:30am US Eastern

have a pleasant day!

Same