This is a fun little post I thought I could do really quick. While I'm still getting the hang of using shaders and such, recently I thought of something that I thought was kind of clever to do with shaders. This is a quick post about what the problem was and how I solved it. Shout out to Michael C. Johnson for suggesting to blog about this!
Showing posts with label android development. Show all posts
Showing posts with label android development. Show all posts
Wednesday, July 9, 2014
Tuesday, July 1, 2014
Photos of the Month - June 2014
With June finally over, it's time for some new photos of the month! While not as high of quality as last months, I still found these to be quite good!
Thursday, June 26, 2014
Google Cardboard - A Perfect Start for Virtual Reality
Man, it seems like I've been on a VR rant these past two days now. Let's cut straight to the point on this post: Google Cardboard is the exact thing virtual reality needs right now. It's cheap, it's (fairly) high quality, and anyone can get it right now. This kind of access is the perfect push for anyone who wants virtual reality to succeed, and while the Oculus Rift and Control-VR might have a nicer case, Google has managed to blow them both out of the water. Let's go ahead and review everything really quickly.
Sunday, June 8, 2014
Class, Jobs, and Glass!
Phew, it's been a busy month, and unfortunately I've slacked quite a bit on posting to this blog. But no more, for I have returned! For the next few days I plan to post quite a bit on a variety of topics, as I've had some really interesting experiences these past few weeks, with even more coming up!
Monday, February 17, 2014
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.
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?
 |
| Clicking "Button 1" should insert a new tab between tab 2 and tab 4 |
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?
Subscribe to:
Posts (Atom)