Page 12 of 12

The Shopper Development Update – C

This morning was by far one of the most productive mornings I’ve had in quite a while. I posted on Google+ that I was definitely in workaholic mode and that certainly wasn’t a lie.

So where to begin with The Shopper…

As a developer, I have a really nasty habit of incorporating test code into production code. This particular type of injection is required sometimes when I’m testing out a portion of the API that I’m unsure of which is fine. However what isn’t fine is when that code sticks without any type of polish. It then sticks out like a sore thumb and begins to pollute the rest of the project.

I like to think of the theory of broken windows here which I first heard of reading The Pragmatic Programmer.

So I sat back and literally, on my dry erase, sketched out the workflow as it should be at this point and catered the code to match. The results were astounding. I was actually seeing a performance gain on certain methods. Importantly I didn’t feel like I wanted to rip my hair out thinking about the mess I’d made.

A very important feature was completed and that is contextually sensitive menu items in the ActionBar. Logically it doesn’t make sense for all of the icons in the ActionBar to be present all of the time. It makes even more sense to only have certain icons present when certain conditions are satisfied. The benefits here are batch operations and to prevent users from doing something that, at that time, doesn’t make any sense (also eliminating exceptional circumstances). For example, you should be able to add an item at any point in time so the add item icon is present at all times. You can’t edit an item without first selecting one so that icon is hidden until an item is selected. You should be able to delete any number of items so when at least one item is selected, the delete icon is present. However you can’t batch edit so when more than one item is selected, the edit icon disappears (this is something that I think would be nice but would be difficult to express cohesively via UI).

For the time being, all custom styling has been dropped and the theme reverted back to the default Android Holo Light theme. Styling is a little more involved than I’m willing to give time to right now so it’s going to have to wait until a later date when more important things are complete.

The last big thing that was finished was a bit more technical.

Google has openly admitted that using the findViewById API is a bit expensive. More importantly, it can become cumbersome and redundant. A while ago I devised my own fix to the problem: why not store single references to the Views that are relevant per Fragment and Activity and issue calls to findViewById just once post inflation? The references were wrapped in a static class that was unique to each Activity and Fragment and this worked for some time. However some things were painfully obvious about the design here. This was taking redundancy to an extreme. Each Activity and Fragment had their own class which had the same design and same interface just different members. Typing this thing out over and over again was tiring but more importantly it wasn’t very good practice.

A thought occurred to me this morning: why not parameterize the members of this class? Seeing as how that was the last “least common denominator” challenge yet to be tackled, overcoming that meant that a separate entity could be created that could be distributed to each Activity or Fragment that required it. More importantly, if designed properly, it could hold instance-based references to other things like MenuItems. Thus ReferencePool was born.

The details are simple really. ReferencePool contains a collection that stores a nested collection (more specifically a LinkedHashMap that stores a SparseArray). The key for the parent collection is a Class instance while the key for the nested collection is an integer ID which is expected to be the Android-generated ID found in R. The reason for this is that neither collection should be explicitly tied to any one particular descendant class (with the exception of SparseArray but it stores Objects). That being the case, it would be really easy to lose the meaning of the object in syntax if the interface were not designed properly. Using a Class as a key helps to enforce, logically, that one SparseArray is linked to a specific type while making sense syntactically (derived contextually from reading the source). The method that gets an object from the collection uses generics (actually the whole class does) to return an Object casted specifically to the Class used as the collection key.

Despite my efforts to keep the collections as type-agnostic as possible it would be a valid statement to say that to some degree they aren’t. SparseArrays store Objects thus regardless of the Class key used in LinkedHashMap, you realistically could dump anything in there so long as you remembered the integer key for the Object in SparseArray. The goal was more syntactic. Originally I left it up to the client to cast out to whatever they needed by simply returning Object from the get method. So you either had one of two client situations: declaration with casted assignment or anonymous classes with nested parentheses; neither of which I wanted in client code and didn’t really suit the intended nature of the class and its interface. What I got instead, after implementing generics for the get method, was an inline generics declaration before the method call which looks a lot nicer and does what you would expect it to do. An example is here:


