1

Building an android app that displays a list of of Dog objects in Activity A. When you a tap a Dog in the list, that single dog is accessed by Activity B, Fragment B, and 3 other classes.

After that Dog is modified, it gets passed to Activity C and Activity D that all modify it, before finally making a network request.

Currently, I pass the same instance of Dog back and forth through activities, fragments, and classes using callbacks, parcelable extra in intents, and bundles for fragments. This is getting really messy really fast. Is using a Singleton a good idea in this situation?

If Dog were a singleton, how can I load multiple Dogs to begin with?

Think of the list of Dogs as a list of empty boxes. After a single Dog is selected, it goes through a conveyer belt of Activities, Fragments, and helper Classes, where the box gets filled with data. At the end of the user flow, this box is filled up with a bunch of information, ready to be shipped off to the backend server.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
aaa
  • 139
  • 2
  • 4
    It's kinda difficult to get an idea of your overall program structure from your description. Generally speaking, "Should a singleton be used", a lot of the time the answer will be 'no', but you need to consider the size and scope of your application. – Matthew Jan 26 '17 at 16:17
  • @Matthew added an extra paragraph to try and clarify – aaa Jan 26 '17 at 16:19
  • 1
    This sounds like you construct your `Dog` before you have all the information you need to complete it. A better solution would be to build the components your `Dog` consists of first, say `Hairstyle`, `TailWagglingMode`, `TongueDrippiness`,... that you construct in your activities, and once you've got everything you need, you wrap it all up in a `Dog`. – Hulk Jan 26 '17 at 16:24
  • @Hulk that's a good idea, but this list of `Dog`s will come from the server, and will already contain *some* preliminary information like, `name` and `birthday`. Would using something like `EmptyDog` for the list, and then spawning a `Dog` singleton in `Activity A` which is to be used throughout the rest of the userflow, work? – aaa Jan 26 '17 at 16:27
  • I still wouldn't use a singleton. A separate Class for the basic information you receive from somewhere else would be a good idea, though. – Hulk Jan 26 '17 at 16:32
  • You basically already admitted that you mostly want to introduce the singleton because it would make accessing it more convenient - the problem with this is, it also makes it less obvious where and when it is accessed from any point in your program, because it could be accessed from *everywhere* at *any* time. – Hulk Jan 26 '17 at 16:37
  • @Hulk since I haven't seen this in practice before, I'm having trouble seeing how it would make it less obvious. Wouldn't seeing `Dog.newInstance()` in a line of code suggest that it's being accessed? – aaa Jan 26 '17 at 16:39
  • No. Never use a singleton – Ewan Jan 26 '17 at 16:46
  • @Ewan please provide a justification or alternative solution – aaa Jan 26 '17 at 16:47
  • 2
    you dont want a singleton, you want a global variable. global variables are bad. structure your code better! I cant tell you how unless you post the code – Ewan Jan 26 '17 at 16:49
  • @AjayRamesh this question is related: http://softwareengineering.stackexchange.com/q/252/187318 - the answers provide a lot of solid reasons to avoid singletons. – Hulk Jan 26 '17 at 17:28
  • 1
    I think @Ewan's comment goes to the heart of the confusion. The OP appears to be conflating the concepts of the Singleton pattern with that of global variables. – Erik Eidt Jan 26 '17 at 18:04

3 Answers3

1

I don't think that you should use a singleton pattern in this case. So if you implement the Singleton correct, there is only one instance for the dog class. If you have a list with dogs, it's not possible for you to implement a singleton if you don't want to show the same dog in every line. So you have a reference to the dog like this Dog dog = Dog.getInstance();

Everytime you access the getInstance Method, the singleton will return you this one Object. Everything you change, is changed in this one object. So if you want to have more than one Dog, the Singleton pattern isn't the right way for you!

Gulliva
  • 111
  • 2
  • thanks for the feedback. Did you by any chance see my last comment on the original post? – aaa Jan 26 '17 at 16:30
  • Ok, but why do you want to use it this way? Why didn't you pass the Dog object through the Activities? After you filled your dog, the singleton is useless i think – Gulliva Jan 26 '17 at 16:33
  • the dog is filled in multiple activities and fragments within those activities. – aaa Jan 26 '17 at 16:41
0

Should a singleton be used in the following case?

No, seems like it wouldn't work.

Perhaps you have a new responsibility that you should create its own class for - namely that of having a selected dog and the moving of it through the activities. The selected dog would be a member of that class, i.e. some fixed state per instance object, for all methods (of that class) to work on (and without using the singleton pattern).

With that perhaps you can have different dogs in different flows in parallel.

Erik Eidt
  • 33,282
  • 5
  • 57
  • 91
  • I'm having trouble seeing how this is different from using a singleton. If we have some class like `DogMaster` that contains an instance variable `Dog`, and `DogMaster` contains methods that modify it's single `Dog` instance, how is that different from just making `Dog` a singleton? – aaa Jan 26 '17 at 16:40
  • 1
    You said in your question that you have list of *multiple* `Dog` objects. If `Dog` were a singleton, there **cannot possibly be** multiple `Dog` objects. There can only be exactly one. – Jörg W Mittag Jan 26 '17 at 17:55
0

Nothing in your description implies a need to limit Dog to a single object. This suggests that doing OOP gymnastics to ensure you don't end up with two Dogs at the same time is not a good idea. How could two Dogs possibly crash or corrupt your program in the scenario you describe?

Singleton is usually a bad design pattern to begin with. Keep in mind that design patterns are generalized solutions for OOP languages in cases where the language itself is unable to handle the situation naturally. When you use a design pattern, you usually do it because you don't have a more natural solution.

Trixie Wolf
  • 414
  • 2
  • 6
  • 1
    "Nothing in your description implies a *need* to limit Dog to a single object." – Indeed, the question explicitly mentions a "list of `Dog` objects", which is plain simply logically inconsistent with `Dog` being a singleton. – Jörg W Mittag Jan 26 '17 at 17:57