I’m wondering what you’re preferred architecture would be for the hard challenge. There are two rather straight forward options:
- CrimeFragment shows and passes mDate to an “Options Dialog,” which in turns shows and passes mDate to DatePickerFragment or TimePickerFragment. In other words, mDate (among other items) gets passed down the line.
- CrimeFragment shows and “Options Dialog,” and upon onActivityResult() shows and passes date to DatePickerFragment or TimePickerFragment. In other words, the Options Dialog drives the flow.
I attempted both, but found that in order for Option 1 to work you need to “boomerang” the result of DatePickerFragment or TimePickerFragment back to CrimeFragment (instead of passing back to Option Dialog, and then having Option Dialog pass back to CrimeFragment); the Option Dialog fragment gets an onDestroy() call when it’s view is destroyed. This could have been an elegant solution that reduced coupling (CrimeFragment only knows about Option Dialog, freeing up Option Dialog to know about Date Pickers and Time Pickers and possibly other pickers in the future). Maybe there still is a way…?
Option 2 couples CrimeFragment to all the dialog fragments, but maybe that’s unavoidable. I get a funny code smell that I need to if-else / switch in CrimeFragment’s onActivityResult() to determine which DialogFragment is calling back; the behavior we desire is to get a callback about a modification to “date,” and DatePicker and TimePicker do this (Dialog Picker is the odd man out, which is what lead me to try implementing Option 1). I think we could handle that without any conditional code.
How would you manage these object interactions?