hello, markedef!

how can I help you today?

Hi Mark

on the last chat you mentioned accessibility is important

I was wondering how can I test if the app is accessible

turn on Talkback and try using it with your eyes closed :-)

(though I'm not completely joking there...)

because if you remember I have my custom keyboard and a custom TextField that displays a price

among other things, Google has an app ("Accessibility Scanner") that can help identify accessibility issues

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

Hello everythone

marekdef: yes, and I was concerned about accessibility with respect to the custom keyboard

I think the keyboard is accessible beceause is built on top of TextFields but my custom price tag is FrameLayout with EditText covered by another FrameLayout

just wanted to check if blind person could read the price

my guess is they will not

but I have not had to do that sort of thing very recently, so I am not completely certain

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

allright will check the scanner app

so, turn on Talkback and see if you get announcements from your EditText

hi Mark! sure thing

also, set up a Bluetooth keyboard and make sure that you support text input, both in terms of numbers and in terms of arrow keys for navigation

if you can get both of those working, you should be in decent shape

also, I think there are firms out there that help with accessibility testing, if your firm is interested in getting specific professional input on your... ummm... custom specific professional form of input :-)

let me take questions from the others, and I will come back to you a bit later

Kai: you were next, so... how can I help you today?

sure

I was wondering how to implement different layouts for different screens sizes properly, especially given a ListItem with ConstraintLayout

that's a little abstract... in general, you decide at what size you want to switch strategies, and then set up a layout resource directory for that size

Given this listitem

I want it to have both the highlight bar and the "action buttons" (dots on the right) in one screen width, only the action buttons in another and neither highlight bar nor action buttions in a third.

you have two choices: handle that with layout resource directories, or handle that in code

with layout resource directories, you would have res/layout/, res/layout-swXXXdp/, and res/layout-swYYYdp/

I did make three variants with w420dp, w420dp-large and layout

I strongly recommend changing w420dp-large to something else, based purely on a dimension

So that is still the proper approach? Just have three layout variants?

that is one possibility

the other is to mark those widgets as having visibility of View.GONE by one means or another

Thing is that I had it that way but for some reason I didn't get the results I was looking for. Also, we have a two-pane view for tablets which still works with -large and I wanted it to adhere to that

I really don't recommend using -large anymore

that's a 2011 sort of thing

and you are even more at the mercy of device manufacturers than usual if you use it

use w420dp and another wNNNdp, for some other value of NNN

I kinda needed to as I needed the listitem to change at the same time as two-pane would come up, which is coupled to -large atm. When refactoring I could change that.

tactically, if you want to use it, go ahead -- it's just something that would worry me

It worries me too, but at the time being, I kinda had to do it that way.

in general, I can't really help with "I didn't get the results I was looking for", as I don't know enough details

Short of taking the time to find out how the app should look on different devices and refactor large

But I think that answers my question. I wanted to know if I was going in the proper direction.

your revisions are minor enough that I would consider having just one layout and either use integer resources to change visibility of those widgets or change their visibility in code

but, three layouts is certainly reasonable, particularly if you anticipate more substantial changes down the road

let me take questions from the others, and I will return to you in a bit

How readable would that be?

Leora: your turn! how can I help you today?

I haven't thought about integer resources so far, but sounds like an interesting approach.

Having some trouble converting my code from java to kotlin

specifically, I have a lib module and an app module

interface INav in lib, singleton class Nav that implements INav, and class NavA from app that extends Nav

I get the correct Nav class when I initialize some stuff using custom Application classes

In java it worked great! even when i had a function called from the singleton Nav class, it was directed to the overridden function in NavA class. perfect

in kotlin, I made the singleton class using object Nav

but the function called from the Nav object calls it's own function, instead of redirecting to the overriden function in NavA

phew that's it

I'm surprised that NavA can exist -- I didn't think you could subclass an object

hahaha

object NavigationST : INavigation by Navigation{}

:)

but, isn't Navigation itself an object?

yup

i thought that's how i get a singleton class in kotlin...?

yes, but I guess I had not realized it could be used this way

is my pattern messed up?

you said that it is not working, so ¯\_(ツ)_/¯

how can i define a navigation base class and override some methods of it depending which app subclasses it?

well, on the whole, I would try to minimize the use of the Kotlin object keyword

ideally, you would be using dependency inversion (Dagger, Koin, etc.)

i should be using?

personally, I use Koin, as it is very easy to set up -- I use it in quite a few of my books

but, let's skip that for now and say that you still need to use object

which book? I downloaded all of them

ok

my intro to DI is in *Elements of Android Jetpack*, I use it in *Exploring Android* in the back third of the book, and many of samples in the other *Elements* books use it

ok i'll check it out

anyway, you might consider having your base implementation be a regular class, and use objects for leaves of your hierarchy, rather than trying to use one object as a property delegate for another

it is possible that there is a way to get that to work, but I have never tried it, and it makes my stomach queasy

interesting...until you said queasy

the "queasy" was with reference to the property delegate approach

i'm sorry, which is that?

I would see if the library can have the base class implementing the interface, and different modules can create subclasses of that as singleton objects as needed

object NavigationST : INavigation by Navigation{} // by is the keyword to set up a property delegate

ooooh

if Navigation is an object, you now have an object whose implementation is backed by another object

