Android UI Test: Mocking the ViewModel with or without Dagger? Part 2

In the first part of this post, I explored the approach of setting up a UI test with a mock ViewModel without using Dagger 2 for dependency injection. I used the GithubBrowserSample app from the Architecture Components sample code to demonstrate disabling Dagger for UI testing, even though the app itself uses Dagger.

Now, using Dagger

There are various ways of using Dagger to provide fake or mock version of dependencies for testing. Generally they involve writing test versions of the component and module classes.

Then when the Espresso test is run, somehow the Dagger object graph that is built (incorporating the mock dependencies provided by the test module) is used instead of the one used just for the app. Some of the ways to do this includes:

  • Include a hook into the application class to replace the Dagger components with the test versions.

  • Once again create a test version of the application class in the androidTest directory. Here the test application would be a subclass of the app application class where the code to build the Dagger graph is overriden with the test version.

Of course, this would mean writing a custom test runner to use instead of AndroidJUnitRunner in the gradle build file.

public class YourApp extends Application implements hasActivityInjector {

  DispatchingAndroidInjector<Activity> dispatchingAndroidInjector;
  public DispatchingAndroidInjector<Activity> activityInjector() {
    return dispatchingAndroidInjector;

// The test app in the androidTest directory
public class TestApp extends YourApp {

  public AndroidInjector<Activity> activityInjector() {
    return new AndroidInjector<Activity>() {
      public void inject(Activity instance) {
        // inject the fake / mock dependencies into the activity
        // e.g.
        ((YourActivity)instance).viewModelFactory = ...

Other options I came across in my research include:

  • There is the DaggerMock library that uses a JUnit Rule to override Dagger objects. This is a nice idea, but currently DaggerMock only has limited support for Dagger Android. In particular it does not handle abstract modules and methods which some of the Dagger Android annotations depend on.
  • Include a hook in the activity to set dependencies.

Disadvantages, again

As I mentioned in the previous post, any of these approaches that uses a custom test application class for instrumentation testing would apply the same Dagger object graph to all the tests. This is not suitable for my situation where I only want to mock the ViewModel for the UI tests, but use the real one for other tests.

Other ways require making code changes to the app just to accommodate testing. This is a bit of a hack and not good design.

One Possible Solution

The solution I decided to use was based on this gist. The test module was used to create a AndroidInjector that would inject a custom ViewModel factory into the test activity. In turn the custom ViewModel factory would provide the mock ViewModel.

return new AndroidInjector<MyActivity>() {
  public void inject(MyActivity instance) {
    // create the viewmodel mocks
    MyViewModel viewModel = Mockito.mock(MyViewModel.class);

    // create the livedata used to return results
    MutableLiveData<Data> returnedData = new MutableLiveData<>();

    // set test data
    Data expectedData = ...

    // set the custom viewmodel factory that just returns the mocks
    instance.viewModelFactory = ViewModelUtil.createFor(viewModel);

This approach did have the downside of requiring a lot of boilerplate code. But it also allowed me to only mock the ViewModel for the UI tests, without affecting the other tests.


Please note that the opinions expressed in this post are not meant to apply to all instrumentation testing with Dagger.

They are only for the specific use case of trying to mock the ViewModel for my UI tests, while not affecting other instrumentation tests.


Android UI Test: Mocking the ViewModel with or without Dagger?

An Android app I’m currently working on has the following architecture:

When it came to testing the views , I wanted to write some UI tests using Espresso. These would just test just the activities and fragments with a mock backend.

With the Architecture Components I thought this would be fairly simple since all the interactions between the view and the backend services should be done through the ViewModel. Hence all I would need to do is to provide a mock ViewModel (in my case using Mockito).

Additionally I wanted to find a solution that:

  • was simple and straightforward, without the need for workarounds or hacks if possible
  • did not require any changes or additional code in the app just to accommodate testing

Looking at the Google sample code – no Dagger for UI Tests!

Since Google provides sample code for the Architecture Components, that’s the first place I looked. In particular the GithubBrowserSample seemed to be what I was after, this is from the README:

UI Tests

The projects uses Espresso for UI testing. Since each fragment is limited to a ViewModel, each test mocks related ViewModel to run the tests.

However, when I looked at the sample code for their UI tests, I was in for a surprise. Although the sample app itself uses Dagger DI, the UI tests do not.

This differs from most examples of testing Dagger applications, where it is advocated to write additional Components and Modules to inject fake dependencies for testing.

How it is done? The Setup.

Since I couldn’t find any documentation for these UI tests , here is a quick summary of how the GithubBrowserSample apps mocks the ViewModel without using Dagger. This basically involves using test version of the application and activity classes which do not invoke the Dagger injection code.

ViewModel Factory

Although it is possible to inject a ViewModel into an activity or fragment with Dagger, I will be using a custom ViewModel factory and injecting that instead. This is done for the following reasons:

  • Injecting a ViewModel class is only possible for ViewModels that have a default (empty) constructor. If the ViewModel constructor has parameters, then you need to inject a factory class that implements ViewModelProvider.Factory.
  • It seems to be a common pattern when using Dagger with the ViewModel to create a Module to encapsulate the ViewModel injection code. This Module would bind the ViewModel classes used in the app into a map. It would also provide the ViewModel factory class, which in turn uses the map to create the ViewModel classes. This is the pattern used in the GithubBrowserSample.

Here is a brief description of the UI tests for the fragments in the sample code:

  • Create a test application class.

This is just a dummy application class that does not invoke the Dagger code that builds the object graph.

  • Create a test activity class.

This is just a dummy activity class to contain the fragment to be tested. It allows the fragment to be inserted into it.

This test runner will used the test application class instead of the application class for the app.

 public Application newApplication(ClassLoader cl, String className, Context context)
 throws InstantiationException, IllegalAccessException, ClassNotFoundException {
   return super.newApplication(cl, TestApp.class.getName(), context);
android {
  testInstrumentationRunner ""

How it is done? The UI Test.

The GithubBrowserSample has several UI tests for different fragments, but they follow the same basic pattern. Let’s use this one as an example:

Remember that when the UI tests are run, there is no Dagger dependency injection.

  • Use the test activity class to hold the fragment to be tested, instead of the activity used in the app. This is done in the ActivityTestRule used in setting up Espresso tests.
public ActivityTestRule&lt;SingleFragmentActivity&gt; activityRule =
new ActivityTestRule&lt;&gt;(SingleFragmentActivity.class, true, true);
  • Before the test is run, setup the mock ViewModel.
public void init() {
  viewModel = mock(UserViewModel.class);
  • Set the ViewModel factory field in the fragment (which would have been injected in the app) to a fake factory class that just passes the mocked ViewModel. Of course the field needs to be accessible from the test class for this to happen (i.e. public or default package access).
 public void init() {
  fragment.viewModelFactory = ViewModelUtil.createFor(viewModel);
  • Put the fragment into the test activity.
 public void init() {
  • Because this fragment uses LiveData to get data from the ViewModel, the test data is inserted into the LiveData returned from the mock ViewModel.
public void loadingWithUser() {
  User user = TestUtil.createUser("foo");

A simple approach

That’s it.

With this approach there is no need to worry about the Dagger configuration. Just mock the ViewModel to return the data you want for the Espresso test.


  1. Using a custom test runner and test application means that all of instrumentation tests in the androidTest directory will have Dagger disabled.

But what if you have other instrumentation tests where you do want to use the Dagger injected classes, in additition to the UI tests. You don’t have the flexibility of deciding whether to enable / disable the Dagger DI on a test by test basis.

2. If you are using the Dagger Android library, then this approach will work with fragments, but not with activities. This is because an AndroidInjector is used in the onCreate() method of the activity to inject the dependencies.

public void onCreate (Bundle savedInstanceState) {


In the next post, I will explore some of the options if we want to mock the ViewModel in the UI tests with Dagger.

Groovy and Dagger 2 Android Example

I decided to use the Groovy language for an Android app I was working on. Luckily it was fairly straightforward, but I noticed that the number of blogs and examples available to demonstrate using Groovy for Android development are far fewer than Java ones. Not only that, but many of them were out of date.

This is particularly true if you want to use libraries that are not straightforward coding, such as Dagger 2.

I was intending to write a simple proof-of-concept app to start with, to verify that I could use Dagger 2 and Groovy together. Then I found this example app on Github.

However this simple Dagger 2 example did now show how to use the @Inject annotation (which is my preferred way to do Dependency Injection into activities), so I created a fork that did.

Note that you will need to use an up-to-date version of Groovy (2.4.x) to get Groovy and Dagger 2 working on Android.

Code Changes

I only had to make a few code changes to use @Inject, you can check the commits in the project to see what they were.

Firstly in the component interface (in the example, it is called demo.simplegroovyapp.component.VehicleComponent), I added a statement that would inject the dependency objects into the activity.

void inject(MainActivity mainActivity)

Then in the activity class (demo.simplegroovyapp.MainActivity) add the @Inject annotation to the field that was to be injected. The other important change I made was to add the public access modifier, I’ll explain later why this is necessary.

In other words, from this:

Vehicle vehicle

to this:

public Vehicle vehicle

In the onCreate() method, this line was added to inject the dependencies into the activity.


I also commented out the statement that was previously used to manually retrieve the Vehicle object, as it was no longer necessary.

//vehicle = vehicleComponent.provideVehicle()

That’s it!

Property or Field?

In Groovy it is quite common to see data in a class being defined without an access modifier (public, protected, private).

Vehicle vehicle

Likewise in many Dagger 2 Java examples I’ve seen, the @Inject annotation is used on fields without the access modifier.


MyPresenter mypresenter;

However when this is done in Groovy, you are specifying a property, not a field.

Hence Dagger can’t inject the Vehicle object into the activity, even with the @Inject annotation. Once the public access modifier is added, then Dagger works as expected.


Another Defection to Android Studio

Like many other developers out there, I have been using Eclipse as my main IDE for many years now. However for Android development I have decided to take the plunge and migrate to Android Studio (especially since it has finally been released).

Here is a blog post I found that closely echoes what I have long thought regarding the issues with Eclipse:

Build, build, build

For me, another reason was that the Ant build files I was using to handle building different versions (free vs paid, dev vs release, etc) were getting too complicated to manage easily. So I can now change over to Gradle at the same time, since that’s what Android Studio uses by default.

Gradle has the concept of build variants to handle building different versions of an Android app.

The Recurring Eclipse Re-install

Here are some other problems that I personally have had with using Eclipse.

  • Plugins, well not the plugins themselves, but having too many plugins. I’ve found that having lots of plugins in one Eclipse installation can cause Eclipse to misbehave , especially after several updates. There are several ways I use to get around this:
    • Keep separate Eclipse installations for different types of development, e.g one for Java, one for Android, one for Cloud, etc. Therefore each installation will only have a few plugins relevant to the type of development. However this is not always convenient if a project does require multiple types of development.
    • Every so often, when Eclipse starts to play up, do a fresh re-install of Eclipse (along with the latest version of the plugins required).
  • Intermittent miscellaneous bugs, e.g. cut and paste stops working, builds not alway done automatically, etc. A lot of these issues are more of a nuisance rather than being a serious problem, but all the same it tends to kill your productivity (and isn’t that why we use IDE’s in the first place?).

No Pain, No …

Make no mistake, despite what the Android Studio documentation might try to tell you, migrating a non-trivial project will take some time and probably involve some pain. But worth the effort I think.

User changes for Address Location Finder

I’m currently working on upgrading my app Address Location Finder. While most of the changes are internal improvements or bug fixes, there are 2 major changes for users.

1. The map will be dropped from the app.

The simple built-in map screen will be removed from the app for the next version. In the future it will come back as an optional add-on.


I was getting quite a few error reports from users trying to run the app on devices that did not have the mapping requirements.

One of the requirements stated in the Google Play app store for the app was:

– device that supports the standard Google Mapping API (not the same as having the Google Maps app installed)

This means the manufacturers need to have licensed the Google Mapping API v1 for the device in order for the map in Address Location Finder to work. Unfortunately it may be difficult for users to know whether their device has this requirement or not, possibly resulting in the app crashing.

So, removing the map from the app will remove this requirement and allow it to run on more devices (as well as reducing app crashes).

The map will become an optional add-on app for a future version of Address Location Finder.

2. The app will require Android 4.0.3+ to run.

The minimum API level to run the app will be raised to 15, which means it will now require Android version 4.0.3+ on the device to run.


The original minimum API level required for Address Location Finder was 8 (Android 2.2).

According to the Google dashboard for platform version, devices running Android 2.x now account for only about 10%.

Supporting old versions requires a fair bit of additional work

  • needs more testing
  • requires additional code, e.g. Android support library, to implement newer Android functionality
  • may require internal version checks for functions that would not work on old versions, possibly with alternate code

This all means it takes longer for updates of the app to come out. The diminishing returns in supporting the old versions is not really worth the extra effort and time.

Users with Android older than 4.0.3 who have already installed the app can just continue to use the old version of the app. They should not even see the new version of the app when it comes to the Google Play app store, since the store applies various filters to determine which apps to display (include the minimum Android version require to run).

Help! my Android USB Connection is dropping out

After updating Android on a phone that I use for testing, I started having problems when I connected it up to my PC. The USB connection would be there when I connected the cable, but then would seem to drop out after a short time. Sometimes it would disappear after 10 seconds, sometimes a couple of minutes, sometimes when I started up DDMS or Eclipse.

Very frustrating, but I hoped it would be a quick fix. But an hour later …

I guess I’m writing this as a cautionary tale for myself about going through proper procedures for problem solving instead of just guessing.

Firstly I tried to isolate the problem:

  • use a different USB port
  • use a different USB cable
  • try another Android device

From this I determined that the problem was with the phone, an old Nexus S that I use for testing older hardware and Android versions. Since I had just updated the Android version on the phone, I just jumped to the conclusion that it must have been a USB driver problem.

So next I made sure my Android SDK installation was up-to-date, and then updated the Android USB driver from it. Made no difference.

Then I tried uninstalling and re-installing the USB driver. Still not working.

At this point I was out of ideas and just went away for a bit.

Tip: When you hit a brick wall when trying to fix a problem, sometimes it can be helpful just to go away from it for a bit. Work on something else, go for a walk, have a coffee break, whatever. Let your subconscious do the work.

When I came back later, I remembered that I’ve had other intermittent issues with the phone since it was quite old. So I did what I should have done in the first place, the golden rule about fixing tech equipment.

Turn it off, wait, then turn it on again. Working now!

Guess this shows that it is easy sometimes to forget the basics.

Reusable Aspect Library for Android, Part 2

In part 1 of this post, we created an Android library containing aspects that could be used to intercept code in an application. However the library would require code changes in order to work with other application, and so was not really reusable as it stood.

In this part, we will modify the sample code to make the library more reusable across multiple applications.

Scenario 2 – The Pointcut in the Application

In this example, the aspect tracing code is kept in the aspect library project, but we will put the pointcut in the application.

Create the Projects

Create an Android application project and library project, and configure them as AspectJ projects in Eclipse, same as for part 1. Then add the library project to the application project, both as an Android library and to the application aspectpath.

Code Changes

1. Aspect Library

Once again put the AspectJ tracing code in the library project,  but this time the pointcut has been made abstract.

public abstract aspect BaseTraceAspect {

    /** Pointcut for tracing method flow tracing */
    protected abstract pointcut traceOperations();

    before() : traceOperations() {
        Signature sig = thisJoinPointStaticPart.getSignature();
        log("Entering [" + sig.toShortString() + "]");

    /** Implement in subaspect for actual logging */
    protected abstract void log(String msg);

Notice I have also made the log method abstract as well, this leaves it up to the application to determine how it wants to log the tracing output. In general any funcationality that is specific to the application should be made abstract here, and be implemented in the application.

2. Test Application

In the application project, add some code that can be intercepted by the aspect, as for part 1.

Then create another aspect file which subclasses the aspect in the library project. This aspect just implements the pointcut (and in this sample, the logging method as well).

public aspect TraceAspect extends BaseTraceAspect {

    private final static String TAG = "Aspect-Test";

    protected pointcut traceOperations(): execution(***.testMethod(..));

    protected void log(String msg)
        Log.i(TAG, msg);

Run and Verify

Once again run the application and verify in LogCat that the aspect tracing has worked.

Sample app 2

LogCat tracing

The Sample Code

You can download the sample code for this example, from GitHub. Follow the same instructions as for the previous example for running the sample app.


Now the aspect library project is reusable in other applications. An application would just need to include the library and then override the abstract pointcut to implement a concrete pointcut that is specific to it.

In the last part of this article, we will add another library to the application and show how to apply the aspects to it as well.

Reusable Aspect Library for Android, Part 1

There are various projects / tutorials / blogs out there about how to integrate AspectJ into the Android development process. They generally show you how to setup an application project to use AspectJ, with the aspects in the project itself.

However the way I tend to use AspectJ in Java projects is to try to put them into reusable libraries so that they can be applied to multiple projects. After all they are supposed to be used for cross-cutting concerns which are common to many applications. Searching the internet, I did not manage to find much information about how to do this in Android.

So here are some examples of one solution I found when using Eclipse (Windows version). If  you are not already familiar with creating and setting up Android projects in the Eclipse IDE, and with using AspectJ, have a look at the documentation for Android and AspectJ.

These are the requirements for the samples:

Note that the Android tools tend to be a bit brittle, so different versions may have changes (and bugs). So the examples may not work if you are using a different version.

Also I had the following design goals in mind:

  • keep it as simple as possible
  • stick to using Android libraries

With Eclipse you can put code in separate Java projects and either reference them from an Android application either as a project or a jar, e.g. create a ‘glue’ Android library that references a Java library.
While this might work in Eclipse, it would make things much more complicated if I wanted to use another build system (e.g. Ant) to build the application.

Scenario 1: Self-Contained Aspect Library

In the first example, we will create an android library that contains all the aspect code, and use it to apply the aspects to some code in an application.

Here are some instructions on setting up an Android library with aspects, along with some sample code.

The Test Application

This is just a very simple app to demonstrate the aspects working.

1. Create a new Android application project and add some code that the aspects can intercept.

public class MainActivity extends Activity {

private Button testButton;

 protected void onCreate(Bundle savedInstanceState) {

 testButton = (Button)findViewById(;

private OnClickListener testButtonListener = new OnClickListener() {
 public void onClick(View v)
 // invoke the method to be traced

 public void testMethod()
 Toast.makeText(this, "Inside test method", Toast.LENGTH_SHORT).show();

2. Add the AspectJ nature to the application project.

If you already know how to setup AspectJ in an Eclipse project, then you can skip the next bit …

To add the AspectJ nature to the application project, there are 2 ways of doing this:

a. Using the AJDT plugin
Right click on the project in the Package Explorer to bring up the context menu.

  • Click ‘Configure’
  • Click ‘Convert to AspectJ project’

Menu to convert to AspectJ project

b. Do it manually

  • Edit the ‘.projects’ file for the project.

Replace the java builder …


with the AspectJ builder …


and then add the AspectJ nature …


The edited file should look something like this:

<?xml version="1.0" encoding="UTF-8"?>
  • Add the AspectJ runtime jar to the classpath for the project.

The jar is named ‘aspectjrt.jar’ and it is probably a good idea to use the one that came with the AJDT plugin, which should be located under your Eclipse install at ‘plugin/org.aspectj.runtime_x.x.x’.

There are various ways of doing this, but if you have AJDT installed, the easiest way would be to add it as a library in your ‘Java Build Path’ dialog. In the ‘Java Build Path’ dialog, select the ‘Libraries’ tab, and then click the ‘Add Variable’ button. Then in the ‘New Variable Classpath Enty’ dialog that comes up, select the ‘ASPECTRT_LIB’ entry and click the ‘OK’ button.

Add aspectrt.jar as variable

To make the sample code a bit more portable, rather than doing it this way,  I’ve just copied ‘aspectjrt.jar’ to a directory named ‘lib’ in the project and added it to the classpath from there.

The Aspect library

This is the Android library project that will contain the aspects.

1. Create an Android library project

2. Add the AspectJ nature to the library project (the same as for the application project)

3. For these samples I am going to show a very common usage of AOP – tracing. So add some an AspectJ tracing code to an aspect file in the library project, with the pointcut configured to intercept some code in the application project.

public aspect TraceAspect {

    private final static String TAG = "Aspect-Trace";

    // pointcut to intercept a method in the application project
    protected pointcut traceOperations(): execution(***.testMethod(..));

    before() : traceOperations() {
        Signature sig = thisJoinPointStaticPart.getSignature();
        log("Entering [" + sig.toShortString() + "]");

    protected void log(String msg)
	Log.i(TAG, msg);

4. Add the aspect library project as an Android library for the application project.

Add aspect library project to application

5. Also add the aspect library project to the AspectPath for the application. Do this in the ‘AspectJ Build’ dialog for the application project.

For the application project, right click the project in the Package Explorer to bring up the context menu.

Then either …

  • Click ‘Build Path -> Configure Build Path …’ to bring up the project properties dialog
  • Click ‘AspectJ Build’ in the side menu

or …

  • Click ‘AspectJ Tools -> Configure AspectJ Build Path …’

In the ‘AspectJ Build’ dialog, click the ‘Aspect Path’ tab. Then click the ‘Add Project…’ button and select the aspect library project.

Add aspect library to aspectpath of application

Run the application

Now run the application in your device or emulator, making sure that the code that you want to trace is invoked.

Sample app 1

For the sample app, just click the button ‘Click to test tracing’, and then check in LogCat that the aspect tracing has occurred.

LogCat tracing 1

The Sample Code

You can download the sample code for this example, from GitHub.

Running the sample code:

  • Unzip the zip file containing the Eclipse projects.
  • Import the projects into your Eclipse IDE.
  • The sample projects have Android 4.0 (API level 14) as the Android build target. So you need to either have API 14 present in your Android SDK installation or change the build target for all the projects to another API version.
  • Optionally you may have to adjust any application or class paths to suit your development setup.
  • Build and run the sample application project.
  • Check LogCat to see if the aspect tracing is present.


The problem with this example is that the aspect library isn’t really all that reusable.

If you wanted to use the library in another application, chances are you would have to changed the pointcuts to match the code you want to intercept in the new application.

In the next part of this blog, we will make some improvements to it to make it more reusable.

Path Problems: Java (Android), Windows 64 and 2 Drives

I recently updated my installation of the Android SDK and ran into a problem that I’ve alway had on my current computer – the SDK Manager would not run after the update.

This is due to a Java path problem for a particular setup:

  • a computer running 64-bit Windows (Windows 7 in my case)
  • a computer with more than one disk drive installed

I also have Java 6 64-bit installed on the computer (not Java 7 as I use it for Android development).

Android SDK Manager – it no work

To re-iterate the issue: after installing or updating the Android SDK on a system with this setup, the SDK Manager may not be able run.

When trying to start the SDK Manager, in the ‘tools’ directory of the SDK installation, the batch file ‘android.bat’ is run. Inside the batch file it sets various path variables that point to libraries or to your Java installation that is required to run the SDK Manager.

This is where I run into problems.

One issue is this line in ‘android.bat’:

for /f %%a in ('%java_exe% -jar lib\archquery.jar') do set swt_path=lib\%%a

Here it is looking for the file ‘swt.jar’ which is located in the SDK installation under ‘tools\lib\x86’ or ‘tools\lib\x86_64’ depending on whether you are running a 64-bit system.

If you have only 1 drive in your system, then this should work. But if, like me, you have two drives then it may not work and the variable swt_path is not set.

Then there is this line where it tries to find Java:

call lib\find_java.bat

This runs the batch file ‘find_java.bat’ to set the variable ‘java_exe’ to point to the path of java.exe in your Java installation.

for /f %%a in ('%~dps0\find_java.exe -s') do set java_exe=%%a

Once again in my system this doesn’t work and the batch file can’t find my Java executables.

By the way when you try to do a build with Ant, it runs ‘platform-tools\dx.bat’ which also calls ‘find_java.bat’, so it runs into the same problem of not finding Java.

Why Does This Happen?

It seems this all has to do with the way Windows x64 handles the long and short format of file (and directory) names when working out paths.

Of course, this is for my particular setup. On your system it may all work fine – but you only have to do a quick google to see that many others have similar problems.

If you have this issue, then it’s worth checking for more common errors first, e.g.

  • the appropriate version of Java is installed correctly
  • JAVA_HOME and PATH environmental variables have been configured

Other Java Programs – GMote

I was recently reminded of all this when I was setting up my HTPC. This is a Windows 7 64-bit PC, once again with 2 drives (one for applications and the other for storing media files).

I was trying out GMote (an Android remote control app for playing media on a computer). This has a server component which runs on the computer and is a Java program.

After doing the default installation, I tried to run the GMote server and kept getting an error “Unable to load library ‘libvlc'”. After checking that the ‘libvlc’ library was in a folder in the PATH environmental variable, this error still kept occurring.
It took me a little while to find the problem with getting the GMote server to run:

  • I had the 64 bit version of Java installed, so I installed the 32 bit Java and pointed the JAVA_HOME environmental variable to it.
  • Since the path to the support library was under the default installation of GMote server at “C:\Program Files (x86)\…”, I re-installed the GMote server to another directory name that did not contain any spaces “C:\media\…”.

Finally it worked.

Why Two Drives?

At this point you might ask why do I have 2 drives on my computers?

I tend to install the system and application files on one drive, and data files on the other, I find this convenient for various reasons:
Backup – I can use different backup strategies on the different drives, e.g. do an disc image backup on the system and application drive and some other type of backup on the data that I want on the other drive. I also point the TEMP environmental variable to the data drive so that the temporary files don’t clog up my image backups.
Performance – Use a SSD for the operating system and applications disk for faster booting and app loading (Of course it would be nice to have a SSD for the data drive as well, but if you have a lot of data then this would be very expensive!).

The Moral of the Story …

So in this particular setup of trying to run Java programs on 64-bit Windows on a computer with multiple disk drives, I follow these guidelines:

  • check which version of Java is required by your program (64-bit or 32-bit)
  • check whether it requires the JDK or JRE
  • install Java programs in a path that doesn’t have spaces in the directory names, as you might do on a UNIX or LINUX system
  • point your JAVA_HOME environment to the appropriate Java installation (you can do this in a batch file before launching the Java program so that it is only local and doesn’t affect other Java apps)

So how did I resolve Android SDK issue on my system? If you google this issue, there are various suggestions as to how to fix it. These include things like digging into the Windows and Java internals, registry hacks, etc.

For me, I just took the easy route of editing android.bat to point the variables to the correct paths on my particular system. I know this is not the best way to deal with it, but after many frustrating hours of research, configuration and testing, I wanted to get things up and running quickly.
It’s a shame you have to waste so much time digging into Android issues to find the causes (and if you’re lucky, the solutions) of these problems. It’s not like running Windows x64 or having multiple drives on a computer is all that unusual.

But then the Android build tools have always been a bit flaky, so I guess it’s part of being an Android developer.

Android Fragmentation – A Developer’s Perspective

Much has been written about Android fragmentation, and how it affects consumers. But what does it mean for Android developers?

Well, more testing – lots more testing. And, of course, all the associated support and bug fixing issues for dealing with multiple versions.

You have to test for:

  • All the Android versions that you want to support for your app.
  • Then there is testing for different screen sizes (both in portrait and landscape mode, of course, and handling orientation changes between them).
  • Also testing for manufacturer phones that have a custom UI, especially if your app interacts with the UI in some way – for instance for widgets or if the app accesses system settings screens.

This sounds like a lot of work, and it is, if you are diligent about testing and providing a good experience for your users.

But then is this much different for developers writing web applications that work in browsers?

In that case you would have to test your app for:

  • All the major browsers that you want to support (Firefox, Internet Explorer, Chrome, Opera, etc).
  • Different versions of these browsers that might still be in use (and how to degrade gracefully for older versions).
  • Once again different screen sizes, particularly if you are supporting mobile devices as well as desktop.
  • Exception testing in cases where the user has disabled Javascript or is not using cookies.

So, from a developer’s perspective it’s not all that different from the issues that Android developers have in terms of having to do a lot of testing and app support.
They just don’t call it fragmentation, because it isn’t. But the issues with having to support multiple client environment versions are the same.

I consider that this is the price that has to be paid for working on systems that have some degree of ‘openness’ (in contract to systems that are tightly controlled by the company that owns it).

If you support openness in software, then I think this is a price worth paying.

Update 7/3/2015

Recently I have been investigating web (Javascript) frameworks to use for an upcoming project.

Then I came across this post about how bad fragmentation was in that area. Basically the gist of the article was that there were so many frameworks and libraries for building web applications, and the landscape was constantly changing. The author used the phrase ‘crisis of churn rate‘ to describe the mess.

Even frameworks like angularjs, which seems to have a lot of mind share at the moment, will have a new version (2.0) coming out possibly at the end of the year which will not be backwards compatible with the current version. More fragmentation!

After having read that post, and done a bit of research myself, it just reinforced my view that Android fragmentation was not really so bad after all.

Now, which Javascript framework/library/tool/combination should I be using …