hello, Tad!

Hi Mark!

how can I help you today?

Are you having your dinner while we have this chat? ;)

not exactly

Just wanted to follow up - I worked through several approaches to streaming content using SAF that we talked about last time.

I ended up deciding to NOT go the "public URL" route.

I went ahead and investigated using SAF, then using pipe streaming in openDocument().

Used some of your examples of pipe in ParcelFileDescriptor.

OK

Mainly due to potential customer feedback about hesitancy they had in granting an app the ability to create a publicly available URL.

potential USER feedback I should say.

No paying customers here...

Anyway - I had a question about the sample in your book

fire away!

I noticed that the TransferThread sample you use is a static inner class. Is this to help prevent leaks given that static classes don't hold a reference to parent?

probably yes -- which specific sample are you referring to?

Your example on ParcelFileDescriptor using a pipe

ContentProviders/Pipe?

yeah

OK, hang on

yes, I didn't need TransferThread to have a reference back to the PipeProvider, so I made it a static class

in this case, there are no configuration changes, and a ContentProvider lives as long as your process does

Is there any ramification of that model if/when this gets instanced multiple times for the same doc?

not really, other than forking a thread per transfer

I notice, for example, that I am seeing multiple calls to openDocument() for the same doc.

you could implement a thread pool with a work queue, possibly

I think that would imply that the client is closing and reopening the stream

Seems a bit strange to me - but given that I might be transferring a 50-80MB (or larger) video file, was worried about all this data streaming.

I mentioned last time that the streams from ParcelFileDescriptor are not seekable

Right.

perhaps closing and reopening is a workaround that the client has for dealing with the inability to use mark() and reset()

And ExoPlayer appears to "figure out" the length accurately, as well as support moving back/forward in the video.

cool! not sure how they're pulling that off, but cool!

I haven't tested accurately to know whether their skips are actually correct (i.e. it shows moving back/foward 4 seconds, is that correct?)

beats me

But anyway - both Glide and ExoPlayer seem to accept this ParcelFileDescriptor approach with the pipe and it seems to work so....

One other question - in your experience do you have a particular buffer size for Internet streaming that you think is best as a default?

I'm using 8k right now

that's not a bad value

but I haven't done an exhaustive analysis of buffer sizes and performance

I started to do something a bit more clever - like test the size of the target file, and if it is less than 64k make it the largest multiple of (8k*2) that I can, and if it is > 64k make it 64k. But I couldn't tell any real improvement difference over just leaving it at 8k.

At least, in the limited performance testing I've been doing.

¯\_(ツ)_/¯

how else can I help?

Curious if you have played with Flutter?

a little, and not recently

What do you hear about it? Do you have a sense of where you start running into walls? I'm curious about whether it's "worth it" for apps that use native type resources (audio/video, etc.).

I don't have a good sense of that, sorry

mostly, my attention has been on what Flutter means for Fuchsia

Given that Fuchsia is really Google-centric, it seems like they are at cross-purposes?

Flutter is the native UI for Fuchsia

This is where I get a bit fuzzy - because I thought the whole power of Flutter was cross-platform. So when you say "flutter is the native UI", you mean the "google aspect of Flutter"?

The actual widgets map into native controls on both platforms, right?

yes... but on Fuchsia, they *are* the native controls

(at least as I understand it, Fuchsia being shrouded in mystery and all that)

So you use Flutter controls, that map to Google widgets, which get placed in the Fuchsia. I must be missing something. That's an extra step. Why not just program in Google native controls from the get-go for Fuchsia...?

Flutter controls == Google widgets

they do on a Google platform (like Fuchsia). But not on IOS. So it seems to me that is an extra layer of indirection if all you want to do is build Fuchsia apps.

Unless I'm entirely missing the point (which is possible!)

I've been scratching my head to draw an analogy and am coming up blank

If it is all Google, why not have a Fuchsia plug-in for Android Studio?

if you could, visit https://flutter.io/docs/development/ui/widgets-...

OK - well, I won't keep you. Thanks for your pointers on my little project, and I must say it is quite impressive what you have put together on CommonsWare. Thanks so much for what you do!

in the Hello World code snippet, they have a Text widget that shows 'Hello, world!'

you're very welcome!

Btw - I don't want to "wear out my welcome", is it ok (according to your vision of your business model) that I attend multiple of these sessions?

of course!

you're welcome to attend as many as you lik

er, like

It's been just you and me in the few I've attended, and having owned and run a consultancy in the past I'm sensitive to people's time...

well, you haven't been overlapping others that frequently

and, on the whole, these office hours are not especially well-attended

ok cool.

but, there are certainly others who show up from time to time

as you can see in nearly a decade's worth of chat transcripts: https://commonsware.com/office-hours/

Great - well, I certainly appreciate the time to bounce ideas off of you.

happy to help!

I may have mentioned Possible Mobile here in Denver, I attend their Android meet-ups also, and they speak highly of you!

Denver Droids?

right

if so, I've virtually spoken there a couple of times

Also the Boulder one, but that has been off and on.

Yeah, that's the one...

I think I still sponsor them, with Warescription giveaways

It's a pretty well attended meet-up. Btw - in addition to the section in your book about "getting your app ready", and what is in the Android docs, any other resource for "real world best practices" that would be useful for me to review?

"getting your app ready for the Play Store"

I haven't kept up to date on that specific type of resource, so I can't name any off the top of my head, sorry

ok thanks.

Bye now.