My 1st Android App - Sudokroll

I know how to solve Sudoku puzzles but have never solved one by myself. I'm just too lazy to do that.

I developed a Sudoku solver a while ago. It has a command line interface, so just input your puzzle as follows and it'll get solved.
_____8_7_
91___45__
_7_5__8__
_3__86_5_
7_______3
_4_12__8_
__2__7_6_
__34___21
_9_8_____
Pretty cool, huh?

As I always said, Android development is a bonus to Java developers. I ported my Sudoku solver and made it an Android application. It's called Sudokroll. As the name suggests, you touch a cell and scroll on the screen to assign a number for the cell.

For better look and feel, it's for Android 2.3 Gingerbread and above. Have fun.

When not to use Dependency Injection?

Dependency Inject and Inversion of Control are too popular for people to think when not to use them.

DI / IoC encourages high-level modules define abstract services for low-level modules to implement. The changes of the implementation in low-level modules won't affect the defined interfaces, so high-level modules can remain stable. Unit tests to high-level modules can be conducted even when mocked low-level modules are provided.

From this understanding, it’s always a good idea to use DI / IoC between layers in a multi-tier software architecture. On the contrary, whether or not to use DI / IoC within the same tier should be carefully examined. In most cases, factory method or even new statement will do. Here are a couple of reasons.

1. The components within same tier are usually tightly coupled. Changing one component and related components need to change accordingly is sometimes reasonable, if compared to inter-tier cases.

2. Within same tier, large amount of business objects may be created. This is very different from injecting a low-level service provider to high-level module. The performance of reflection in creating large amount of objects in IoC container may hurt the system.