SCALA development for Android is becoming more pragmatic

Only three weeks after my last post SCALA development for Android is becoming more pragmatic again. This is due to the new IntelliJ IDEA version 14.1.. IntelliJ IDEA provides now a seamless integration of the android-sdk-plugin:

1. Set ANDROID_HOME to the path where you have stored your Android SDK.
2. Download latest hello scaloid project template.
3. Go to the root of the hello scaloid project and type:
   android update project -p .
4. Make sure you use IntelliJ IDEA 14.1 or later.
5. Install SCALA and Android plugins into IDEA.
6. File -> New -> Import Project... -> Import project from external sources... -> Import project from external model -> select SBT.

This should do the job and compiling and debugging should work out of the box.

SCALA development for Android

One year ago, I was excited how easy scala development could be done for Android within Eclipse. I just added the scala-ide plugin for eclipse plus the ANDROID_PROGUARD_SCALA plugin. Everything worked nicely out of the box.
When you search the web today this procedure is still promoted actively in many places such as the official SCALA website. Just try this if you have a few hours to loose. I tried it with the SCALA ide and Eclipse Luna standard edition ....

The next thing I tried was the new SCALA activator tool which looks great and you can find templates for Android and Scaloid. Unfortunately, they seem to be outdated and you should try to use activator for this purpose, only if you have a few hours to loose....

After too many hours lost, this is how it worked out for me:

1. Start from the hello scaloid project template.
2. Update the plugins inside /project/plugins.sbt to their last versions.
3. Set ANDROID_HOME to the path where you have stored your Android SDK.
4. Start sbt inside the project folder.
5. You can call "sbt android:package" to compile the project.
   Unfortunately the Proguard settings are not good anymore. I have to look into Proguard settings at  a later time. For now, I set useProguard := false in build.sbt to get started.
6. "sbt run" puts the apk file on your connected device and runs it. Now you can compile and run the Android command line tools.
7. Do you want to compile, run and debug from an IDEA? "sbt eclipse" creates you a project. Unfortunately again, this does not work! No easy eclipse integration.
   IntelliJ IDEA comes to a rescue.
8. Add the sbt-idea plugin to sbt.
9. Run "sbt gen-idea"
10. Now you can open your project with IntelliJ and compiling and debugging works fine through the IDEA. 

As a conclusion, it is pretty clear that the pragmatic Android developer is not going to write his code in SCALA.

Git: Check last changes in a given file

To see the last commits of a given file:
git log <filename>

What has changed:
git log -p <filename>

To see more options:
git help log

There is also a nice tool to browse the commits visually:
gitk

Install Oracle Java JDK on Ubuntu 14.04

1. Download the JDK from Oracle.
2. Extract the file to /user/lib/jvm.
3. Change the owner to root:
   chown -R root:root jdk1.8.0_11*
4. Install java, javac, etc..:
   update-alternatives --install /usr/bin/java java /usr/lib/jvm/jdk1.8.0_11/bin/java 1065
5. Setting the system's java version:
   update-alternatives --cofig java
6. Testing the java installation:
   java -version

Upgrade Ubuntu 12.04 LTS to 14.04 LTS (emacs problems)

I did a direct upgrade from Ubuntu 12.04 LTS (Precise Pangolin) to 14.04 LTS (Trusty Tahr) using the "Update Mangager". As usual a few things went not so nicely ...

During the upgrade the  following error message was shown:

 I closed this message and continued the upgrade. After all packages were updated the system needed a reboot. At the first boot the system was complaining that my video card (nvidia) could not be configured properly. I chose the "configure now" option, however the screen froze finally. A reboot by pressing the on/off button made disappear this problem magically.

The classic Gnome desktop is now called "GNOME Flashback" session. It seems to work fine right out of the box.

When I checked the update manager, I have seen that the upgrade could not be completed due to the previous emacs problem. It seems to be a bug similar or equal to this one. I could finish the upgrade when I deleted the scripts in  /usr/lib/emacsen-common/packages/install .

As usual one needs to reactivate the third party software sources in "System Tools" -> "Administration" -> "Software Sources" -> Other.


Unfortunately some messages "System program problem detected." persists:

These can be removed with:
sudo rm /var/crash/*

The jackass agile manifesto

Once upon a time, there was the agile manifesto written by brave men which "uncovered" in us "a better way of developing software". It was such a success that everybody became agile. By now, even the agile waterfall is not as uncommon as you might think. There are uncountable agile evangelists out there who help us to become agile without having done a single software project in the last fifteen years.

Why is agile such a success story? It gives the freedom back to developers. Self-organizing teams protected from the outside world have more fun than ever and are more productive. QA people like agile because agile people are more open to the new heavy weight processes than this old stupid waterfall guys. Management knows that software projects are doomed to failure and agile could be the missing link which was sought so desperately during the MBA.

There is this viscous triangle which seems to agilize everything and everybody. Even our team got roped into this triangle and we live now our own agile way:

We avoid to deliver software continuously as promised by accusing the customer of not being agile.

We use changing requirements as a welcoming excuse for not having delivered software previously.

Agile is an excellent excuse for not documenting anything.

Agility forbids to plan more than one sprint in advance.

We self-organize our team to freely move unloved tasks from one sprint to the next.

We focus fully on the current sprint. No need to understand what we are developing.


We lived happily ever after.

Test static methods with JMockit

If you want to use JMockit within Eclipse you have to be aware of several pitfalls. You cannot use the Junit.jar which is integrated into eclipse. You need to download it from the original junit.org site. Further, it is important that the jmockit.jar appears before the Junit jar in the classpath. Go to the  "Order and export" tab of the "Java build path".

Looking now at a very simple example to test static methods:

1:  public class MyStaticClass {  
2:      static boolean doSomethingCrazy() {  
3:          return true;  
4:      }  
5:  }  

The test for this static methods could look as follows:

1:  import static org.junit.Assert.assertFalse;  
2:  import org.junit.*;  
3:  import mockit.*;  
4:  public class StaticTest {  
5:      @Mocked  
6:      MyStaticClass myClass;  
7:      @Test  
8:      public void testMakeConnection(){  
9:          new NonStrictExpectations(){  
10:              // MyStaticClass is mocked here  
11:              {  
12:                  MyStaticClass.doSomethingCrazy();  
13:                  returns(false);  
14:              }  
15:          };  
16:          boolean wasItCrazy = MyStaticClass.doSomethingCrazy();  
17:          assertFalse(wasItCrazy);  
18:          new Verifications() {{  
19:              MyStaticClass.doSomethingCrazy(); times = 1;  
20:          }};  
21:      }  
22:  }  

JMockit appears to be very powerful and elegant. I will publish more examples soon.