Google Android Development Agency SASS

Wednesday, 9 December 2009

NUnit and App.config

Here's the problem: You have a project which you want to unit test with NUnit but the project relies on some appSettings or other config data normally loaded from app.config or web.config. You know the sort of stuff, connection strings, usernames etc.

When you run your code in NUnit you get a NullReferenceException when you try to access your config, it's like it's being ignored.

I come across this problem quite often but I always have to refresh my memory of how I fix it. Well there's two ways, but only one I can get to work reliably:

1) When you create your nunit project, rather than clicking Project-> Add Assembly, just drag your DLL from Windows Explorer onto NUnit. After doing this it'll pick up the assembly.dll.config file for your assembly. I couldn't get to work reliably though, it would work once and then fail.

2) You need to have a config file named the same as your nunit project and located alongside. So in my case I have com.sass.ecommerce.tests.nunit and alongside it my assembly (com.sass.ecommerce.tests.dll) and my renamed config file, com.sass.ecommerce.tests.config.

Doing it the second way gave me more reliable results and I could access my config file no problem from my unit tests.

Tuesday, 1 December 2009

Tub Thumper Pro for Android out this week

At long last, we're looking at releasing Tub Thumper Pro for Android this week.

We've been into Android Development since day one and I've been constantly suprised at the amount of positive feedback we've had from the first version of Tub Thumper. We receive emails daily asking us about the pro version so I'm hoping it's going to be well received.

I'll put some more details online once it's live in the Android Market, but here's a screenshot of the sequencer interface in the meantime, which is one of the coolest new bits.


Tub Thumper Pro Sequencer Screenshot
You'll need at least Android 1.5 to run it and a touchscreen device. It's pushing the low-level audio features of Android with this tool, although I already have plans for Tub Thumper Pro 2! Watch this space...

At last! A good UML Editor for Visual Studio

For years I've been trying various different UML/CASE tools for designing .NET based solutions and until now I've always been left diasappointed. (I've not tried the new in-built tools of Visual Studio 2010 yet...)

This week I've been working on an e-commerce system for a client of ours who have chosen to use Sagepay as their payment gateway. Their site is built on the Kentico CMS platform and the Kentico E-commerce system doesn't support Sagepay out of the box, so basically I'm designing a payment provider for it.

I decided to try once again to find something decent to do Use Case diagrams, Activity diagrams, ST diagrams etc in so that I don't have to resort to Visio and Word as always.

Praise Jebus! Something good at last in the form of Tangible T4 Editor for Visual Studio. This is a plugin for VS.NET which allows you to create half-decent looking UML painlessly.

Here's an Activity diagram for the aforementioned e-commerce system I'm working on:




The only gripe I have so far is with the Use-case diagram tool; it would be really nice to be able to double-click on a use-case to open up a text-view of the actual use case allowing me to document the steps and pre and post conditions.

Here's the best bit: THERE'S A FREE VERSION!

Friday, 27 November 2009

Android AudioTrack source

I've been doing a lot of work optimising our audio playback on Tub Thumper Pro for Android this week and I constantly find myself referring back to the C++ source for the OS to help solve latency issues.

For anyone doing work with the AudioTrack object, it's worthwhile bookmarking the source online so that you can browse it whenever you hit a problem.

Here's two links I find really useful:

Incidentally, I've found that the best way of getting low-latency polyphonic audio is to subclass AudioTrack and call finalize() yourself after you're done playing; I was seeing more "write blocked for xx seconds" messages before I did this, although it may be co-incidental.

Thursday, 26 November 2009

Useful tool for building Android user interfaces

Android user interfaces are built using XML and the support for graphically laying these out in Eclipse is limited to say the least. (There are many things wrong with Visual Studio .NET but at least the UI builder is reasonably well sorted...)

A while back I came across DroidDraw - a third party tool for prototyping UIs. I think I must have had an early build back then because it had some issues, but I downloaded the latest build today and it's now hugely useful.

If you want to throw some Android user interfaces together head over to http://droiddraw.org/ and try it out. It's the tool Google should have included with the SDK!

Tuesday, 24 November 2009

Android Activity States and State Transitions

I wanted to tidy a bit of our Android code up recently to make sure that each Activity was handing it's state properly and to make sure that things were getting cleaned up when the Activity was done.

Before doing this it was important to fully understand the lifecycle of an Android Activity and to understand the state transitions that will and can occur within one.

An Android activity basically exists in one of four states:


Here's a bit more detail about each of these states:

Active
The Activity is in the foreground of the screen and is interacting with the user

Paused
The Activity has temporarily lost focus behind a new non-fullscreen or transparent Activity. In this state is retains all of it's state, however, if Android detects a low-memory situation it may be killed.

Stopped
The Activity is totally obscured behind another Activity. Again it retains it's state, but is much more likely to be killed at any point.

Finished
The Activity has been closed, either by Android or by calling finish(). The state it had dies at this point (unless you explicitly save it).


There are seven events in the Android Activity Lifecycle which give you a bit of control over what happens during each state transition.

onCreate(Bundle icicle)
Fires when the Activity is first launched. You would normally do all of your setup in this method. You can also retrieve any previously saved state from the supplied Bundle.

onStart()
Called when the Activity is becoming visible to the user, for example when another Activity higher in the stack has closed.

onRestart()
Called after the Activity has been stopped and is being restarted.

onResume()
Called when the Activity is becoming interactive to the user.

onPause()
Called when Android is about to start resuming another Activity. You would normally use this to stop anyting dynamic that is happening in your Activity, e.g sounds playing, animations happening.

onStop()
Called when the Activity is no longer visible, usually because another Activity has started over the top of it.

onDestroy()
This is the last breath of your Activity, called just before Android pulls the plug on it.

Here's a state transition diagram to show the sequence of states and the events in between:



isDaemon and Java Threads

Whilst pondering the best way to organise the threading structure of our upcoming Android app Tub Thumper Pro, it struck me that there is a smattering of confusion (at least in my head!) over whether a thread is a daemon or not.

In Java, there are two types of threads Daemon Threads and User Threads.

User Threads are the ones you'll most commonly use; these provide the mechanism of running parallel code in your applications. Most importantly - when the application is terminated, the JVM waits for all user threads to finish before quitting.

Daemon Threads are generally used for service-level processing rather than application-level code. The JVM will not wait for any daemons to finish before quitting your application, they will run behind the scenes until the JVM decides there's nothing else to do and terminates.