Why to Avoid Dynamic Tabs on Android and iPhone Development

Recently I began finishing my first Android application.  They app itself is pretty simple in my mind, but actually creating the application has proven much more difficult than I thought it would originally.  This difficulty is mostly due to things like creating and managing databases for storage, utilizing fragments instead of activities for new screens, and creating user-interfaces that are quick and responsive without requiring multi-threading.

Clicking "Button 1" should insert a new tab
between tab 2 and tab 4

The bulk of my problems have been caused with creating the user-interfaces.  A recent problem I ran into was displaying large amounts of information on a single screen.  My original approach was a tab-based system, where users could add new data sections, which would then appear as a new tab.  These tabs could then be scrolled through, and each one would contain a different sub-section of the application.

The big requirement for this however was the need for dynamic tabs.  That is to say, I needed to be able to easily insert a tab between two other tabs.  This proved impossible with the default TabHost object, as there is no insert method available with it.  I opted then to simply remove the last tab, add on my new one, and then re-add the deleted tab.

It was at this point however that I realized that this was a surprisingly weird feature to leave out in the ADK though.  In fact, my thought was that this must be a bug in the ADK, as this seems like something that everyone would want.  Taking the problem to Google showed a few forum posts about this as well, though it didn't seem like anyone had a good solution.  In fact, I still don't have a good solution other than this, and the steps involved get even more complicated.  You can't just "delete" a tab, you actually have to remove both the tab itself, as well as the content that the tab shows, then add the new tabs.

This is much more complicated than it needs to be though.  Why not have an "insertTab" method for the TabHost?  Why would such a seemingly important method be left out?  While I can't confirm the accuracy of this, I believe I actually found the reason, and it's the exact reason why I opted out of using tabs for this purpose (well, sort of, more on that later).

Let's start with an example of bad tab usage:  imagine you are looking at someone's internet browser.  Imagine this person is me, and when you look at the amount of tabs in their chrome browser, you see this:

Kind of painful to look at that many tabs isn't it?  That's the point I want to bring up: dynamic tabs in an application are very dangerous and bad for the user.  It makes sense that dynamic tabs are not supported, as it would very quickly become a cluttered interface as the user added more tabs to the screen.  If you force your user to create a new tab to view content, looking through that much data can be annoying.  Even if the tabs scroll, that can still be overwhelming when trying to view the page.

There is also another problem that occurs, especially in older devices: memory limits.  If you start adding more tabs, you'll find that your memory usage skyrockets.  This is nothing out of the ordinary though, and is a problem that can be easily combated by simply limiting the maximum number of tabs, but it's still a problem nonetheless, and is prevented by not allowing dynamic tabs.

There are probably a variety of other issues that come up with dynamic tabs, so this brings in the question of whether dynamic tabs should even be used.  In my case, I realized that tabs would not be the most efficient way to achieve what I wanted, so I scrapped them and took on another solution.  The solution I took was instead to use a spinner, and updated the content based on what is selected, as well as breaking up where the data is displayed.  By using a spinner, you allow the user to display more at once but with less clutter due to how spinners are designed, and by breaking up the data, you help guarantee that the user can never overwhelm themselves on accident.

There are of course other solutions that can be done other than spinners and breaking up the data, those are just the ones that I chose.  If you've encountered a similar issue, what was your solution?