Office Hours — Today, September 6

Tuesday, September 4

Mark M.
has entered the room
Mark M.
turned on guest access
Sep 6
9:00 AM
ndrocchietto_ivano
has entered the room
ndrocchietto_ivano
Hi Mark good american morning
Mark M.
hello, Ivano!
how can I help you today?
9:05 AM
ndrocchietto_ivano
first of all thank you for all your help in the last years, I will start to work as Android/Ios dev next month
9:05 AM
Mark M.
cool!
ndrocchietto_ivano
thanks. secondly would like to ask you if you know an use case when I could use flatmap
I understand really easy concatMap
and even map
but I cannot understand this operator flatmap
Mark M.
you are referring to flatMap() on an RxJava Observable?
ndrocchietto_ivano
actually I know that return an Observable that get flattened
yes correct
(actually you have been nonw a duck rubber for me because I get inspiration asking the questio, I could see the source code of flatmap() DOH!)
I am going to check
Mark M.
you use that when you have an Observable that needs to have some other Observable thing applied to it
ndrocchietto_ivano
so basically when I need to make a transformation but need that returns an Observable?
so map() does not return an Observable?
Mark M.
no
ndrocchietto_ivano
wow
I get it
Mark M.
ndrocchietto_ivano
so is before to apply a subscribe
Mark M.
yes
in the code that I linked to, I start with an Observable that may be doing disk I/O
I then use a couple of map() operators to collect a piece of data from that, in the form of a generated passphrase
ndrocchietto_ivano
but you should use map after flatmap
because map() does not return an OBservable
Mark M.
not necessarily
9:10 AM
ndrocchietto_ivano
in this logic I should use rather a Subject type
Mark M.
in my case, I want to confirm that the passphrase is not already used in hacked data sources, so I flatMap() to pass the passphrase to another Observable that hits a Web service
I use a Subject when I need the subscriber to have a consistent subscription, but the sources of data change
ndrocchietto_ivano
I think I want to clone your repository this evening
and play a bit
so that I could in retrospective see if I am going to get a good understanding
thank you very much
Mark M.
that sample is covered in the chapter on repositories in "Android's Architecture Components"
ndrocchietto_ivano
fantastic
I started to read it
although I am surprised in AAC you did not use a LiveData
Mark M.
I have plenty of examples with LiveData
ndrocchietto_ivano
but possibly is because you needed the more complex operators of RXJava2
no doubt
Mark M.
that sample in particular uses LiveData
my general approach is to use RxJava for "back end" things (repositories) and use LiveData in the UI area
using things like LiveDataReactiveStreams to map between them
ndrocchietto_ivano
fantastic idea
Mark M.
LiveData is not very powerful, but it is excellent for the UI, given that it is aware of the lifecycle
ndrocchietto_ivano
so that you can easily couple it with ViewModel in UI, while doing all the heavy backend API lifts with RXJava
Mark M.
precisely
ndrocchietto_ivano
really glad I can focus my life from now on coding
have a pleasant day
and thank you very much
9:15 AM
Mark M.
you're weclome!
er, welcome!
ndrocchietto_ivano
:)
9:35 AM
Hazi c.
has entered the room
Mark M.
hello, Hazi!
how can I help you today?
Hazi c.
Hi
9:40 AM
Mark M.
do you have an Android app development question?
Hazi c.
yes one minute let me explain it
View paste
I have two applications lets say A and B. application A have a deep link to app B, both require authentication so I want to open app be from A and send it the auth token I have so when app B is opened the user will not have to authenticate
I'm wondering what is the most secure way to send the token between the apps?
I thought using IPC but I cant find a way to sent directly just to save it on some storage and then app B will read it from there
9:45 AM
Mark M.
I have not seen any successful implementations of what you describe, because it winds up being fragile. What happens to App B if App A is not installed? What happens to App B if App A is installed, used, then uninstalled?
but in terms of secure IPC, a bound service is probably the best, though any IPC in theory should be secure
ndrocchietto_ivano
(why not a PendingIntent?)
Mark M.
Ivano: because a PendingIntent is not IPC; it enables IPC
ndrocchietto_ivano
(ok thanks)
Mark M.
Hazi: you cannot rely on App B being able to access this token from anywhere outside of App B, as there may not *be* anything outside of App B
Hazi c.
Do you know if it is possible to send data directly between two apps without saving them to some local DB first? (as in SP/SQL/etc)
Mark M.
sure -- use IPC
Hazi c.
I have tried an IPC implementation using AIDL, but had to save the data locally
Mark M.
pass the token as a String in an AIDL method parameter
or, if the token cannot be represented as a String, pass it as a byte[]
if the token is massive (100+KB), ask yourself why the token is so big
9:50 AM
Hazi c.
It can be passed as String. A developer in my team tried to look into the AIDL solution, or IPC in general, he could not find a way to share data between processes without saving the data locally
Is there any source or link you can refer me to?
Mark M.
I have a chapter in "The Busy Coder's Guide on Android Development" that covers remote services with AIDL
it has a few sample apps
they involve passing strings around, and they do not persist those strings to local storage
View paste
so, for example, if A will push the token to B, B would have a service with an AIDL interface like: 

interface AppBService {
  void hereIsTheToken(String token);
}
App A binds to the service from App B and calls hereIsTheToken() on its AppBService proxy
App B gets the token in its AppBService.Stub subclass implementation of hereIsTheToken()
no local storage required
Hazi c.
Alright, great, this is really useful and seems to be exactly what we were looking to achieve
I have one more question please, if possible
Mark M.
go right ahead
(Ivano, if you have another question, chime in)
9:55 AM
Hazi c.
Lets say I have a View (CardView for my current example). In some cases, by some business logic, I am changing the CardView's background. At end of everything, I want to restore the CardView's background to the default one it started with (usually depends on the API/Style/Theme the app is using)
So the quesiton would be, how could I restore that CardView background? Can I load it using a style? Is there any method to create a background Drawable from a style in runtime?
Or perhaps there is a much easier solution I wasn't aware of
Mark M.
what I would try is calling getBackground() on the View, holding onto that Drawable, and later calling setBackgroundDrawable() to restore it
Hazi c.
So we did that as a temporary solution and decided to ask you :)
ndrocchietto_ivano
(no questions mark, thanks)
Mark M.
did you run into a problem with that approach?
Hazi c.
No, but it made me wonder if there is indeed a way to restore a view's default background at any point?
Just decided to ask out of curiousity
Mark M.
I cannot think of a good way to do that, other than to re-inflate the layout resource
ndrocchietto_ivano
(extract a method and make it static in an utility class with a view)
Mark M.
I'd hold onto the Drawable in the ViewHolder or something for this CardView, if there is one
ndrocchietto_ivano
(nice)
10:00 AM
Mark M.
otherwise, you might use getTag()/setTag(), though I haven't used those in years
Hazi c.
Yes, we're simply holding on to the default background until we need to apply it again
Mark M.
that's a wrap for today's chat
Hazi c.
Okay Mark, thank you for your time... That would be all for now
ndrocchietto_ivano
thanks
Mark M.
I will post the transcript to https://commonsware.com/office-hours/ shortly
Hazi c.
Much appreciate, have a good day
Mark M.
you too!
the next chat is Saturday at 4pm US Eastern
ndrocchietto_ivano
has left the room
Hazi c.
has left the room
Mark M.
turned off guest access

Tuesday, September 4

 

Office Hours

People in this transcript

  • Hazi corly
  • Mark Murphy
  • ndrocchietto_ivano