hello, Leora!

how can I help you today?

Heya Mark!

How are you?

OK, and you?

Not bad not bad hhhhhh

So I got permission to rewrite an old project I had worked on

And the simplest thing has stumped me ----- the layout!

It is a gameboard - calculator style you might say

and was written as a gridview with a BaseAdapter

ooooo... retro! :-)

And me, being so wise and experienced and all tried to turn it into recycler view, which i realized quickly is wrong in this case since it doesn't scroll and doesn't recycle

or grid layout which is completely inflexible....

since in the settings the user can change the item number to 4, 6, 9, or the default 12

that controls the numbers of rows? columns? both?

So....should i leave it as gridview (gasp)??

yes both

each column or row can be 2 or 3 span

for a fixed number of alternatives like that, I would consider creating individual ConstraintLayout-based layouts for each, and using the right one based on user selection

or 4 hhhh

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

hello

hmmmm i didn't think you would say that :)

Leora: GridView is also set up for scrolling and recycling, so IMHO RecyclerView is also a viable option, though the ConstraintLayout approach would give you per-gameboard design flexibility

I would not use GridView or GridLayout -- I would expect them to be deprecated one of these years

with the constraint layouts option i would be copy/pasting 12 views! (gasp)

it's possible you could do it with fewer layouts and using View.GONE visibility for some of the cells

deprecated eh

the items will also need to be shuffled when the user shakes the device

and smooshed a bit when a banner ad is presented

one advantage of RecyclerView is that if you use ListAdapter, you get automatic animations on a shuffle, to move the items around your board

(here by "ListAdapter" I mean the RecyclerView one, not the old AdapterView subclass)

oh i didn't know that

yes but it's really hacky to get recyclerview not to scroll

i think you even commented on that in SO once

i think it has to be in a nested layout

¯\_(ツ)_/¯

at a high level, if you want to use pre-existing UI things, I'd lean towards RecyclerView and/or ConstraintLayout, but in the end, it is up to you

let me take a question from Mark, and I'll be back with you shortly

Mark: your turn! do you have a question?

i was tempted to leave it as is, already has shuffle functionality written and all that, but if you think those layouts' days are numbered then....

ok

(Leora: you could leave them alone if you prefer -- your next rewrite may need to consider changes, though)

then i rather consider them now :)

Mark: your turn! do you have a question?

I created a productFlavor called "liveScores". In the Android Studio Project View, I see app/src/liveScores/kotlin/com.sports.mobile/info. I see the same directory structure in the debug build type: app/src/debug/kotlin/com.sports.mobile/info. When I CMD+SHIFT+O for a file in the info directory I see app/src/liveScores/kotlin/com.sports.mobile/info and app/src/debug/kotlin/com/sports/mobile/info

Android Studio shows packages using dot notation, to/limit/the/number/of/nested/directories/

but why would it appear differently between debug and liveScores

oh, wait

com.sports.mobile is one directory in the project window. if I search for a file the paths are different

to be clear: CMD+SHIFT+O brings up a file explorer for that directory? (I use Linux and forget my macOS UI...)

global search for files

so it lists a path from app. debug shows the package split up while livescores shows it as one package

OK, if you use Finder or something, and look at the app/src/liveScores/kotlin/ directory, do you see a com/ directory or a com.sports.mobile/ directory?

but project view shows both as com.sports.mobile

finder shows it as com.sports.mobile

OK, that's wrong

finder shows it as separate directories for the debug

I'm not certain how you got into that state, but you need that as com/sports/mobile/, not com.sports.mobile/

you may have difficulty fixing this directly from within Android Studio -- I would close the project in Studio, fix the filesystem using Finder or something, then reopen the project

Android Studio's behavior of showing packages as dot.delimited.strings normally is fine, but in this case masked a real problem in the directory structure

let me take another question from Leora, and I will return to you in a bit

Leora: do you have another question?

errr same question

ummm... same answer? :-)

OK

(Mark: that should be OK)

i thought you would be vehemently opposed to me using recyclerview since it doesn't recycle

but if i have your blessing...

you do not gain as much value from RecyclerView if you do not need recycling

