Hello

hello, Kai!

how can I help you today?

I am using the Glide image loading library in my application and have "abstracted" the call via a utility method.

Something like "setCroppedImage(...)" with parameters for the View to load into, the image, fallback image etc.

But I am not completely satisfied with this and wonder if I can abstract in a better way

How would you do it?

off the cuff, I don't know that I would do it at all

if I felt the need... I'd probably use a top-level utility function or perhaps an extension function on a Glide object

The reasone I abstracted it was that Picasso was used before so I had to find all the places where it was used and replace it with the appropriate Glide calls.

We're talking Java btw.

OK

why did you switch from Picasso to Glide?

there's nothing wrong with doing that, of course, but AFAIK Picasso is still supported and still works fine

Because I needed to support image loading via InputStream and Picasso doesn't support that in any way as far as I know.

it has a pluggable API, and a quick search is turning up blog posts and Stack Overflow answers on how to implement one for InputStream

but, anyway, if you've already converted, you're fine

Then my memory failed me :D

anyway, back to your function...

Maybe it was that I was loading images via an internal ContentProvider (our own FileProvider) and Picasso wouldn't work because it failed with non-seekable file handles.

I'd actually have to go look into my notes at work why I replaced it :D

that's a possibility -- that sort of problem has been a long-standing thorn in my side

Glide has a reasonable terse builder API: Glide.with(fragment).load(url).into(imageView);

Yes, and I tried to emulate that with my own functions, but didn't really know how

if the utility method can add some smarts, and you need those smarts lots of places, then perhaps it's useful

that's beyond what simple methods can do -- you would need to create dedicated builder classes to replicate that sort of API

It actually doesn't. Its only job is to not have to go to all the places again in case I have to replace Glide by something else.

I can "just" replace Glide behind the helper methods.

and if you feel that was worth creating the function, that's a perfectly fine reason

but then whether you abstracted it well or not is really up to you

I am actually not sure, as I really like the builder API and my function (or rather functions, as I have several of them) seem kinda clunky

And don't tell which parameters are passed at which position etc.

all that will be solved when you move to Kotlin :-)

I really wish Java (8) had named parameters or something to make the "builder style" work with normal methods as well

hehe

I think they added that to one of the later Java versions, but that won't help us on Android for a while

Which will probably never happen, as my company 50% Java and 40 % Javascript

+uses

I dunno, that remaining 10% has hope!

And 10 % .NET and such

oh, well

But I am really eying Kotlin for things like Coroutines and such

Might give me a way out of AsyncTask hell and too many inheritance layers

more importantly, it's Google's long-term direction

some things simply won't ever be available for Java, such as Jetpack Compose

It's a long way until I can even use something like that

sure

For now I am doing tons of Fragments and deep hierarchies of LinearLayouts etc.

fragments: good

deep hierarchies of LinearLayouts: not so good

Did you ever implement displaying SVG images that weren't resources?

I think I used the old svg-android several years ago

nothing recently, though

That's what I used too.

(sorry, "the old svg-android library")

there may be better options nowadays

such as a Glide plugin: https://github.com/kirich1409/SvgGlidePlugins

or other ones from https://android-arsenal.com/tag/96?sort=created

I actually use the "Glide SVG Example" which used AndroidSVG

By "use" I mean that I adapted it a little.

I am often unsure about what libraries I can pull into my project.

How can you make sure a library is "trustworthy"?

what is your specific concern? malware? reliability? something else?

Malware mostly. Reliabilty too

I guess I am just unsure about it :D

And would prefer to only use libs google themselves released and similar.

that's going to be a fairly limiting factor

popular open source libraries are unlikely to contain malware, if for no other reason that somebody would have noticed it in all likelihood

the more esoteric the library, the greater the risk that somebody slips something in that nobody notices

at the same time, the more esoteric the library, the less benefit their is for the attacker, as they won't get as many victims

But take the SvgGlidePlugins example from above. How do I know it's trustworthy and reliable?

skim the code

Is that a common practice?

I doubt it -- you have already expressed more concern about this than the *vast* majority of developers

that's not to say that your concerns are unwarranted

just that they are uncommon

a simpler check is to see if the library has a manifest and if it is adding anything to your overall app's manifest

I have just been thinking about it

so for example, if this SVG Glide plugin requested READ_CONTACTS as a permission, that would be a warning sign

Definetely :D

the problems we have had with malware from libraries has tended to be from proprietary libraries, particularly ad networks

to date, it hasn't been a big problem for open source libraries

that does not mean that it cannot someday bite us in the posterior, just that it has not happened significantly to date

I think I'll relax when it comes to importing

