Hey Mark how's life?

hello, Dimitris!

how can I help you today?

So today I have two major questions

First one will be regarding an updater app I'm making

go right ahead

So it has a download manager, what I currently have is a class extending async task that takes a set or params and downloads the according files

I was wandering if using the download manager would make more sense (the whole downloading part is going to be done in a service)

OK, first, there is no point in using AsyncTask in a service

the point behind AsyncTask is to do something on the main application thread after the background work

and there are very few scenarios in which you want a service doing anything on the main application thread

Since it doesn't need to use the main thread right ?

right

either use a Thread, or a ThreadPoolExecutor

in terms of using DownloadManager... there are pros and cons

What would be a proper design patern for each case

Just so you get the point

The files are going to be XML configuration files and media files

um, whatever you are doing with AsyncTask, replace with the thread or thread pool

They will be stored and parsed only after everything is downloaded and hash checked for being valid

for example, if you only want to download one at a time, just use an IntentService

as it gives you a background thread "for free"

if you want to parallelize the downloads, use a ThreadPoolExecutor, typically sized at 2N+1 threads, with N being the # of cores

I want to make edge case scenarios handled as easily as possible

I don't really care about parallel downloads

execute Runnables and whatnot on the ThreadPoolExecutor, with some sort of logic to know when they are all done, so you can do your post-download processing

then an IntentService is the simplest solution

you will want to make it be a foreground service, though, particularly with an eye towards Android O, in case your downloads and post-processing will take over a minute

I need safe downloads this process is going to be done for a "player" app update purpose

what does "safe" mean in this context?

I am supporting fixed devices only

Digital signage ;)

Huge custom rooted screens supporting 5.1

the downside of DownloadManager is that it cannot download to your app's internal storage

it can only download to external storage

I need to have a tracking mechanism that makes sure that everything I need to download is downloaded properly

and you cannot use certificate pinning or anything to further secure the connection

I actually need it on an external storage

Since the data will be parsed by a second app

Hmm that's an issue

that does not imply that you need external storage

that only means that the second app has to be able to get to the data

So download manager ain't working with certificate pinning

correct

:/

you have no way of teaching it the rules

Httpurlconnection it is then

and even with network security configuration on Android 7.0, that only affects your process, and DownloadManager is a separate app

I would recommend OkHttp over HttpURLConnection, but that's just me

Regarding the Android priority job queue​ open source library

do you mean https://github.com/yigit/android-priority-jobqueue ?

Could it help me out ? Since I should also have a job scheduler implemented

Yes that one

I have not used it

so I do not know how its integration with JobScheduler works

My updates have to be either triggered or follow a set of rules

I do not know what you are looking for a library to solve with respect to that

if your objective is to support JobScheduler but also support older devices, perhaps that library can help, or use https://github.com/evernote/android-job

Thankfully I'm only supposed to support 5.1

Regarding the edge case handling (wifi connection lost, device rebooted) is there any suggested patern to use for my download manager

for loss of connectivity, scheduling a job to give you control again after you get a connection is a fine solution