So far this is working out nicely.

Quick Thought – How I Updated Content in a TabHost

Every project introduces a few new challenges. Especially when you’re trying to add features that require you to do things that you didn’t to in the last project or simply haven’t encountered before. But this is the fun part of software development.

Lest we forget, software development isn’t fun unless you’re pushing yourself to do things that you didn’t do before.

If you’ve read some of the previous posts regarding updates I’ve made to the latest version of The Shopper, you’ll notice that I’ve decided to use a TabHost to hold ListView’s that act as dynamic filters for the proper item listing on the right side of the screen. As far as I know, tabs in Android are still a bit fringe. Judging by the implementation details presented in my instance, I’d have to say that it’s not the most elegant solution for tabs in a GUI environment I’ve used (frankly setting up tabs in GTK is easier IMHO). Just to clarify, I’m not talking about declaring a View in XML, rather I’m talking more specifically about populating dynamic tab content in a procedural manner.

Just in that last sentence, therein lies the challenge. Defining your layout in XML is one thing. Having to react to user input and dynamically change content is another. While you can anticipate the methods in which the user will do certain things that will require your app to change in some way, this isn’t a solution context that can be adequately described in a layout XML file. Typically, despite the obvious violation of encapsulating data from GUI, a procedural solution is sometimes better.

So what exactly am I going on about? The behavior of The Shopper requires that the content of the lists contained in the TabHost change on a frequent basis. In fact, every time the user performs a transaction that revolves around an item (think in the context of CRUD for you DB people), that list content is almost guaranteed to change. Thus for every action, in order to ensure the user is seeing the most accurate data, the lists are updated.

The process of actually updating these lists isn’t hard and any novice Android developer can do this. Using Fragments as I have here only adds a small layer of complexity in the form of interface-based delegation through the hosting Activity. Again nothing too seriously mind bogging.

The problem comes in when you actually try to get access to a tab’s content. It’s not as straightforward as it seems. I also may be overcomplicating things but bear with me.

TabHosts contain TabWidgets. TabWidgets are the Views that hold the actual tabs. Each TabWidget hosts an arbitrary number of tabs that can be specified in either your layout XML or via code. Procedural exploration shows that TabWidgets actually contain what are called TabSpec instances. TabSpec defines an individual tab that will be inserted in the parent TabWidget via the TabHost (the API call to perform this operation belongs to the TabHost).

My first logical instinct was to assume that a TabWidget had an API that went something like this:


It’s extremely raw and definitely shallow (also totally unrealistic) but it makes logical sense and looks nice syntactically. One would think that because a tab (TabSpec more specifically) contains content that you could reference the View and use the findViewById API to update the content.

Turns out that it doesn’t really work like that. The API for TabSpec is extremely sparse. All it allows you to do is set the content and set the indicator (inflated View content and the text/View that shows on the tab). There really isn’t anything that you can do insofar as updating the content is concerned.

I decided then to go one layer up, to the TabWidget, to see if it would provide me with anything useful. Unfortunately it doesn’t; the design here really reflects well on the Android team for making sure that individual components stay separate entities which you have to admire them for. Upon first glance, some of the methods seem like they would work for the purpose: getChildTabViewAt for example. However this, and methods like it, only select the tabs themselves, not their content.

So here I was back at the TabHost after having gone down as far as I could go and working my way back up gradually with no success. Back at the TabHost, I knew a few things:

  • Tabs can be added or removed via the TabHost in a procedural manner. Adding tabs can be performed individually but removing tabs can only be in a Draconian manner (i.e. remove either all of them or none of them).
  • Tab content can be generated in a procedural manner via TabSpec. A new TabSpec can be added to a TabHost thus making it a visible tab to the user.