how would the subclass define itself? object NavigationST : Navigation()

?

(I so wish this chat supported Markdown for backticks-as-code)

let's suppose that in this revised approach, you still have INavigation, and Navigation is a base class, not an object

then yes, object NavigationST : Navigation()

ok, thanks Mark, I'll try it :)

let me take questions from the others, and I should be able to get back to you before the chat ends

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

marekdef: do you have another question?

marekdef: if you come up with another question, let me know

in the meantime...

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

Yes. I want the background of a listitem to look a certain way after it had been clicked. I am quite confused after trying to find out how to do it.

I think the typical approach is to use a StateListDrawable for the background, where you have different background for normal an activated

I tried that with checked, but it never got activated.

checked AFAIK is only really there for CompoundButton

activated as a state exists for all views

and it is not used by the framework itself for anything, so our uses of it will not conflict with something else

so, if you use the activated state, you should have better luck

I didn't know that. We used "pressed" and "activated" at a lot of points

pressed as a state should get triggered while the user is sending touch events to the view

A listitem is "activated" after a long press or a press on the "action button" in our app.

If you would short press it or press the action button again, its state goes back to... dunno :D

let's go back to "I want the background of a listitem to look a certain way after it had been clicked"

is this a transient thing (i.e., it reverts to normal after 500ms), or a permanent thing?

and, if it is a permanent thing, doesn't this conflict with the long-press thing?

Permanent

It denotes the item that has been selected last

and that is something different than the long-click?

The long press brings up action mode (and you can actually press other items and add them to the selection after having pressed one with long-click).

If you short-click it, you just choose it, but don't invoke action mode.

your graphic designer and I are not going to get along

at most, I would do one or the other of those

And it gets a highlight bar atm, but the graphic desiners want another background too

So would I, after having understood what they want.

you'll probably just have to manage that yourself in code

keep track of which one is "selected" and manually swap the backgrounds

I just wanted to clear up my confusion on how to do the selection thing properly on the technical side.

basically, "activated" gives us one application-level UI state that we can leverage, but only one

you're using that for something else

so, this "last selected" state is going to have to be manually tracked

I think that is what I wanted to know.

I guess the usualy states for a normal app would be state_pressed, state_activated and none?

yes, though most of those have framework uses (e.g., the framework switches between normal and pressed)

pressed on clicking something, activated after it has been clicked and none otherwise?

activated is there for application use, and so you can decide if/when a view is activated or not

in your case, you are using that for something else, and I do not recall there being another application-centric state

everything else (pressed, disabled, etc.) are used by the system

and will have ramifications beyond the background

It's good that the framework "uses" the pressed state, as it is something you get automatically.

yes, and the original vision was that *all* states would be framework-managed

activated was an afterthought, added in API Level 11

and I'm grateful for it

But you could always change the colors for the states?

sure

And "activated" you can actually "grab" as an event, is that what was added in API Level 11?

it's not an event

it's a state that you set yourself, via setActivated()

it's just not one that anything in the framework should be using and setting automatically

and it's not one that the framework will react to, other than for your own purposes (e.g., StateListDrawable)

So before API Level 11 there where not states that could be set by oneself

you could set something like disabled, but then that has other impacts, such as disabling user input

And they added that to give a generic and controllable state besides the framework used ones

correct

I see

let me take questions from the others, and I might be able to get back to you before the chat ends

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

yes, but also to say your suggestion of changing the base Nav to class and NavA to object worked!!!

oh, cool

it's now pointing to the correct methods

totally cool thanks!

you're welcom!

quick question but looks like a bug

er, welcome!

registerForActivityResult is suddenly showing up 'unrecognized'

red, error

but the code compiles and runs fine

any idea?

since that stuff is still in alpha IIRC, are you sure that both modules are using that alpha version of androidx.activity or androidx.fragment

i had it in the library module as api and not implementation

that usualyy takes care of the imports of the app module

agreed, that sounds fine

but after the error i added the dependencies to the app gradle as well

error persists [insert eye roll here]

If I have something like this, I first click on the elephant in the top right to sync gradle. If that didn't work I restart the IDE

hmmm... there's always Build > Clean Project, and running a Gradle dependency report to confirm you are using the alpha

did all, even invalidate caches/restart

but, given that this is compiling, it might just be an IDE bug

what version of Android Studio are you using?

ok probably

ahhh maybe cause i DARED to try the beta 4.1

i felt i could handle it hahaha

it's not you, it's the beta

thats what they all say :)

btw i only need the androidx.activity OR androidx.fargment?

not both?

AFAIK, you need whichever one(s) you are using -- so, if you are calling registerForActivityResult() in an activity, you need androidx.activity

ok thanks

this is just based off of a quick skim of the docs -- I haven't played with these APIs yet

and thanks Kai for the suggestion - love your name!

ok, i've been feelin bleeding edge

if anyone has any last questions, fire away!

Thanks so much Mark, a pleasure as always

None for 1 minute :D

What is the airspeed of an unladen swallow? ;-)

hahaha

is that an African or European swallow?

*sproing*

aaaaahhhhh....

but, alas, that's a wrap for today's chat

the next one is Saturday at 4pm US Eastern

thank you all

Have a good time everyone

have a pleasant day, and stay healthy!