Singleton

You are familiar with the singleton pattern. It should be handled with care. It has the tendency to shift an object oriented program into a mess similar to good old C programs.

It has its advantages, though. Take this section as thoughts and a rule of thumb but not as strong rule. You follow your way.

You have to implement a GUI for your application logic. GUI code is split into two major parts: Layouts, menus etc. are defined in resources. Activities glue user actions and application logic together.

You activities will always need access to your components. How to get them?

singleton

Singleton pattern seams useful in this scenario. We defined a class SharkNetApp. This class represents the whole Android application.

It provides a static initializeSharkNetApp method. This method is called from our InitialActivity, see section Initialize. We create a SharkPeer instance in this methods and store it a static member.

This line of code works in any class of the project.

SharkPeer sharkPeer = SharkNetApp.getSharkPeer();

This helps a lot. We have a very convenient way to get reference to our SharkPeer object. There should be only a single SharkPeer object in any ASAP/Shark based application anyway. We figured it a good idea to implement it as singleton. And it works fine.