Due to watching world cup evey night through out the week, I spent most of my time these two weekends sleeping. Even not able to do some serious coding, I tried to clean up my long pending reading list, and I just took a look of SwipeRefreshLayout.

Saw this class a while ago, just from the name of this class, I expected it to be a ViewGroup that handles the pull gesture of the Android style pull to refresh. I was not very interested in this class because there is no plan to touch the refresh UI in work, but it is always good to know it is in the support library.

What really caught my attention is the canChildScrollUp() method in SwipeRefreshLayout. It used ViewCompat.canScrollVertically and special handled pre-ICS.

Source line 348

public boolean canChildScrollUp() {
    if (android.os.Build.VERSION.SDK_INT < 14) {
        if (mTarget instanceof AbsListView) {
            final AbsListView absListView = (AbsListView) mTarget;
            return absListView.getChildCount() > 0
                    && (absListView.getFirstVisiblePosition() > 0 || absListView.getChildAt(0)
                            .getTop() < absListView.getPaddingTop());
        } else {
            return mTarget.getScrollY() > 0;
    } else {
        return ViewCompat.canScrollVertically(mTarget, -1);

(Well I don’t understand why the ViewCompat method cannot(?) handle pre-ICS… then what’s the point of Compat?)

I wasn’t aware there is a canScrollVertically() method in View since ICS, and the ViewCompat also provides some interesting method that could simplify some custom ViewGroup implementation. Should put more time to review what’s new in those commonly used classes as I believe there is no need to support pre-ICS soon.


Why I Failed to Have Side Projects

At the beginning of last few years, I wrote down a list of things I want to do through out the year. I finished some, gave up some, and some stays on the list. One of the longest staying item is – “start a side project”.

What takes me so long

It is easy to come up with something, but it is even easier to ban the idea. At first I thought maybe it is easier to start when I get more experience, learned more tools, but the truth is, the more you see, the harder you start.

For example, I come up with an idea of building an Android app that provide list of XXX and allow user to do YYY on it. Sometime I would not even start when I find that it is not easy to get the XXX list, or after I wrote some scripts to crawl the list, I get distracted in other idea and put down the started project, sometime you just get tired in work and decided to take a break in weekend.

Obviously I am not determined enough. But another problem I found for myself is, I start losing that kind of fire I had 5 years ago.


Two months ago, I helped in a workshop for my middle school about using AppInventer to build Android apps, targeting F1-F3 students (12-15yo). When I prepared the material, the first thing I found is that, not surprisingly, the tool has VERY limited features. I am not even sure what I can build using that, how do I give advise to those students?

During the workshop, before telling them what the tool can/cannot do, I let them students brainstorm the project topics, and told them not to worry if it is possible, we can “fake” it. Turned out they came up with some interesting idea, of course most are impossible to actually build it with their skill level (or even mine) and with that tool. But seeing their discussion reminded me a very important thing, the excitement.

Don’t think too much

People have different reasons to start side projects, for me, it is simple, just to keep myself motivated and do things that I may not have chance to do in work.

Related reading

F8 Mobile Talks

Got some days off last few weeks (public holiday and AL), spent quite lots of time on watching tech talks. (Another video summary post…)

Hacker Way: Designing the New Messenger

The first one I watched was about designing Facebook messenger, a little bit slow, but talked about some design iterations and considerations through out the process which is quite interesting.

Hacker Way: Releasing and Optimizing Mobile Apps for the World

This one is really interesting. It talked about their Android app shipping schedule and workflow. The talk also included their buck system, heard this from other talks but this is the first time I heard (maybe I missed before) about the share build result over network, which is quite… crazy amazing.

Hacker Way: Mobile Engineering at Facebook’s Scale

Similar contents but also worth watching.

Dagger: A Fast Dependency Injector for Android and Java

I have been researching the possibility of using dependency injection in current project. I think I will use it eventually, especially Facebook and Square are using it for a while. The biggest problem right now is it may affected every part of the app and I am not comfortable doing that without unit tests…

I also re-watched these two videos from IO 2013 as I am working on related view performance recently

Write Dirty Code


As an experienced software engineer, you are expected to write code reusable, modularized, clean, blah blah. Of course you do that in your product, but sometime you need dirty code to do dirty work, and I enjoy doing that. :)

Code generator

One of my favorite dirty code is code generator. When writing Java, sometime you need to write lots of getter setter, at first you just copy and paste, but after a few months, you will find the class goes big and messy, and it is easy to make mistakes, you may forget to change a variable, or put in wrong default value…

So, how about a little code generator? Make a config file containing the fields and data type, and just generate the java class for you. You don’t even need to write the generator in Java, in my case, I have a python script that reads yaml config file and generates Java code.

That script is simple and ad hoc, you are not going to maintain that so when you want to “reuse” it, just copy the script, modify it, do whatever you want.

Custom build scripts

I have been using ant to build Android for a long time, just migrated to Gradle recently. One of the problem with the old system is lack of multiple build support. What I did in last 3 years is, have a custom ant task that modify the package name in AndroidManifest.xml and update all import of R in code.

And combine with code generator scripts, I can create builds with different config files which is one very important during development.

It is generally not a good idea to modify every .java files before compile, but with the limitation of the build system and you don’t have the resources to dig deep, I would just use the dirty way (proudly).

Get your hands dirty

After working for some years, we switched our mind set from a programmer to an engineer, we may forget how to get dirty, forget how we used to “hack” things, forget how we rushed a course project in one night. By being a better engineer, we write better code, but we should not lose the ability of being dirty.

Use dirty code to do dirty work is just an example of use the right tool for the task.

Yes or No

From being interviewed to interview others

I have been working as a developer in different startups, I am not a decision maker in any of it, but as I becoming a “senior engineer”, I start getting involved in the hiring process. And this gives me a good view to see even we all called ourselves “startups”, different teams can have very different hiring considerations.


It is obvious that hiring in startups is very different from Google. You don’t have a large pool of candidates for you to choose, you don’t have a HR/recruitment team to do that for you, you can’t simply fly someone from another country and give him a few rounds interview even you know it is a fit…

As I mentioned in previous post, Hong Kong is not a good place for tech people, it is normal that the best people leave Hong Kong for better opportunities. Of course there are still many good developers or potential candidates but it is hard for startups to reach those talents. For some companies/industries, they believed in some kind of “hiring season” indicating that the “market” is more active and can have better chance to find match for your openings. I agree on the probability, but in my opinion, it is easier for you to find a match, it is also easier for the candidates and they may turned down your offer after all.


No matter what are you looking for, what questions you asked, at the end of the day, as a interviewer, what your boss/manager want from you are actually just scores, comparison to other candidates and most importantly, YES or NO.

At first you may feel pressure of saying no because it means the candidate will not get the job, especially you don’t have much comparisons at that time. But in my experience, the more you see, the easier you say no, the hard part is to say yes.

What the YES means

For me, a yes means

  1. If the new hires will be working with/under you, you feel comfortable to assign tasks to them and believe they are/will be able to handle it.
  2. You want to work with them.

(1) is the bottom line, no matter how experienced the candidate is, if you think they could have problem picking up the existing code base, it is usually a easy no. And when you are interviewing entry level developers, you may have a lower experience/technical bar but you still need to have a feeling that the candidate is a fast learner to give a yes.

(2) could be tricky, you may think he is qualified for the job on every aspect but you are still not sure about if you want to work with him, could be just impression, the way he talks, his background etc. For big companies, you may just say no if you are not sure, but for small teams, we try not to lose any potentially good candidates. So far I don’t have a good solution for this, most likely I will just tell my manager that I think he is qualified but I am not sure on personality, then let the next interviewer decide that.


Interview is not just about a company hiring a candidate, it is also about a candidate deciding to join a company. If you are a big company, you could think that it is the candidates lost to not joining you, but as a startup, things are not working that way, at least in Hong Kong. If you want to attract good people to join you, you need to show that you have what they looking for, or something better than what they are looking for. It’s not always about money.