I'm building one of my first android apps. I met this problem that everytime you change screen orientation, Android destroys the app and builds it up again (I know this is more complex, but this isn't the subject of this post.)

I am wondering if it is good idea to have a Game game variable inside my MainActivity.java that would simply implement Serializable. This way I can do this:

public class MainActivity extends AppCompatActivity {

    private MagicSquareGame game;

    protected void onCreate(Bundle savedInstanceState) {
        game = MagicSquareGame.getEngine();

    (all the other stuff...)

    protected void onSaveInstanceState(Bundle outState) {
        outState.putSerializable("game", game);
        Log.i("MSG", "saving Game");

    protected void onRestoreInstanceState(Bundle savedInstanceState) {
        game = (MagicSquareGame) savedInstanceState.getSerializable("game");
        Log.i("MSG", "loading Game");

Is this an okay approach? Code smell? What problems can I meet?

  • \$\begingroup\$ Can you post details of MagicSquareGame (members/fields)? \$\endgroup\$
    – petey
    Commented May 18, 2017 at 16:37
  • 1
    \$\begingroup\$ You should implement Parcelable instead of Serializable because a) it's made for this purpose and b) performance bec ause a). \$\endgroup\$
    – JimmyB
    Commented Jun 2, 2017 at 11:19
  • \$\begingroup\$ But apart from that, your approach is basically what Google intends you to do. As an alternative, e.g. if you need to preserve large state, you may look into subclassing Application which lives (at least) as long as the app runs. \$\endgroup\$
    – JimmyB
    Commented Jun 2, 2017 at 11:23

1 Answer 1


If this is a private project, where you're free to use alpha-staged libraries I'd strongly recommend you take a look at Android Architecture Components. A great talk about the subject was given at the recent Google I/O.

Restructuring your app's architecture and using Android Architecture component - the LifeData and LifecycleObserver in particular will very much ease the problem of having to deal with LifeCycle events (such as screen orientation change).

If you're writing a game, then the Component-based Architecture may be interesting for your purposes. You'll very likely come across it when investigating architectures suitable for Games (render loops etc).

The general idea is:

  1. Separation of concerns and improving testability. Ideally you should be able to unit-test your entire game with locally running Java tests and no UI necessary whatsoever. This however requires you to separate your Game instance from your activity - something I'd highly recommend either way.
  2. Making your game modular and plugging it together in the form of components (this architecture style is a matter of preference but lends itself quite well to games)

Let me know, if you want me to elaborate on any of the points I mentioned.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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