Now, this is something I have seen done way too many times, mostly in applications that are obvious ports of their iPhone counterparts. This is the kind of thing where you can literally create an infinite number of new activities in your application because two activities are capable of calling each other. I’ve mainly seen this done in apps that are trying to implement a Tab Bar like UI element. As I stated before, this really does not work, not in the same way that it works on the iPhone. The problem is with the iPhone you have this nice clean container, called the Tab Bar Controller that holds all of the views displayed by it, it and only it handles their lifetime. You don’t get something like that in Android without building it yourself from scratch. If you think of it, as Android is meant to be developed, then each Activity has its own view. So, what most people end up with, when trying to implement a Tab Bar, is to create a separate Activity for each Tab/view of the Tab Bar, each with the capability of calling all of the activities in the Tab Bar. The problem with this is, you end up with two or more activities capable of calling one another.
Think of it like this, every Activity has a specific purpose, a specific action that it is meant to perform, the only time you should call a new activity is if you want to take what you have already done and perform further actions with it. A Tab Bar is a collection of multiple, different, completely separate actions; they don’t need each other, so why should they call one another into existence. Every new activity is meant to perform an action and then return to the previous activity. Therefore any time you create a set of Activities capable of calling one another, you’re actually breaking out of the architectural patterns of the android platform, a risky thing to do on any platform. In the end, all you really get from your endeavor is a never-ending tree.
From the Home Tab you can call an intent for either the Find Tab or the Account Tab creating an entirely new activity upon selection. Then, from the Find Tab you can reselect the Home Tab or proceed on to the Account Tab, both options create an entirely new activity that is completely unaware of the previous Activities’ existences. As a user you could actually go back and forth between any two tabs countless times, creating a seemingly unending path of activities once you try to start going back through the application. This horrible infinite loop/never-ending tree can be created in many other ways than just attempting to implement Tab Bar like functionality. So, avoid it all costs. Not only will this save you from a lot of memory issues, but it will also make your app feel a lot more congruent.
I realize this has been a fairly short part to this series, but I’ve seen this done far too many times to let it be a side point to another part. So, if you want a great way to make sure that your users delete your application from their device and write you a hate-filled review, make sure you have a nice, ugly infinite loop to trap your users in. If not, please, test your apps forward and backward. Ensure that it is entirely impossible for your application to find itself in this lovely infinite loop.