but they have added enough stuff to RecyclerView and its related classes that it is not unreasonable to use it even in places where you do not expect to recycle stuff

i see

so that or different layouts yeah?

those would seem to be the two main options, for using modern existing UI constructs

you could always roll your own custom ViewGroup, if you wanted, but I find those to be kinda complex

nah :)

or, since this is a game, you could change approaches entirely and switch to a game UI framework

as in, no thanks

game UI?

it's a toddler game. they click a card and it opens up

most Android games are not written using the View hierarchy -- they use various game toolkits

not too complicated

the best known is Unity 3D, though that's probably overkill here

it would be nice to know but yeah overkill

ok great thanks for your input Mark!

happy to help!

as always

let me take another question from Mark, and I'll return to you in a bit

peace

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

for my liveScores product flavor I have my own version of files originally in src/main/com/sports/mobile/info that I moved into src/liveScores/com/sports/mobile/info. I want the app to use different files of the same name depending on the product flavor or build type. The file has a build error on the class name complaining Redeclaration

but you cannot have different class implementations for the same class for both build types and product flavors, other than by organizing them via build variants

I just want my product flavor to use its own version of the activity

you have more than one flavor, as you cannot just have a single flavor (other than to have no flavors at all)

(unless they added single-flavor support when they started forcing flavorDimension... actually haven't tried that recently...)

I created my own flavor

should i move the activity out of debug and into main

if you only wanted resources/assets/manifest entries to vary, then having just one flavor might work

but if you want classes to vary, you need two flavors (liveScores and, um, deadScores), with your class implementations in each

you cannot have the same class in main/ or in debug/

no this is an Activity. Originally it was in main. I want my own version in liveScores

ok let me try deleting it from the debug build type

then you need liveScores/ and deadScores/, each with their own version of the activity

and you need to remove the activity class from other places (main/, debug/, etc.)

what is deadScores

another flavor in the same dimension as the dimension that you have set up for liveScores

ok i can try that

thanks

(though I suppose undeadScores/ would allow you to have Walking Dead and Game of Thrones tie-ins... :-)

haha

hhhh no spoilers! didn't see ep 4 yet

OK, we're running out of chat time -- if either of you have additional questions, ask away!

bye mark and mark, may the undead be with you

before we go, how would I go about obscuring a module from deadScores, which I assume has the same source files as main?

what do you mean by "obscuring a module"?

deadScores/ has no source files by default, just as liveScores/ has no source files by default

I have an app module and an api module. liveScores depends on new code in api module. I would like to hide that code from deadScores

use liveScoresApi

so, liveScoresApi "your.artifact.group:your.artifact.id:1.3.3.7"

(or liveScoresImplementation)

that says "use this dependency only for builds for the liveScores flavor"

I unfortunately it is not in artifcatory, it is a separate module in the app

so, liveScoresImplementation project(":whatever")

yes

(or liveScoresApi)

im not sure I follow, they both need the module but liveScores only should have the liveScores api functionality built in the final apk

what is "the liveScores api"?

if you mean "code in liveScores/", then by definition only liveScores builds will have that code

an undeadScores build will not have the liveScores/ code in it

they both will have main/ code, plus code for the build type (e.g., debug/ or release/)

I have 2 modules in the same project, app and api. Before liveScores app still uses api. WIth liveScores I have new app code inside liveScores AND new code inside api module

you will need another module then, AFAIK

the api module would be split into the common stuff that both flavors use and a liveScores-specific api module

and you would only add the liveScores-specific api module to liveScores builds, via liveScoresImplementatino

er, liveScoresImplementation

do modules have flavors? couldnt I create a flavor in api and reference it somehow specifically in liveScores product flavor from the app

what is liveScoresImplemenation?

"do modules have flavors?" -- um, possibly, I forget the details there

implementation project(":whatever") says "add this module to all builds"

liveScoresImplementation project(":whatever") says "add this module only to liveScores builds"

you might wish to reconsider whether having a separate api module is worthwhile

OK I can create a submodule within api called liveScoresApi. Then in app's build.gradle say liveScoresImplementation project(":liveScoresApi")?

yes

yeah

great!

and that's a wrap for today's chat

have a wonderful day!

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

see ya

have a pleasant day!