While completely barbaric in some sense, my solution thus became outlined in pseudo-code as such:

  1. Obtain a reference to the known existing TabHost
  2. Instantiate required variables of respective types for operation
  3. Use the TabHost to remove all tabs and their content
  4. Repopulate the data from the database into transitive objects
  5. Configure new TabSpec instances by assigning a text indicator and inflating a View that contains the ListView for the respective tabs. The ListView adapters would be assigned here using the transitive objects as data basis.
  6. Apply custom styling to the TabWidget
  7. Cleanup

In other words, what this all meant is that due to API restrictions, I am essentially removing all existing tabs from the TabHost, manually rebuilding and assigning them back to the TabHost. Like I mentioned before, this is quite barbaric and costly in some cases but for the time being, this seems to be the more mind-settling solution for me.

What made me do this? Nothing else I found on the matter seemed to satisfy me and remain simple. Occasionally I stumbled across a few people who suggested the use of ViewSwitcher and the equivalent for Activities (the name of which escapes me now). Logically these didn’t make any sense. All I wanted to do was update content for an existing ListView and not swap between an arbitrary number of them (which is what a ViewSwitcher is designed to do and is far more suitable for View animations than anything). More importantly, the ListView was self-contained meaning that changes or interactions in one tab didn’t directly or indirectly affect the content of another tab. This same logic applies to the ActivitySwitcher only backed with the argument of additional complexity of having multiple Activities instead of multiple Views.

The other argument made is why not just check to see if the tab content’s parent layout View exists and use findViewById? The content of the tabs is generated in a procedural manner to begin with. Thus at the time of initial layout inflation, they don’t technically exist. This conditional, however, is used to determine the current orientation of the app. More specifically, the existence of the View that contains the TabHost rather than a parent View for TabSpec content.

So until I find a more efficient way of doing things, this is going to be my toss into the tab content updating solution.

The Shopper Development Update – B

Unfortunately I didn’t spend much time on The Shopper today. At least not as much as I’d intended to. However with what little time I was able to afford it, some goals were achieved.

Let’s start with the matter of orientation. I’ve been a bad developer and have been working on portrait mode as an afterthought and putting more attention to landscape. Frankly I’m more attracted to the way the app looks in landscape even though the same functionality can and will be present in portrait mode via shelves. The concept is similar to the YouTube app and is promoted even on the Android developer website under the Design section.

Portrait mode hasn’t been touched on too much

Right now the shelf isn’t implemented. Actually, swipe actions aren’t even listened to yet so it’s extremely raw. This has become a bit of a priority since I’ll be playing catch up with it if I don’t do something soon.

Meanwhile, on the landscape front, I trimmed some fat from the tab identifiers. Now they’re simply condensed to one word. Looks sexier that way. The list content is now dynamically populated from the database. As intended, the population mechanic uses distinct clauses so that multiple entries are only included once in the list. Right now, there is no enforcement on case so technically speaking there can be more than one of the same store or item entries in the list. I’m still coming up with the most user-friendly method for mitigating this behavior since realistically I only want one guaranteed distinct entry in the list regardless of factors like character case.

A bug was fixed regarding the addition of items not being immediately updated in the item listing. Now, when the user adds an item, the item listing gets updated as does the dynamic filters listing. Another bug was fixed regarding the conditional used to determine the orientation of the app. For some reason or another, I was under the assumption that checking to see if a Fragment existed was enough but that didn’t seem to be the case. Instead, a check for a particular View, more specifically the TabHost that contains the dynamic filters, was used instead and works perfectly fine.

Trimmed fat from the tab names

Sometime soon, I’ll have to do a post on how I decided to dynamically update the content of the tabs contained in the TabHost. This is a rather interesting problem in Android that, from what I’ve seen, doesn’t have a very easy solution. What I’ve done seems to do the trick but I’m not sure of the future impact of performance it will have. I’ll just have to keep my eye on it.

The Shopper Development Update – A

