Hello world!

July 18, 2012

Ha, the default first blog post generated by WordPress, the title seemed kind of fitting given the nature of this blog so I figure I’ll leave it. We’re gonna have a few “Hello World!” type examples so why not start here?

If you want to actually know what this is all about you can go to the about page.


Read the rest of this entry »

Android Testing

October 15, 2014

I’ve recently started looking at the Android testing framework and once again I have to say I like it, I’m impressed with the set of tools available.

I won’t say too much about it as it’s covered pretty comprehensively in the Android documentation here: http://developer.android.com/tools/testing/index.html (note some of this stuff, namely the tutorial is pretty out of date, SDK 8, but it is still valid), and here: http://developer.android.com/training/testing.html.

What I will say right now is that if you’re not testing your code as soon as you begin writing your code at the very latest (many proponents of Test Driven Development advocate writing your unit tests before you start writing application code) you should be, really, you should (I intend to make the case for unit testing in another post sometime).

The Android SDK tools make it really easy to start testing, they provide everything you might need in terms of base test classes, mocks, instrumentation and automation. The documentation gives guides on what to test and how to test.

With all of these tools built into the SDK it would be foolish not to use them. If you’re new to Unit Testing and Software Testing in general I think this could be a really good place to start.

For me personally, having such a comprehensive framework in place immediately removes any barriers to unit testing (Unit Testing can be hard at times :(, sometimes it seems that I put more time into writing tests and the conditions under which they can run than actual application code), quite simply there are no excuses for me not to do it here.

Some things what I likes:

  • Familiar – Based on JUnit, anyone who has used JUnit and it’s test runner should be comfortable straight away.
  • Built in Instrumentation for testing Activity lifecycle and UI components – To try to do this from scratch would be incredibly tedious.
  • Comprehensive mocking framework – There is a good set of system mock objects that can be used for dependency injection. Often external dependencies of classes can cause difficulties in testing, providing mock objects helps alleviate this, having a ready made set of mocks to extend is very helpful.
  • UI automation – Great for automated system/functional testing, anyone who has had to run manual regression tests on Software UIs will appreciate this.

Hmm, before committing my project to Mercurial source control I like to run a clean so that nothing that’s part of a build shows up as a change that I don’t want to commit (although I’ve added lines to .hgignore to ignore any generated class files and the gen directory where the ADT auto generates some files  so this probably wasn’t even necessary).

When I came back to my project at a later date there were errors in all of my activity classes, turns out that the auto generated R.java file had been deleted and was stubbornly refusing to be re-generated and so anything that depended on this (lots of stuff!) had errors, really f**king annoying.

I never found a satisfactory solution to this problem and eventually restarted the project from scratch as I’d only really just started it anyway, Google gave me few suggestions from other people but none of them worked, it seems a lot of people have had this issue. Here are some of the popular suggestions that have worked for other people.

  • Clean/rebuild – These options are under the ‘project’ menu in the main Eclipse menu, usually the project is set to build automatically whenever changes are saved so after a clean a build is usually performed, if it’s not the clean dialogue gives you the option to build immediately after a clean.
  • Deleting gen – This should cause gen and everything under it to be re-generated, the directory itself and BuildConfig.java were re-generated for me but not R.java.
  • Setting derived to false on gen – You can check this by right clicking on the file in Eclipse and selecting properties, apparently if you put gen under source control when it’s pulled out it can have the derived property set, as I didn’t have gen under source control this was never the case for me.
  • Restart Eclipse.

So far everything has been fine since, perhaps I’d missed out a file that should have been under source control which then got deleted on a Mercurial ‘update’ command? I guess the takeaway lesson for me is to be extremely careful to make sure any changes that should be committed are before updating or pulling code.

Came across this again today and found a fairly comprehensive list of things to try on Stack Overflow here http://stackoverflow.com/questions/2757107/developing-for-android-in-eclipse-r-java-not-generating.

Second answer is most useful I think.

This is an annoying problem that I would come across from time to time.

When debugging a Java application on Linux (Mint 11) using Eclipse, on hitting a breakpoint the whole system would appear to freeze.

I found I could drop down to a shell with CTRL+ALT+F1, login then use list the running processes and grep for any java processes and kill the relevant process.

simon@simon-mint-vm ~ $ps -ely | grep java
S  1000  2374  2373  6  80   0 442072 297255 futex_ ?      00:01:57 java
S  1000  3216  2374  0  80   0 86264 1442616 futex_ ?      00:00:08 java
simon@simon-mint-vm ~ $ kill -9 3216

Then return to the X session with CTRL+ALT+F7 and the screen would be unfrozen.

After having to do this numerous times I managed to find a solution on the internet; when starting the jvm give it the option -Dsun.awt.disablegrab=true

In Eclipse you would enter this in the ‘VM arguments’ pane in the ‘Debug Configrations’ dialogue.

I believe this to be a JVM problem rather than anything to with Eclipse, I was using JRE.

Me and the IDE

September 25, 2014


I’m just going to come straight out and say it. I love using modern IDEs.
Yes, I’m sure I can write code just as well in a plain old text editor with a bit of code highlighting, yes, I’m sure Emacs can do everything my IDE does and so much more, maybe real developers use Vi(m), (Vi, don’t get me started, Emacs I can handle but Vi, really, why? Ok maybe cos I’m too lazy to learn how but that’s kinda my point), maybe all that IDE clutter distracts from the purity of the essence of distilled code.

Maybe, but I just want to get stuff done. I’ve worked with nothing but Emacs, a console and the GNU tool chain developing c/assembly applications for embedded Motorola 68000 based chips, it worked, it was actually quite fun because it demanded an intricate understanding of what was going on, from the workings of the tool chain on the development OS right down to the hardware level of the target, but man was it tedious.

No, give me my comfy chair of an IDE, take away my code completion and I’ll start to scream, and maybe punch something.

Currently eclipse is my tool of choice, I like it, it’s easy to use, highly extentible, well supported by the software community, and free.

I’ll admit that I actually enjoyed using Visual Studio 2010 (the last version I used) and was a bit sad when I moved to Java development (although why the f**k does an installation of VS take up more space than the operating system, around 6Gb, wtf!! I reckon they’re just writing a load of random ones and zeros to the hard disc to make it look big to justify the cost 🙂 ).

Ok, there is a good argument that too much hand holding causing a dumbing down of software development (see this excellent article by Charles Petzold http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html), but surely it comes down to using the tools available the way that’s best for you, not letting the tools lead you.