The Chronicle of an Android Developer Apprentice (2 of 7)

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.

Android Blueprint

The Blueprint

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 …

This entry was posted in KoinKuLator, Wisespend. Bookmark the permalink.

One Response to The Chronicle of an Android Developer Apprentice (2 of 7)

  1. abangkis says:

    My comment on the matter :

    You need to go back and grasp the basic concept of android apps. First we need to go back and revisit Android Fundamentals. There’s 4 building block when building android apps. Activity, Services, Broadcast Receivers and Content Provider. I’m just going to highlight the first part. This component is the most important thing to understand because it gives the unique behavior that android apps has.

    Android apps mainly consisting of several activity that ‘basically’ independent from each other. Why do we call this group of activity an apps ? Because we give rules how they will work coherently. For example we set which activity will start as our main activity , and then when a button on that activity is clicked, it will start another activity, and so on)

    Consider an apps that has 4 activity, lets call it Cinemator. You can go straight forward from activity 1-4. But lets try a scenario, where you’re on activity number 2, a sms come, and you reply it immediately. You start a new apps, a whole set of new activity. And after you’re finish reply-ing and press the back button you go back to the Cinemator 2’nd activity. This show’s how android application activities aren’t tightly coupled to its apps. But wait a minute, isn’t that regular multitasking ? context switching ? regular round robin of process in a computer.

    To give you better context, you need to understand how this behavior actually implemented. Whenever we create a new activity, that activity will be push into a stack, and the top most activity on the stack will have its user interface shown to the user.

    So your using cinemator, First activity goes into the stack (c1), and then the second activity (c1, c2). Going straight through the apps will give you (c1,c2,c3,c4). Now we use our last example. When we receive the sms and start an activity to reply it, the first sms activity (s1) will go to the top of the stack. So the content of the stack would be (c1, c2, s1) starting another activity in the sms apps, would give (c1, c2, s1, s2). This shows how an activity its not tightly coupled with its application, in android system. the next activity of c2, doesn’t necessarily have to be c3.

    The back button will tell android system to pop the top most activity from the stack. That is why when you pressed back in s1, you will get c2, and remember that the top most activity in the stack will have its UI shown to the user.

    So what are my point rambling this long unnecessary things. My point is, although we come from desktop or j2ee developer, bringing all of our idea from those days would work almost all of the time, but the sooner you adapt to the nature of android apps. The easier you would design your apps, and the simpler it is to tackle and give new feature in your android apps.

    ps : I’m not saying its wrong or anything. I’m encouraging you to dwell further to android ecosystem🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s