Hello Mark!

hello, Dimitris!

how can I help you today?

Well I have a kind of theoretical question

theoretically, I can give you a theoretical answer

in theory, anyway

:-)

suppose you have an android app that has a core fucntionality and depending on the client (you are not using the play store) you have to do adjustments, customisations and additional features

how would you handle the structure and customer code sharing

that would depend a bit on the scope of the "additional features"

(hello, Steve -- I will be with you shortly!)

since the actual app is owned by you and you only charge for the developement of the extra features

Hi Mark - happy to wait

you should only share the source code that was paid by the customer

if we put aside the additional features for the moment, I would lean towards a single-module project, using product flavors

one flavor per customer

kai actual product follows a licencing type

where in the flavor's source set are resources (branding, color scheme, etc.) and minor code changes

however, I would start to worry about that if "additional features" might get big

(thats a fact)

there is a functional version in developed for windows and im porting in android

my alternative would be a core library module, an app module for simple clients, and additional app modules for clients needing bigger "additional features"

each app module depends on the library module

the simple clients' app would follow the first plan, using product flavors for light branding adjustments

would you automate the code sharing somehow ?

and clients that need more changes get their own dedicated app module

the shared code would be in the core library module, on which the app modules depend

so, it's already automated, at least in terms of how I interpret your quesiton

er, question

what about shipping the source code to the client

how would you automate that

"big app" clients get the core library module and their own app module

"small app" clients get the core library module and the relevant source sets of the simple app module

the "small app" model may prove unwieldy, depending on how you plan on shipping the code

I see, thank you for the suggestions I will wait and ask one more question after Steve

if you're shipping the code in the form of ZIP archives, it's not that big of a deal: write a Gradle task, Ruby script, etc.

if you're granting access to a source code repository, then this gets a *lot* more complex

OK, I'll be back with you in a bit

Steve: your turn! do you have a question?

Let me paste it in:

I am having a problem with a full-screen background image for an activity. The image appears in front of buttons instead of behind them. The buttons also use background images I provide. In both cases, the images are png files. I have tried two different png files as the full-screen background. I have this problem with one of the files but not the other. Is this expected behavior? How can I fix it?

I avoid full-screen backgrounds like the plague

in large part because of aspect ratio differences

ok

but I have no idea how one PNG file could give you this effect and not another PNG file

and so I do not have any idea how you could fix it

about the only recommendation that I can make is to check your elevations, on Android 5.0+

I had assumed that a layout background image would always appear behind background images for buttons in the layout. Is that assumption not correct?

I would make a similar assumption, but the elevation system introduced in Android 5.0 could be screwing things up here

We're actually using 4.2.2 - we have dedicated tablets

oh

then I don't know what to tell you

ok

when you say "background images", do you literally mean android:background?

yes

can you share your layout tree?

agreed: are these buttons children of the container that has the background?

yes

they are in included layouts

that shouldn't make a difference, but it may be worth an experiment to temporarily replace the <include> with an inline copy of the layout

ok. i was going to try using a FrameLayout to see if I could overlay the buttons on the background that way

you might also poke around with Layout Inspector and confirm that the buttons are indeed where you think they are

ok

no offense, but this smells like "you're making an assumption about the situation that isn't actually correct"

ok

(e.g., the buttons are inside some other container, not the one with the background image)

but, I don't have a silver bullet for you, sorry

if your layout is complex try to use the Hierarchy Viewer tool

ok

Layout Inspector in Android Studio does the same thing

(at least, with respect to examining your own app's layout)

so that would enable me to confirm that the buttons are contained in the layout with the full-screen background image?

yes

you will get a tree representation of your view hierarchy

ok. i'll investigate that

let me switch back to Dimitris for a bit, and I can return to you for follow-up shortly

Dimitris: back to you! do you have another question?

sure, thanks

I would like to ask you if you have any experience with loading and executing code at runtime in android

for security reasons, I avoid it

other than the one book chapter on the subject that I wrote

(which, to be honest, was a commissioned chapter by a consulting client)

the devices are unreachable in my case so this is not an issue

if they are unreachable, then there is no code to load

if there is code to load, the devices were reachable long enough to get that code there

it is entirely possible to lock down the dynamic code distribution process such that you feel confident that nobody can hack it

unreachable meaning that there is a local server that will provide the extra classes to be loaded

yep thats the case

I still don't recommend it, but it's your app

I have a chapter outlining the technique in the book

so you would never distribute a feature without actually updating the apk

correct

ok thank you :D

FWIW, the chapter is "Replacing App Code Dynamically"

starts on page 3729 of Version 8.7 of the book

thanks

let me switch back to Steve, and I'll return to you in a bit if you have further questions

Steve: your turn again! do you have another question?

i just wanted to finish up by asking if it's possible that there could be optimizations that would change the expected z-order of layouts (i guess that's something the LayoutInspector could establish)

optimizations, meaning things done behind your back?

yes

not outside of some GPU bugs or something

ok

no further questions today. thanks for your help, Mark!

you're welcome!

Dimitris: over to you -- do you have another question?

Yes a theoretical one again

I havent checked the source code related to widgets

by widgets, do you mean home screen app widgets, or subclasses of android.view.View?

but I was wondering if it would be possible to have full apps with complete functionality in a widget way windowed version on the launcher

home screen app widgets

official Android SDK app widgets are limited to RemoteViews

exactly

which severely cramps your UI potential

plus, the interactions are limited to clicks, further limiting matters

would it be technically possible to ignore that

and go with actual views

if you develop your own home screen, you are welcome to develop your own SDK for what I'll call here "AppWidgets++"

when you say home screen you mean a launcher app ?

you can create your own view structure seralization system that replaces RemoteViews

yes

as part of that view structure serialization, you can support PendingIntents for other types of events, beyond clicks

and you can create your own IPC system for obtaining that view structure, initially and when updated

your home screen can then use that view structure to create the Views and render them

locally handling relevant input events and triggering PendingIntents as appropriate

and I guess the home screen should have some kind of configuration file

that tells it what it should draw

you would have some sort of rules for what AppWidget++ instances have been requested by the user (or whatever)

if for example there is a gallery in the top half of the screen and an expandable list in the bottom part

correct: sizing and positioning data would be in the home screen

sounds fun

this approach gives you an expanded app widget-style system, with more control over how the interactions work

by the way I have enough insight on kioks mode implementations for rooted devices if you ever want to write a chapter on that

that's way outside the sort of thing that I want to be covering, but thanks!

:D

back to AppWidgets++: it's still based on separate apps and IPC, for security, and that will still put some limits on how elaborate an AppWidget++ can get

I really like your approach of digital signage apps

with the AppWidgets++ concept

of course, you could also go with the "it's all HTML" route, where each AppWidget++ is really a WebView

do you think each widget would be an app

with its own apk

I was working under that assumption

I was assuming that as well

I was thinking about loading code at runtime :D

in part, because I don't know the situation, and so I have to assume that there are many possible providers of AppWidget++ implementations

In my scenarion I would be the only provider

the client would just be able to choose what makes sense for them

then why isn't this just an app?

scenario*

like one app, that has the UI that the client wants

what is the value in either dynamic coding or what I was describing?

(er, dynamic code loading, I meant)

because every client will have the core functionality but all the customisations and additional features/widgets

will be individual

I kind want to avoid building 100 apks for 100 customers

"individual" meaning per-client or per-sign?

it can even be per device

but that could still be a single app, just with a configuration file or something

yes it currently is

but im just evaluating options

OK

thank you for the great suggestions !

you're welcome!

As always very helpful

I try to be useful

Have a nice day!

you too!