in that case, you might dispense with the IntentService and just do everything in a JobService, with your own forked background thread (as unfortunately you're responsible for that yourself with JobScheduler)

and if you think Yigit's library will help with that, give it a try

regarding a reboot, there would seem to be two corner cases:

1. what happens if the device reboots while you are in the middle of processing a job?

2. what happens if the device reboots while you are waiting on connectivity?

if you use a persistent job with JobScheduler and your JobService, #2 should be handled for you automatically

I have never tried #1 and so I do not know what happens if the device reboots while a job is in progress but has not been signalled as being completed

you would have to run some tests to see if JobScheduler handles that

it should, but there are lots of things in Android that I think "it should" do, but it doesn't :-(

Can I fetch a jobScheduler status

you can get a list of the scheduled jobs, if that is what you mean

My service is going to run on device boot so maybe I should just check the jobs list

you would have to run some tests to see if the jobs are ready at the point of an ACTION_BOOT_COMPLETED receiver being invoked

in principle, they should be

The devices will be public displays so I need to have a solid control

but, stranger things have happened

Yeah a lot of testing will be needed :/

Do you have any experience with silent apk updates ?

I have not worked in rooted environments in general

It's a dark place since the client requirements surpase what the os was made for

in the long term, Android Things is likely to be the better platform for this sort of device, IMHO

Just to finalize question 1. I should go for the service - own thread - urlhttpconnection or okhttp solution right ?

compared with DownloadManager, yes

Awesome this is a really important decision I needed to make and you really helped me :D

I am happy to be useful!

So question 2. ?

In my awesome strange setup the updater tool gets data saves it inside an accessible folder

In the data an apk of the "player" app exists

It gets installed "somehow" and runs

Now that player app

Is going to build it's ui by parsing xml configuration files

So imagine that the configuration my tell me that the 1st screen consists of 2 sub screens devided horizontally

The upper part should have a slider with images and videos for example

The question is what kind of generic structure should I use for the sub screens

Should they be fragments or views or custom components

I am not certain what "custom components" would be other than fragments and views

most of your application logic should reside in some sort of controller/presenter thing, typically

Ok right it could maybe be custom viewgroups

digital signage does not involve user input usually -- am I correct in assuming that your UI is output-only?

The UI is going to be interactive

So I will have buttons and so

The goal is to make as much abstraction as possible regarding sizes and positions

but the device screen is physically fixed, and the user can't mess with settings, so there should be no configuration changes... right?

So if the client needs a slider that takes 20% of the screen height or 30% I should be able to support it if he wants it to take 20% horizontally that should also be supported

that sounds like you want to create a LayoutInflater equivalent

Yes they can navigate through fixed paths

unfortunately, LayoutInflater itself can only be used with resources

I seem to recall libraries out on the Android Arsenal that offered LayoutInflater-style inflation-from-data-file capabilities

Hmm that would be nice ! But what about something built by me

I would approach the problem in much the same fashion, with a dedicated set of classes for "inflating" the UI from the configuration files

The subscreens are going to always have specific set of possibilities

that can simplify the inflation logic somewhat

Should I have a view base implementation or fragment

um, to some extent, neither

So single activity and adding removing views or fragments

:/

the "inflater" would assemble a view hierarchy based on the configuration file

if you have individual discrete views that are fairly distinctive, having those be custom views is reasonable

but then the "inflater" would hand over the view hierarchy over to your controller/presenter thingy

For example a slideshow

whether a "slideshow" is necessarily a custom view, I can't say

I guess I should be able to have a custom slideshow that can work on different sizes

I wouldn't rule it out, and you probably want to have some sort of packaged "slideshow" component

Yes

but whether it is truly a custom view (i.e., subclass of ViewGroup) or more of a local controller/presenter around something else (e.g., RecyclerView) is up to you

I would tend towards the latter approach

I need it to be something like small apps in my app

ok, then the "small apps" themselves are their own MVP/MVC/MVVM units

Yes that would be perfect I guess

the "inflater" is stitching together those small apps

Would it make sense to have them as modules ?

Yep I really like that approach

if you want separate teams working on them, or you want to reuse them across projects, yes

otherwise, while they might be separate Java packages, I'm not sure that having them as separate Android Studio modules would gain you much value

What about keeping the project readable and clean

Packages should be enough right ?

if you find having N modules to be more readable and clean than one larger module, feel free to use multiple modules

typically, though resources are not affected by that

Any attempt to dynamically update and apps module without a new app update ?

that is difficult with resources

it also presents security issues, but your whole environment is one big security issue with a screen attached

I know some apps do it and I know it's not legal in play store apps but since I don't use the play store it would be interested

^^ indeed

I have a chapter on dynamic code loading in the book

Awesome I'll read that

Any idea of how the inflater class can be structured ?

Should I just take a look at the inflater source code

the LayoutInflater code is fairly nasty, last I looked at it

and you have a more controlled scenario, whereas LayoutInflater needs to deal with custom attributes and such

(the only reason I'm not too scared for the security issues is that the data is always public data so if my login credentials are not leaked it should be fine )

I hash check everything before showing it

Maybe I should just encrypt my hash containing table

I would use digital signatures

hash checks are good for confirming that the download wasn't scrambled

but if they can hack what you are downloading, they can hack your list of hash values

so that their modified download has a valid hash value

True :/

whereas to hack the digital signature, they would need access to the developer machine, not the digital sign

I guess the hardest task is making the inflater class right ?

well, given your "small apps" model, the inflater would appear to have two roles:

1. configuring the overarching layout (e.g., the splits of screen space to be allocated to the small apps)

2. handing configuration data over to the "small apps"

it may be that each small app knows how to "inflate" itself, given its subset of the configuration data

and so the top-level inflater is handling the screen space allocation and instantiating each "small app"

The main container is my activity right ?

presumably

And I guess maybe it would nice to have a definite ed order of inflation

Top to bottom or so

I do not know how flexible your inflater needs to be

Worst case scenario it should decide the screen into 4 rectangles of different sizes

Devide*

(at least it's always rectangles :D )

ideally, you boil that down into a fairly simple algorithm

e.g., the primary split is horizontal or vertical, with X% being the dividing point

and then within the first split we have an optional second-tier split

and so on

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

That's a nice point thanks !

the transcript will be posted to https://commonsware.com/office-hours/ shortly

As always I'm very thankful

the next chat is Tuesday, also at 9am US Eastern

you are very welcome!

have a pleasant day!

Enjoy the rest of the day :D