This morning I took a few hours and drilled some more time into the next version of The Shopper. This is a little overdue and needs done but, as with most things, I’m taking it slowly to make sure I’m getting all the things I want in it 100% complete.

The screenshots shown here are from the tablet-specific interface in landscape orientation. The first one shows what the normal screen looks like. The ActionBar is populated with various actions the user can take. Right now, only the Add Item feature works (obviously signified by the plus icon on the far left). The item list is presented to the user on the right side of the screen while dynamic filters are specified on the left in a TabHost container.

The default appearance for The Shopper on tablets in landscape orientation

It’s not visible here but the selection highlights for the lists is the same green color as the tabs. This is also true for the selection of ActionBar icons and the folded menu as well.

To add the item, I kept the same mentality here as was present in the first version where a modal dialog appears that contains the form for preparing and submitting a new item to the core database.

Adding an item with the Add Item dialog

Compared to the dialog featured in the first version, this one is greatly simplified and better looking. Unfortunately it’s not complete yet as there’s a feature I’d like to test with it and, as you can tell, it’s not conforming 100% to the style I’ve set for this version.

It’s been an interesting adventure learning how to style as much of the Android UI as possible. Most of this information is not directly available and is instead found only via inference or from some fringe forum on the internet. I’ve discovered a few tools for stylizing your apps which significantly helped in the process and saved me a lot of time. These will be listed at the end. One of the things I’ve yet to figure out how to style is the border for dialogs that divides the title from the rest of the content.

Right now, the dynamic filter lists are still full of static content (i.e. they’re not polling from the database to obtain the pertinent data). This will change before the end of the week.

The design path I’ve taken with this has provided a fair set of interesting challenges. More specifically, nearly every UI container is its own Fragment; the item list, the dynamic filters, the dialogs, etc… Changes made in one Fragment logically reflect on data contained in another Fragment and those changes need to be visible to the user as soon as they’re made. Direct inter-Fragment communication isn’t possible in Android so you have to use a hosting Activity as the delegation point. Writing code that conforms to this is interesting since it makes you rethink how your objects communicate with each other. Down in the ditches, so to speak, it seems like you’re wading though shit but when you look at it from a large scope, it really is a pretty elegant solution if convoluted at first.

Android Asset Studio – Holo Colors

A Quick Thought on Android UI Themes

Right now I’m sitting in the dentist office lobby and decided to jot some thoughts down while killing time.

Earlier today I was showing off the latest version of The Shopper to a few friends of mine. If you follow me on Google+ you may have seen about a week ago ago that I posted a few screenshots of the app with the new UI optimized for tablets. The major difference is that it adheres more closely to the design guidelines provided by Google with modifications only to the colors used.

Surprisingly each of them agreed that it looks sharp and way better than the previous version. Even my girlfriend, who is my primary test user, said that she’s much happier with this layout design and prefers it.

This got me wondering about UI design for mobile as a whole. It’s always interesting to design your own UI theme but is it really necessary in most cases? I’m not talking about developing custom widgets but more toward themes and skinning.

I’ve used a few apps where skinning was possible and it’s always felt a little flaky. There are usually a handful of skins the user can choose from and some just look like total shit. I guess I’m wondering where it is a designer draws the line and says enough is enough.

I think it’s different for solo developers like myself who are the entire team in one: designer, developer, marketer, etc… Personally I’d rather cop out as easily as I can with UI such that I’m not spending a month working on custom art for widgets. So I’m more inclined to stick to design guidelines. We’re not necessarily designers by trade so the recognition of where to stop with theming might not be as obvious.

Does that mean we can’t make beautiful looking apps? I don’t think so. But I do think that it’s easier for people like me to go into overkill with the UI design. With The Shopper, I’ve been skirting around the UI carefully which is in stark contrast to how I did it last time. Maybe this is the better way to go?

Refactoring to Get Back to Root

Despite the implications of the title, this is more of a personal post than something exceptionally technical.

