I understand that the app uses Singleton pattern. I also understand that it is a controversial pattern. Some people like it and some people don’t. I like the discussion justifying the use of Singleton at the end of the chapter for the more curious. I’m not totally sold but I’m going to try to go with the flow and use Singleton.
What if the app has a SQLite database containing all the crimes. The crime list view can pull the crimes from the database and possibly allow a bunch of sorting and filtering options for the user to fiddle with in the UI. The user’s sorting and filtering choices are state of the crime list fragment and applying them to the list of all crimes might be a time-consuming process. When the user taps on a crime in the list and switches to the pager view in chapter 11, the pager view’s list of crimes needs to match the list shown in the crimes list. The crime list fragment can pass the list of the user’s sorting and filters choices to the pager view as bundle arguments. Then the pager view can get the full list of crimes from the Singleton (getting them from the database) as shown on page 220 and then apply the sorting and filter options to the full list of crimes. This seems quite wasteful and will result in a slow user experience because applying the sorting and filtering options is time-consuming. I suppose that the crime list view could make its sorted and filtered list of crimes available in some global store and then the pager view could pull it out but that is getting well into the bad kind of singleton.
What to do in this situation?
Also, I was taught to avoid the Singleton for the unit testing reason mentioned on page 180. It says “Android developers usually solve this problem using a tool called a dependency injector.” I would have loved to see a code snippet right there that would show how to inject a dependency into an activity and/or fragment. Not using a library like Dagger. Just show how the injection would happen.