In "production mode" there will be no client-server architecture, all of the configuration will be done locally (also through dependency injection). In development/debug/real-time-editing mode the configuration will be either
1) configured locally, then uploaded to the server, and the server will be polled for changes (publish&poll)
2) configured remotely (will "pull" the configuration/properties from the remote server) (pull&poll)
So off the bat we have a few issues to contend with. First we don't want all the client server code to be integrated and deployed with the production application. I will use the strategy described in an earlier post of development/release aware builds for accomplishing this (Basically I have multiple application deployment "topologies", each consisting of potentially (many) eclipse projects ..
the "debug" deployment topology version of the release which contains
1) the base project
2) any "library" projects needed to run the application
2) a debug android library project containing overrides and configuration as well as any library code and dependencies for the client-server architecture (this is an android "library project")
the "production/release" version of the project which contains
1) the base project
2) any "library" projects needed to run the application
The main "inflection point" or way I provide this indirection is (at Runtime) during initialization, I check for the existence of a specific class (which is only available in the Debug project lets call it DebugMode.class)... if this class exists, it is created, and in it's constructor it will perform all of the additional configuration and initialization as well as any property overrides to make the application run in "Client-Server mode".
So building and deploying the application in release mode requires nothing special, building and deploying the application in debug mode requires you to change the classpath to add the debug project. (That way none of the debug specific code is deployed to the release app unnecessarily)... this can be done either in eclipse directly or in Maven/Ant. (with different release targets)
Another issue I am working on is selecting a DI framework which works for Android, at the moment I am using robo-guice... which I'm starting to like. Having those @Inject tags makes things relatively easy to read.
package example.roboguice;
import roboguice.activity.RoboActivity;
import android.os.Bundle;
import android.util.Log;
import com.google.inject.Inject;
public class MyRoboGuiceActivity extends RoboActivity {
@Inject protected MyInterface someInterface;
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
public void onStart() {
super.onStart();
Log.e("Guice", someInterface.getName());
}
}
...Also I like that "Modules" (which "wire" everything together) are relatively straightforwardpackage example.roboguice; import android.util.Log; import roboguice.config.AbstractAndroidModule; public class MyRoboGuiceModule extends AbstractAndroidModule { protected void configure() { Log.e("MyModule", "Loading Module ... SomeInterface"); bind(MyInterface.class).to(MyImpl.class); } }
We'll see how things turn out
No comments:
Post a Comment