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.

  • 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 – Ajay Ramesh 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
  • 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
  • 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
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!

  • thanks for the feedback. Did you by any chance see my last comment on the original post? – Ajay Ramesh 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. – Ajay Ramesh 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.

  • 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? – Ajay Ramesh 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.

  • 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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.