Office Hours — Today, January 18

← Tuesday, January 16

Jan 18
7:20 PM
Mark M.
has entered the room
Mark M.
turned on guest access
7:25 PM
Susheel
has entered the room
Susheel
Hi Mark!
Mark M.
hello, Susheel!
how can I help you today?
Steve S.
has entered the room
Mark M.
hello, Steve! Susheel arrived first, so I'll take your question shortly
Steve S.
Hi Mark. Sounds good
Mark M.
Susheel: do you have a question?
Susheel
I am working on an issue with Dialogfragments. I have two instances where I am showing two different DialogFragments. The first one is to be shown based on some business logic. The second one is to be shown on a button click. Also the first one is shown inside a fragment and the second one is shown inside an activity. Both the dialogfragments are shown when my screen is rotated. But the first dialog is dismissed when I turn off the screen and turn it on back.
Sorry that was a long question
Mark M.
you are showing two dialogs at once?
Susheel
So the problem is that the first dialogfragment is dismissed when I turn off the screen and turn it back on. No there are separate instances. I am just perplexed by the different behavior.
these are*
7:30 PM
Mark M.
you say that the first DialogFragment is displayed by a Fragment
Susheel
yes
Mark M.
when you show that DialogFragment, what FragmentManager are you using?
Susheel
I am just using getActivity().getFragmentManager.
Not the v4 version
Mark M.
OK, so, in both cases, then, really the activity is showing the DialogFragment
Susheel
yes.
Mark M.
then I don't have much to go on
personally, I try to avoid dialogs where I can
I can't remember the last time I tested your screen-off scenario
but at most it should just be equivalent to a configuration change, so I'm at a loss as to what might be different between the two
Susheel
Well for one thing the newinstance method is not called in the 2nd dialogfragment for screen rotations.
if that helps
Mark M.
it can't be
the framework uses the constructor
Susheel
It is for the first instance though
Mark M.
that's why we need a public zero-argument constructor
that's not possible
Android knows nothing of that method
*you* might be calling a newInstance() method, but the framework is not
Susheel
But that's because I am triggering the show based on some business logic. not a button click.
Mark M.
but that does not matter for a configuration change
the point of DialogFragment is to keep the dialog around during a configuration change
7:35 PM
Susheel
That's true!
Mark M.
you should not be creating a new instance of the DialogFragment on a configuration change, like a screen rotation
Susheel
right
Mark M.
so, perhaps there's something in your business logic that is the culprit
Susheel
It is highly likely
thanks for the input
Mark M.
sure!
let me take a question from Steve, and I'll be back with you in a bit
Steve: your turn! do you have a question?
Steve S.
I'll paste in my question:
View paste 
I have a question concerning ordering database operations. In my app I create subclasses of Thread for database accesses, modeled on your approach in EmPubLite. In one activity, the user edits "recipes." Changes to recipes are  saved to the database when the user clicks Save. In a second activity, the recipes are retrieved from the database in onCreate() for the user to work with. 

