This part two isn’t exactly what I had drafted (that initial draft would then be pushed as part 3). This was somewhat on the spot, a last-minute addition.
As I’ve mentioned before, Wisespend, as an app was done. Well, save for annoyances for an incomplete and unintuitive UI/UX but that was more in the line for the designer guys at @mreunionlabs should the app is ever released. But it was, sort-of done and usable. Of course, you can’t take my words for granted. After all, no sane parents would talked ill of their kids, right? So, as usual, I had submitted Wisespend (codes and all) to get internal reviews from @mreunionlabs. I don’t have to wait long for inputs as the app was agonizingly simple. The comment that stuck out the most was on how different my coding style with the rest of the guys. Therefore, in accordance to that comment, I had decided to dedicated the part two of this series to a glance on how the blueprints of my Android app worked.
A bit of disclaimer, as I wrote this post and looked at my blueprint, I realize that well, some of you might had a fit and laugh over it. But hey, what’s the point of sharing if I was afraid of criticism. Besides, who knows, maybe by looking at it, you could help tell me what’s wrong with my head that had produced this rather bloated blueprint and offered me some leaner and more effective alternative.
This image below is a rough sketch of the blueprint. KoinKuLator, as my first app had somewhat vague resemblance to it and it is naturally more prominent in Wisespend.
The center of this blueprint is an instance of Application class. The official documentation of this Application class is:
“Base class for those who need to maintain global application state.”
Granted, I hadn’t had time nor bothered to take a closer look and just assuming that, okay, so whenever my app was started, this Application instance will *always* be available so therefore, I could throw everything in it without ever worried that it will throw a NullPointerException. And I did. Throw everything, I mean. As evident in the above image, I used the Application to always have an instance to what I’d called as the All Knowing Class. This class is Observable and holds the connection to the SQLite database and access to the Pool of Whatever. In short, I did almost everything in this All Knowing Class. Created an entry to a database? Go through this class before delegating to the appropriate adapter. Animating a text? Go through this class to grab a hold of an Animation classes from the Pool of Whatever and throw it back to the demander, and so on, and so forth.
From the image above, at the far right is the box of SQLite database related classes. I’m not sure about any of you, but working with Database has always fascinated me, and I’m still quite unsure on how effective/efficient my approach to the database really is. At the very least, I had based my design on how I felt the easiest for me to had a glance to it and making changes and it was a major shift from KoinKuLator public version.
In my blueprint, every table on the SQLite database had a single adapter class, and a single Type class. The adapter was responsible to make a connection, manipulate data, and closed connection. This adapter, in my blueprint, was always called from the All Knowing Class. The Type classes are rough equivalent of an ORM-type class. I’m not really sure the full benefit of it, only that I could call the object, browse through its contents, from Activity, or outside the All Knowing Class without ever maintaining a Cursor or an open connection to the SQLite database. Simply return a query from the database as one of these Type classes or in case of multi-results, pool the Type classes into an Iterable collection class. I had taken this approach because I had a terrible first date with Cursor in KoinKuLator that before long, I had taken the role of plumber, tried to plugged leaks as the results of unproperly maintained Cursor. The public version of KoinKuLator still suffered from this leaked Cursors, although the private version had started to adopt the approach and in the result, more stable. Or so I thought, as the regular user of KoinKuLator. Again, correct approach? Not sure. Effective/efficient? I’ll get back on you on that. All that matters is, by this approach, my life as a *sole* developer was easier.
And finally, the last components of this blueprint is on the far left of the image. Activities. Kinda obvious. In the blueprint, when Activity needs to manipulate data, it first refers to the All Knowing Class and let it and subsequent database adapters do the work. The Activity may implements Observer and then registered itself as one of the Observer for the All Knowing Class. Therefore, whenever the All Knowing Class finished it work, it could tell the Activity that the work is done and therefore could proceed with the obtained value, or refreshed the results, or whatever.
So, that’s how I formulated a blueprint for any Android app. I had two skeleton projects besides KoinKuLator and Wisespending (they were codenamed, “HobbyDecidor” and “BudgetDining” *nudge,nudge,wink,wink*), and each had also taken this approach which frankly, got me up to speed far more quickly than any of the approach I had used before.
All in good time, all in good time.
To be continued …