another thing you could do, if you wanted, is compile the library yourself from source, rather than rely on a Maven repository's artifact

there's a whole research area on 'reproducible builds' for trying to determine if a certain compiled app really came from the expected source code

Ah yes, some OS' are big on that. Debian for example iirc.

right

(though I think it's more a Gentoo thing, if they're still around)

pre-compiled artifacts are very convenient, but they open up other attack avenues

How so?

for example, suppose somebody hacked into Maven Central or JCenter and replaced a library with a malware-laden one

developers would pick up that library and use it

the authors of the library might not notice the switch

and the source code would not reflect the malware, since the malware did not come from the source

so, for projects for which these sorts of concerns are huge (e.g., the Guardian Project's apps), they tend to build completely from source

and there are layers upon layers that you can do for defensive measures (e.g., airgapped build machines)

That sounds like you need a lot of manpower

yes, or small projects

basically, the keys are: how big of a target is your app, and what would be the outcome of a successful attack?

So if it was really important, I'd get the source, confirm it's not doing anything strange and then use that

And if there are any updates, I have to reconfirm.

yes

yes

I see

at least for open source libraries -- that may or may not be possible for commercial ones

I guess my app is not big enough of a target :D

here, 'big' either means lots of users, lots of $$$$, or at-risk users

so, for example, Signal Messenger isn't exactly Facebook-scale and only sorta has lots of $$$$, but I'm sure there are "nation-state actors" trying to figure out how to get stuff into their builds

this sort of thinking is a key reason why I do not like App Bundles and I do not like Google's signing service

if Google signs the APK, Google has control over what is in the APK

Yes

and Google might change what is in the APK, whether of their own volition or not

there are lots of places where unpleasant things can happen

and, on the whole, our industry is doing a craptastic job of dealing with them

eventually, there will be some incident that will change behaviors

Weren't there some already? I remember NPM having some malicious packages?

oh, NPM has had problems from time to time

while I'm nervous about GitHub getting too big, I don't mind them buying the NPM stuff

because GitHub probably has better resources for dealing with those sorts of problems

fortunately, we haven't really had the same problem happen yet in the Android ecosystem

I suspect that has a lot to do with luck

Yes. I guess we pull in less stuff?

That too, mayb :D

Android apps might use fewer dependencies than Web apps, but I think we're catching up

I wonder if we should though

it's all a matter of priorities

and these sorts of concerns usually aren't a priority

similarly, our ability to deal with pandemics wasn't a priority

things aren't a problem until they're a problem

He

he

I can see that in the code I have inherited

similarly, these sorts of concerns tend not to worry the firms that I help

so, I try to improve their practices "around the edges" as best I cant

er, as best I can

but a wholesale revision to how the app gets built isn't something I can make happen

What kind of help do they usually want? And what do you recommend the most often?

How the app gets built?

What do you mean by that?

the sorts of stuff we have been discussing here, along with other mechanics of the build process (e.g., do we fail the build on Lint errors?)

Oh, I was thinkiung more generally. I see.

if I am contributing directly to the project, I have a voice in those sorts of things, just like any other developer

Do you have your "Android App Development Best Practices" somewhere in your books?

"best practices" tends to be the sort of thing that "lies in the eye of the beholder"

particularly at the level of projects

I see

what is a "best practice" for a solo developer will not resemble what is a "best practice" for a major firm

so, I tend to steer away from that and focus more on "nuts and bolts" sorts of things

Which are?

how do you use ConstraintLayout? what is a viewmodel and what does it model (and how do we view it)? how do I get SQLCipher for Android working?

Oh ok

the things that you see in my books

I think I got it

I have gotten a bit more into architectural topics, but not too deep, as that's an area that is still undergoing a lot of changes

And one has to find that out for oneself, I guess

Depending on the project and environment and such

to an extent, yes

there are lots of conference talks and Medium posts and stuff with people extolling the virtues of one practice or another

Which makes it kinda hard to pick one

right

Especially when having little experience and there is already something in place

Or only having little experience.

so, personally, I've been just trying to echo Google's recommendations and not go a lot further

Google has been getting a bit more opinionated on architecture in recent years, so I have pivoted a bit to match

Do you agree with them?

Or rather take them as a baseline?

"baseline" is a fairly reasonable description

And leave it to the reader to deviate from it

I have a few places where I depart somewhat from what they recommend, but not many and my changes are not outlandish

but, that's a discussion for another day

I think it's nice having a baseline to use when starting out

that's a wrap for today's chat

Instead of being confused by too may medium posts

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

Thanks

Stay healthy :D

the transcript for this one will appear on https://commonsware.com/office-hours/ in a bit

you too!