The user needs the updated list of recipes in the second activity, but as far as I can tell there is no guarantee that database changes made in the first activity will occur before the database retrieval in the second activity. To guarantee the ordering, should I use an IntentService for database operations? Is there a better approach?
Mark M.
the better approach is to only load the data from the database when needed
Steve S.
ok
Mark M.
ideally, the second activity is working off of the same in-memory representation of the recipe as the first one, or a logically-equivalent instance
Steve S.
i'm using singleton caches
Mark M.
OK, so why does the second activity need to read from the database?
the updated recipe is already in the cache, right?
Steve S.
i was simplifying
the concern is that the cache won't be updated via the first activity before the second activity starts
Mark M.
update the cache on the main application thread
before control gets to that second activity
Steve S.
ok
7:40 PM
Mark M.
if right now, you are waiting to update the cache until after the database I/O is complete, you would need to delay starting the second activity
Steve S.
so i should prevent navigation to the second activity until the cache is updated by the first actvity?
Mark M.
I would think that would happen automatically
the user clicks Save
you update the cache
you kick off the background database I/O to persist the change
Steve S.
sorry - i see what you're saying. of course
Mark M.
and then you do whatever it is that you are doing to get to that second activity (startActivity(), finish(), etc.)
Steve S.
sure. that seems like a reasonable approach
i will also think about whether retrieving the data in the second actvity could be delayed
Mark M.
if you can work off of the cache, that hopefully is unnecessary
Steve S.
sure
Mark M.
let me switch back to Susheel, and I'll return to you in a bit
Susheel: your turn! do you have another question?
Steve S.
sure
Susheel
I don't have a question Mark. Thanks for your help.
7:45 PM
Mark M.
you're welcome!
if you come up with another question, chime in
Steve: back to you!
Steve S.
Here's my other question:
View paste 
I am using the following pattern to manage persisted data used in setting up activities:
1. In onCreate(), I first attempt to retrieve the data from singleton caches.
2. If the caches are empty, I spawn a thread that refreshes the caches from the database and sends a message to the activity when it is done.
3. The activity then retrieves the data and finishes configuring the activity.

It seems to me that to guarantee that this scheme will work, I need to allow for the possibility that onStop() is called after the thread to retrieve the data has been spawned but before it finishes. In that case, finishing the configuration of the activity will need to be done after onStart() is called (assuming onCreate() isn't called again).

Am I right that this complication needs to be addressed? Do you have a good way of doing so (my solution is messier than I would like)?
Mark M.
"Am I right that this complication needs to be addressed?" -- insofar as onStop() might be called before the thread is done with its work, yes
Steve S.
ok
Mark M.
"Do you have a good way of doing so" -- move your onCreate() logic into onStart(), perhaps
Steve S.
i was wondering about that, but was concerned about repeating operations multiple times that could be done just once
Mark M.
it's a three-stage process, from what I can see:
Stage #1: you look in fields of the activity to see if you have your stuff, and if you do, you're set
Stage #2: you look things up in the cache, and if it's there, you're set
Stage #3: you fork the thread and react when the I/O is done
so, suppose onStop() is called when the thread is still chugging along
there are two possibilities when onStart() is next called: the thread is *still* chugging along, or its work is completed
in the latter case, Stage #2 picks up the data, and you're set
what you need to avoid is kicking off another thread to do the I/O, if you can avoid it
7:50 PM
Mark M.
ideally, the thread work isn't done by the activity, but by the repository (or whatever cache manager class you have going)
Steve S.
ok. i think i understand your suggestion. i will look into it
this would be done from a database helper subclass
Mark M.
which hopefully is a singleton in its own right
Steve S.
yes
Mark M.
if so, it needs to keep track of whether the I/O is in progress or not
so it can avoid the duplicate I/O work
in the end, this isn't going to be a terribly common scenario
avoiding the extra I/O is a good optimization, but don't tie yourself into a pretzel over it
Steve S.
i'm using GreenRobot event bus and was thinking of using sticky events to indicate when the work is done
Mark M.
that might work
the "state of the art" in this area would use RxJava and stuff to try to tie the threading and state tracking together
Steve S.
i have been thinking that's something i need to learn to help with these kinds of scenarios
Mark M.
it has a learning curve that resembles a cliff face, with you at the bottom
however, there are reasons why it has become popular
Steve S.
right, so not for this project
Mark M.
I have been doing more with that over in the "Android's Architecture Components" book
7:55 PM
Steve S.
great. i'll check it out
this has been very helpful. i was locked into particular ways of looking at things, so it's great to get a fresh perspective
thank yo so much, Mark!
Mark M.
you're welcome!
Steve S.
have a great rest of the day!
Mark M.
you too!
Steve S.
has left the room
8:00 PM
Susheel
has left the room
8:25 PM
Mark M.
turned off guest access

← Tuesday, January 16

 

Office Hours

People in this transcript

  • Mark Murphy
  • Steve S
  • Susheel