A few days ago I decided to pony-up to renew my Netflix subscription. The major benefit to doing this is independent documentaries; they can be a bit hard to come by even if you’re seriously looking. While exploring the available titles, one in particular jumped out at me: Indie Game The Movie. I was completely ready to dismiss this as yet another “here’s a developer and here’s what he does on a daily basis” films but gave it a shot anyway.

Not only was I completely wrong, but I was taken aback at how much I connected with the developers featured in it.

The thing that really scared me the most is that I came to find it at a rather interesting time. I’m actually in the process of developing my third Android application which happens to be a game. While still very early on in the project, I’ve found myself going through all sorts of emotions and engaging in combat with myself over seemingly trivial things for little result in the global scope of the project.

One of the developers featured, Jonathan Blow (now most known for Braid), said something to the effect that the major difference between independent games and high-end commercial quality games is that personal character flaws present in the developer can be translated into the game making it an extremely personal affair. I can’t remember the quote verbatim but this struck a major chord with me. I’ve actually been developing games for about five years now. In that time, I’ve written four, released two, and have since lost the source and binaries for all of them. While each one of them has been different in various ways, the one thing that has remained constant is that it’s been a difficult process and I’ve always left a little of myself in them either through personal tweaks in mechanics visible only though reading the source code or via the plot of the story.

As the years went by and I fell out and back into programming, something changed in me. All of a sudden I had no desire to write code for the pleasure of it. Instead I felt compelled by the monetary gains that would follow afterward and driven by such desire. I was controlled by the pressure to code for this framework and shy away from this language because you can’t develop fast enough with it. The code itself has no personality to it. Every line written was clearly marked as nothing more than an extension to the underlying framework API. Things like code completeness and efficiency were now more important than how I felt while writing the code and then using the resulting program. Usability has always been important to me regardless what I’d written but now it felt like I wasn’t concerned about how I used it or leaving my own impression on the program.

Now I was just droning from one project to the next.

And this really bad mentality sunk into my recent game project. It shows in the code, it shows in the demos, it shows in the art. In a sense, the entire project is corrupted by this. And I knew it. I felt it. Something was missing and something was very wrong.

After hearing what Jonathan Blow said in the documentary, I stepped away from the project for a while and really thought about what it was exactly that I was missing. What I discovered was extraordinarily personal but the root to all problems.

Life has a way of making you experience things that you don’t think you should have to experience. You can’t necessarily shield yourself from the things with negative connotations; they have a nasty way of creeping up on you and making sure you know that they’re there. I can think of so many things in my life that have negatively impacted me on so many levels and degrees that it’s easy to get consumed by it: childhood hardships, the decay of family and friends, cancer, death, addiction, misplaced trust, dishonor, abuse of loyalty, hollow bonds of family, unforgivable mistakes, etc… It all detracted from the small lot of things that I did find solace in. Mostly because having experienced what I did it was really easy, and still is frankly, for me to be absurdly cynical about the world.

I took some time to proverbially “refactor” myself. Touching base with what it was that I really loved in life and finding again what I’d lost because of all the cruft, I’ve emerged feeling somewhat invigorated.

It’s truly hard to be yourself in a world that demands you be something else suitable to the context. But being yourself and not shying away from that is extremely important regardless of what you choose to do with your life. Not bringing your personality to the table might as well make you a drone.

Having done all of this, I humorously sat back down at my computer and started looking the code over again.

I’d like to say that most of it was okay. After all, structure work is structure work. Beyond that, it needed a total refresh. That wasn’t me writing that code there. It was drone code.

Is it going to take longer to get this thing done? Yes. Am I going to be happier with it? Absolutely. Is it going to be flaky like me? Better count on it.

Still Building

I’m seeing some people pinging the site already. Be patient – I’m still working on getting the content arranged on here and actually visible. It’ll come together, hopefully, before the end of the week. In the meantime, don’t forget to check out the podcast that I co-host as well as the other projects that I’m working on!