Team work and Inner classes

It's like almost 3 months that I haven't posted anything new here, but my life still goes on. There was nothing really excited for the past months, except that I got an approval from my manager to go back to Thailand at around Christmas time. Our project at work still goes pretty well, but I learn how painful that is to work in a big project that cannot be done by one team but has to wait for "business people" to make a decision. I guess this is the problem facing everywhere there is a big software project, but to see it myself makes it even clearer that we need a faster software development process. I spent most of my time not coding, but wandering around asking people if the components they were working on are done. Debugging is also very painful, especially on the Android platform. Fortunately, I switched the IDE that I use from Eclipse to IntelliJ IDEA, and it makes my life a lot easier when I try to refactor my code.

I don't know if other people have had this discussion, but we just had one discussion about using inner classes in Java. In my opinion, you should use inner classes IF AND ONLY IF it works like a C struct. However, when you try to write code and get it done, it's unavoidable. Furthermore, the Android platform "encourages" you to use inner classes just because it was designed to be like that. I think separating classes makes more sense in terms of object-oriented design and modularity; however, we cannot deny that sometimes inner classes make life much much easier, such as when you have to access the outer class' instance variables, or having to have anonymous classes. It's impossible to come to the conclusion on which approach is better, so I'll leave it up to you whether or not you want to use Java inner classes. For me, I prefer having a separate class (unless it's absolutely necessary).

Actually, I have another thing in my mind that I want to share with you but I already forgot, so I guess I'll end here today, and I'll try to update this blog more often. :)