Using a Singleton Over an ArrayList Object for CrimeLab

#1

Hello everyone! As I’ve been working through this project, I couldn’t help but wonder why we are using a Singleton for the CrimeLab class. Or rather, why are we creating a completely separate class for Crime objects in the first place?

What I’m getting at is that if I were to recreate this project on my own without any of the new knowledge that I’ve obtained through reading this book (which has been great so far, btw!), I would have probably just encapsulated my List of Crimes in my CrimeListFragment class.

For example, instead of writing up an entirely separate class like so:

public class CrimeLab {
private static CrimeLab sCrimeLab;

private List <Crime> mCrimes;

public static CrimeLab get(Context context){
    if(sCrimeLab == null)
        sCrimeLab = new CrimeLab(context);
    return sCrimeLab;
}

private CrimeLab(Context context){
    mCrimes = new ArrayList<>();
    for(int i = 0; i < 100; i++){
        Crime crime = new Crime();
        crime.setTitle("Crime #" + i);
        crime.setSolved(i % 2 == 0);
        mCrimes.add(crime);
    }
}

public List<Crime> getCrimes(){
    return mCrimes;
}

public Crime getCrime(UUID id){
    for(Crime crime : mCrimes){
        if(crime.getID().equals(id))
            return crime;
    }
    return null;
}

}

…I would have just included another member variable to CrimeListFragment:

public class CrimeListFragment extends Fragment {

private RecyclerView mCrimeRecyclerView;
private CrimeAdapter mAdapter;
private List<Crime> mCrimesList;
.....

I’m not even sure if it would work. However, if someone believes that it wouldn’t work, why wouldn’t it?

I understand that Singletons will continue on to “live” within the Android OS’s memory until the OS decides additional memory is needed. Hence, even if the app is off-screen, the data will still be readily available, at least for some period of time. Is that one reason why using Singletons are preferable? Because the data will still be there once the app is closed?

And would the method that I’m suggesting not be preferable because the List would be gone once the app would be off-screen? These are the reasons I came up with myself as to why Big Nerd Ranch decided to use this strategy. However, any clarification on this topic would be appreciated :slight_smile:

Side question: Would the Singleton still exist within the OS’s memory after onDestroy() would be called upon the app?

#2

Hey, I was just wondering if you ever got your code to work without implementing the Singleton. I’m working on the same thing now and I was hoping you had already figured it out lol, thanks!

#3

Hey! Unfortunately, I never got this to work… CriminalIntent is a huge portion of the book and it becomes more complex as you continue to work on it (don’t feel discouraged though, it is doable and you’ll learn more than you thought you could!). Getting it to work with what I was initially proposing might have been possible, but I’m sure I would have ran into bugs and errors. I can’t say for sure though since I continued on with the book’s implementation. That’d be my recommendation regardless, since you’ll eventually make the CrimeLab more sophisticated such as creating a SQLite database out of it.

The other main reason that I could think of to do it this way would be to maintain the MVC architecture, which is explained in chapter 2. By splitting up CrimeLab from CrimeListFragment, you’re essentially maintaining encapsulation between your model layer (CrimeLab) and your controller layer (CrimeListFragment).

I hope all of that makes sense, it’s the best that I could think of. Let me know if you need additional clarification though.

#4

Hey thank you very much! Nice explanation, no clarification needed! Adhering to the MVC architecture is my main priority so turns out making CrimeLab its own model layer is what I wanted to do after all lol.

#5

Not a problem, best of luck!