Model building for 10.000

When I started working on the 10.000 game, I had some ideas and concepts I wanted to try out when building the model. I’d like to share some of my thoughts on the process and the product.

What is the objective of the model?
My goal with the model was to make a clear separation between the logic and state of the game and the user interface. The benefits I was hoping to achieve was first and foremost a division of the task at hand, by dividing the application into a user interface part and a model part. Secondly making it easier to swap UIs, by decoupling it from the model, in case I’d redesign the UI later on. Thirdly I wanted to encapsulate the variables that stored the state of the game, thereby making sure rules would be enforced and thus keeping the model in a valid state all the time.
A lot of this stems from the teachings and common programming practices like the MVC architectural pattern and I saw no reason why this solution couldn’t be applied to the task at hand.

What is the tradeoff?
All of these benefits comes at a cost of course. During the development of the game I kept track of how much time I spent on the different tasks. I’ve given a short list below of the time allocated to different tasks (this only covers the initial version).

  • Designing the solution: 24% (~16 hrs)
  • Graphics: 5% (~3 hrs)
  • Programming UI: 37% (~25 hrs)
  • Programming model: 28% (~19 hrs)
  • Testing and debugging: 4% (~2 hrs)
  • Publishing: 3% (2 hrs)

I can’t say for sure, but I guess that if I had merged the model and UI and didn’t care about the benefits that the seperation gives, I could probably have saved 10 hours divided evenly between designing and programming, which equates to something like a 15% reduction. This is of course my ad hoc estimate based on the size and complexity of the game and it’s rules. I don’t think you could use this as a generic rule πŸ™‚

Encapsulation vs. performance
Another thing to consider is the fact that the encapsulation adds a layer of method calls that could be removed, if variables where directly accessed in the code. I read that internal getter/setter methods should be avoid, due to performance overhead. I’m guessing merging classes and then accessing variables directly would yield the same benefits.
I haven’t tried profiling the game, to see if there are any performance drops. The tests I’ve done on the UI haven’t had any issues so far, like an ANR for example.

What benefits did this give after release?
After the first release I’ve made some improvements to the game. These have been bundled in three new versions. All of these have been rather fast to develop and I contribute a lot of this to the initial investment in time spent on design and model programming. Again, if I where to venture a guess I’d say that the time I could have saved on the initial release I’ve gained in the latter releases.

So I think my bottom line is; Solid design and good programming practices saves time in the long run.
It has certainly saved me a lot of frustration πŸ™‚

On the “Android Activity Lifecycle”

As I dig into the coding of the next app, I’ve inevitably run into the Android activity lifecycle. Initial thought: Wow, that’s nerdy πŸ™‚

The lifecycle pyramid

The picture below shows the “lifecycle pyramid”. Simplified the app transitions through a series of different states, from left to right with the occasional backtracking. This of course depends on how the user interacts with it.

First impressions

What first struck me was the way the different states are reached and how chaotic it seems. Having read a little more from the Android Training classes, it quickly made a lot more sense to me. The app is started, it has a “running” state, it can be paused and eventually terminated.

In the above pyramid there are quite a few arrows between the different states, illustrating the method calls that are being made by the JVM, when each transition occurs. This got me thinking; “Why not try it out and see what and when everything is invoked?”. The guys at Google of course already thought of this and madeΒ an example of this, but I’m more of a hands-on guy sometimes.

onResume and onPause?

The lesson I’m trying pass on here is this; When you start up you activity a series of methods gets called per default (OnCreate, OnStart and OnResume) and then you’re good to go. What surprised me is at if you hit the menu button, gets interrupted by a call or even if you rotate the screen, your activity gets destroyed and rebuilt. Of course you can’t be totally sure that it gets destroy on every occations, but you should program as if it did.

You should therefore always save your state when your activity gets paused (onPause), ’cause it might get destroyed. When you return to your activity, you should restore the state in the onResume method. This way you ensure that nothing is lost if your activity loses focus or the screen gets rotated.