hello, Susheel!

how can I help you today?

Hi Mark. How are you doing?

slightly sleep-deprived, but otherwise OK -- and you?

I got just the right amount of sleep so I'm good. Thank you!

I have a horizontal recyclerview I am using this as a viewpager. But now I'm having to implement my own viewpager indicator equivalent.

Shouldn't be terribly hard as I could just use shape drawables because I am in need of circle page indicator.

I know there's nothing in stock recyclerview that provides this functionality

What do you think or suggest?

in terms of... what?

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

about my solution. with the shape drawables

Hello!

is there a simpler, cleaner or elegant way?

::shrug::

that seems fine

you might look at how an equivalent ViewPager indicator is implemented

the principle difference is in the event listener for finding out when to change the indicator, and to what state

(er, principal)

Right.

Okay

everything else about the indicator would not need to change

barring some unexpected dependency of the indicator on the pager

True. You can get to Dimitris now.

OK

Dmitris: your turn! do you have a question?

So in case we are using a "bad" library that creates some thread using C++ and its not properly mapped to java so when the device sleeps and come back the c++ created thread is either killed or sleeping but we need to restart it, what do we do :P

we ask that question of somebody who has done a lot more NDK work than I have

(library is handed by the manufacturer and its obfuscated)

as I haven't the foggiest notion

though if it's the manufacturer's own library, they ought to know about their own hardware sleeping, and so this is clearly a bug

I guess if I dont see any memory leaks I should just restart it manually without fear right ?

ideally, yes

it is possible that there is some global state outside the scope of the thread that will not like that, though

and what is the "best" way of getting notified that the device goes to sleep

AFAIK, the closest thing is watching for ACTION_SCREEN_OFF and ACTION_SCREEN_ON broadcasts

but, I have not researched this area in years

thats not really reliable

that would not surprise me

but I am not aware of anything better

cause this definitely does't seem to recognize the user pressing the power button

it should

what about recognizing the power button click

maybe I should override the keys pressed

AFAIK, people do that via ACTION_SCREEN_OFF and ACTION_SCREEN_ON

hmm then I guess I should check if I have some mistake in my code

I do not think that the power button triggers a KeyEvent, though I may be wrong, and that would also imply that your activity is in the foreground

again, this is not an area that I work in much, so my knowledge is fuzzy and may be out of date

IOW, YMMV, FYI :-)

:D

adb shell input keyevent 26 is the power button :P

however, if your code cannot detect it, that will be of limited utility

hmm

for example, HOME button presses do not result in KeyEvents, last I checked

maybe I can use this onWindowFocusChanged

im not sure if on screen on this gets triggered

if it does I can assume the device wakes up

it would get triggered in other cases, though, such as when another activity takes over the focus

hmm

if I could at least consistently get the screen off event

the combination would work

but I need at least one of the events in a consistent way

pressing the POWER button should trigger ACTION_SCREEN_OFF, AFAIK

if it is not doing that on your hardware, ask the manufacturer

thank you Mark !

for stuff like this, you might run some tests on a more "official" environment (e.g., Google Pixel), to determine whether your problem is in your logic or in the manufacturer's device

this makes sense !

let me switch back to Susheel, and I will return to you in a bit

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

(at least allows me to complain to the manufacturer)

OK, if either of you have a question, go right ahead

What is your opinion of global shared preferences and the fact that its deprecated, wasn't it a decent feature for people having a set of applications with sharedUserId?

I don't think it was ever really safe for multiple processes

Do you know if an app has System permissions (signed with a system key and so on) can it read shared prefs from every app on the device

I doubt it

that should require root

what if two apps are both system apps

that should not change the situation

can they access each others shared prefs ?

a device manufacturer/ROM developer might set up a pre-installed app in some Linux user group that allows for broader read access

not by default

as Google recommends, use a real IPC solution

but they also mention this

The name of a Linux user ID that will be shared with other applications. By default, Android assigns each application its own unique user ID. However, if this attribute is set to the same value for two or more applications, they will all share the same ID — provided that their certificate sets are identical. Applications with the same user ID can access each other's data and, if desired, run in the same process.

each other's data means shared prefs too ?

yes

so if the sharedUserId = System

then it might be possible that they both access the same

by "system apps", I assumed that you mean installed on the privileged partition

shareduserid='android.uid.system’

are you signing the firmware?

if not, then what you want will not work, as your apps will not be signed with the signing key that signed the firmware

no but I can sign my app with the OS key

OK

then in principle what you describe should be possible

so I do have a real System app

thank you !

is there a section on IPC in the book ?

startActivity(), startService(), bindService(), sendBroadcast() are your main IPC solutions

(plus ContentProvider)

(and its related classes, like ContentObserver)

so I would have one app be the "owner" of the preferences, and expose an API to other apps via a provider or perhaps a bound service

bad question but is the ContentProvider staying intact when an app gets uninstalled

no, as the ContentProvider implementation is being uninstalled

that makes sense

IMHO, if you have two apps that are that tightly coupled, they should be one app, not two

I guess the provider or bound service implementations are the way to go for me

they need to be two unfortunately

so I need to decide how they will communicate

maybe broadcasting some intents will be enough

but thank you for mentioning all the options

have a nice day Mark thanks again

you're welcome!