The Shopper – Questions, Questions

This morning I was able to complete another critical portion of the feature set: item deletion. It now works for either single or batched deletion. In other words, you can delete either single or multiple items in one fell swoop. Of course, there’s no way to undo this but I’m not too concerned about that right now.

Something struck me though. The original version of The Shopper had a visible dynamic calculator. As the user added, deleted, and edited items, the calculator would display the cost with and without sales tax applied. It also showed the total number of items in the list. More accurately, it showed the total of items that should be in your buggy (it counted item quantities rather than strictly the number of items in the list). I thought this was a really useful feature but for some reason or another, when I was drawing the initial UI design drafts for the current version, it never made it in. It still isn’t in there.

In fact, the degree to which it’s missing is evident in code as well. There are no accommodations for calculating a running total for the items currently existing in the list. None.

This might be a little bit of a problem. Adapting the code that calculates these values from the old code base isn’t a problem. I just need to figure out where the hell to put the calculator at. Originally, it was below the list of items (as shown below). I’m thinking that maybe it should go there again? Or maybe above the list? I’m not sure.

The Shopper v1.0 showing the dynamic calculator below the list contents

So here’s another screenshot showing the current iteration in landscape mode. Any thoughts?

Coding in the Winter

Winter is always a bit of a nostalgic time for me. Despite the negative connotations surrounding it (snow, cold, its inept ability to make people drive really poorly), winter is my favorite season for many reasons.

I have a lot of fond memories of winter growing up. There are also some things that I do as a sort of “winter-ritual”. For example, starting the first day that snow falls, I start playing the first Parasite Eve game until completion always starting from a new game with a new file (don’t get me started on my Parasite Eve obsession). Coincidentally, that day is today so I’ll be setting aside about five hours tonight for that very task.

However there’s also something really close to me about winter; more specifically the month of November. This month, eight years ago, I wrote my first computer program ever. It was quite snowy at the time so there’s obviously that association as well but I won’t ever forget how stupid excited I was that I actually had something compile and run without bugs (although not optimized in any way).

To provide a little background, I am your stereotypical kid who grew up indoctrinated by video games. My mom and dad bought me a NES when I was two and ever since then I’ve been involved in gaming in some way. At some point during that time, up to 2004, I had the notion that I wanted to create a video game. I’m pretty sure that every gamer at some point has this idea. The only catch here was that I never actually owned a computer up until about 2001 so I knew absolutely nothing about how games worked, how software was written, or even what software was. All I knew was that I had all of these ideas in my mind that I wanted to see translated into something interactive like what I’d been seeing and using my entire life.

When the opportunity presented itself, during my twilight years in high school, I took up a computer science and networking program at the vocational school near my home school. This was when I learned about writing software and everything that’s entailed with it. What happened here, more importantly, is that I learned independence. I only spent two years at that course as that was the length of it and I’m a college dropout. But everything that I do know has been self-taught. I’m not going to get into an argument about me being comparatively superior to someone with that level of education but what I did do was throw myself into the fray and developed an ability to learn new things extremely quickly. Without that learned independence, I wouldn’t be where I’m at today.

My first programming language was Visual Basic (VB6). Not the greatest language on the planet but despite its shortcomings, putting out Windows-based programs quickly was very possible and satisfying. The first program I wrote with it was a mock inventory management program. This wasn’t a database-backed program like it should have been. Instead it was based around fixed lists where you could enter, delete, edit, and clear items. Nothing fancy but at the time, it was pretty awesome to me.

This was exciting to me. Ever since I learned about software engineering, I’ve always looked at the world a bit differently. I see the things around me and wonder how something like it, say for example a portable heating unit, could be expressed via software. How could I observe what it does, how it behaves, how it responds to interactions from different things, how it looks, how it feels and describe all of those things in the context of code. This seemingly biological analysis of animate and inanimate objects is what compels me to write code and drives me forward.

Winter brings all of this back to me. All of the drive, all of the over analysis, all of the feeling of creating the world I want in terms of software. I’ve never really written software to be used by masses of people; that was never the goal. I’ve always written it so I could use it. Every piece of software I’ve written has always been part of this grander expression of the world around me. But if other people like what I do then that’s very cool.

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:

referencePool.<EditText>getReference(...).someMethodFromEditText()

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:

tabWidget.getTab("tabTag").getContent().updateWithHook(interfaceDefinitionInstance)

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 http://android-holo-colors.com

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?