I guess I have a set of stupid questions, stupid as in I should have asked them sooner. These questions concern Android Code Best practices.
If you look at either Android Source code for Android default applications or for example the ReplicaIsland Game you see certain patterns. One, hard to encapsulate and decouple as in the bean/service pattern concepts not used. Two, the MVC pattern non encapsulated.
Due to the size of both types of applications could we not benefit form use of a non-reflection, non-aop Dependency Injection and a use of a small MVC framework? The benefits would seem to be in the DI case to be the program logic would be back in classes with the Android boilerplate code being the items injected and reducing the coding by 25%. In the case of using a small MVC framework one would get a better programming contract between the applications presentation layer, logic layer, and the model layer and may even be easier to implement a real actual ORM .
I have started playing with O’Reilly’s Android CookBook Wiki and The MVC Principle contribution request triggered this thinking as how would you teach MVC in Android in 3 pages since the MVC pattern is somewhat modified in Android. Modified by meaning in that the View GUI navigation is not separate from the Controllers, etc.
Some of the MVC pattern is of course there in Android as we could extend the Application class as a Controller as a sourceforge Android-MVC does that, in alpha state at the moment. Android-XMBCRemote also made an attempt at MVC and in their approach they had more than one controller and it seemed to be that the benefits they obtained was a better module or unit encapsulation of the application model units which would translate to a better and easier maintainable code base.
Could it be performance? Would be a reasonable question, right? On the Dependency injection side RoboGuice and Yasdic do not use reflection so we do not or should not see a performance hit. On the MVC framework side such as using Android-MVC there would be a slight increase in coding to use the MVC framework but if you are using Dependency injection with that where everything is loaded in the lazy fashion(only loaded when needed, etc) that should counter balance the added code used to use the Android-MVC in an application.
What brought up this line of thinking, originally is I was debating actually teaching java using the Android Platform and of course the modified MVC pattern came up, etc. But, if you had a decent combination of DI and MVC framework avoiding java reflection you could use the strength of those patterns not only in having easier maintained code but also to teach java using android. The person I was debating this with brought up the fact that Android is visual, but that is an advantage as that is one of the channels of learning is in fact visual.
Of course part of Android is XML. But no one teaches SGML any more and yet we use it every day in word processors(most word processors use SGML as one of their internal core formats). The way Google implemented using XML in Android is just one step closer to using XML without having to know all the internals and thus that point about it might detract from teaching java using android should be a non-operation debating point.
The obvious first step would be to convert some small and big android applications to use use dependency injection(roboguice) and and android centric MVC and see what the challenges are and the benefits and write about both.
Side Note: Yes, Android_MVC is missing other MVC framework features such as using the facade apttern, etc. That is why I would imagine the project lead is thinking of forking his own project and why others might also want to fork it. Nothing against the code effort as its a very first good start.