Posts

After a bit of tinkering, I managed to provision my ADP1 setup without a SIM card.  A bit of google, and here is what I did

1. Download the Android SDK.  In my case, I unzipped it to C:\android-sdk-windows-1.1_r1.
2. Connection the phone via the USB cable to my computer.  When the phone asks for a device.
3. You’ll get the new hardware dialog, when prompted for the drivers, you’ll need to specify the location.  The Android SDK has the drivers, in my case they were at C:\android-sdk-windows-1.1_r1\usb_driver\x86.
4. Once you have the drivers installed cd to c:\android-sdk-windows-1.1_r1\tools.
5. Type adb devices.  This should list all the Android devices that you have connected.  If you don’t see any devices listed, then you have a problem.
6. Type adb shell.  This will direct your commands to your ADP1
7. Now while at the adb shell, su to root, then : 
8. cd /data/data/com.android/providers.settings/databases/
9. sqlite3 settings.db
10. INSERT INTO system (name, value) VALUES (‘device_provisioned’, 1);
11. .quit
12. Reboot the phone
13. adb shell
14. am start –a android.intent.action.MAIN –n com.android.settings/.Settings

Once all that is done, you should be enable to use your ADP1 as if you had a SIM card in it (we’ll except for the phoning part).

Every developer, no matter how experienced, has to dig in and fix bugs.  This is, in my experience, the typical cycle:

1. bug is reported
2. bug is assigned to developer
3. developer thinks the bug is fixed
4. developer marks bug as resolved
5. tester checks to see bug is fixed, but it isn’t.
6. tester reopens bug, assigns it back to developer
7. back to step number two.  Repeat until developer (or tester) climbs to the top of a 307 foot administrative building with high-powered rifles to demonstrate USMC-worthy marksmanship.

Now, even if you aren’t into the whole Lean Software development philosophy (i.e. eliminating waste), you can probably appreciate that it can be pretty wasteful of time and patience every time that #6 happens, so please indulge me as I elaborate on some of the finer points of bug reporting. 

(Note:  this article is pretty dated, and used IntelliJ 8.

So I have this semi-fancy Google Android Dev Phone 1.  Lately I’ve been devoting part of my spare time to learning about programming for Android (the OS of the phone).  Google (probably because they didn’t ask for my opinion and/or input) decided to use Java as the lingua franca for Android programming.  If you ask me - and I know you will - they should have used C# and Mono (I might be a bit biased here).  Luckily, years ago I had done Java programming, so I wasn’t that intimidated by the use of Java on Android.

Figured I was due to spend some time setting up a Linux VM and learning how to program my Android Dev Phone 1.  Eclipse is what is recommended, so I thought I’d give that a try first.  So, with the help of Suse Studio, I quick built myself a VM with Java 1.6 (Aside:  I love Suse Studio, I can provision a VM in minutes).  I figured it would be pretty straight forward.  The docs on the Android Developer site for installing ADT plug-in seem pretty straight forward and simple, and I remember Eclipse having a very rich ecosystem of plug-ins that were easy to install (something I wish Visual Studio had – hint, hint Microsoft).

After a bit of tinkering, I managed to provision my ADP1 setup without a SIM card.  A bit of google, and here is what I did:

1. Download the Android SDK.  In my case, I unzipped it to C:\android-sdk-windows-1.1_r1.
2. Connection the phone via the USB cable to my computer.  When the phone asks for a device.
3. You’ll get the new hardware dialog, when prompted for the drivers, you’ll need to specify the location.  The Android SDK has the drivers, in my case they were at C:\android-sdk-windows-1.1_r1\usb_driver\x86.
4. Once you have the drivers installed cd to c:\android-sdk-windows-1.1_r1\tools.
5. Type adb devices.  This should list all the Android devices that you have connected.  If you don’t see any devices listed, then you have a problem.
6. Type adb shell.  This will direct your commands to your ADP1
7. Now while at the adb shell, su to root, then : 
8. cd /data/data/com.android/providers.settings/databases/
9. sqlite3 settings.db
10. INSERT INTO system (name, value) VALUES (‘device_provisioned’, 1);
11. .quit
12. Reboot the phone
13. adb shell
14. am start -a android.intent.action.MAIN -n com.android.settings/.Settings

Once all that is done, you should be enable to use your ADP1 as if you had a SIM card in it (we’ll except for the phoning part).

If you using a unit testing framework such as NUnit, you’re no doubt familiar with the [Ignore] attribute.  (Note:  I haven’t used MbUnit in a while, but I’m pretty sure that all this applies there as well.)

For those who aren’t, when you adorn your [Test] with this attribute, then your test runner should pay no heed to this particular [Test].  Instead of going green or red, your test turns up as yellow in your test runner. At first blush, this seems handy - rather than deleting a failing or broken test you can have it [Ignore]d.

One of the nice things about Dependency Injection is that it can really help write a more flexible, modular application.  These days, it seems that there is no shortage of choice in the .NET community when it comes to IoC frameworks:

• StructureMap
• Castle Windsor
• Ninject
• Autofac
• Unity
• Spring.NET
• And probably others that I’m missing.

Ironically, when you first start using an IoC framework, you might find that in trying to make a loosely-coupled, modular, application you end up shackling yourself to the framework you’re using for IoC. For example, you start off using your own homegrown IoC framework, and then decide at some point in the future to use a different framework, like say StructureMap.  Going through your codebase to make these changes can be quite the exercise in pain. There are a couple of ways to isolate yourself from this kind of situation.  I won’t get into all of them but instead will focus on the Common Service Locator.

Lately I’ve been experimenting with TypeMock Isolator,  and it’s new AAA syntax.  For the past two years I’ve been a diehard Rhino.Mocks kind of guy, but figured that it’s time to check out other tools.  Anyway, I had a situation where a unit test of mine was failing when I ran it with TestDriven.NET, but would pass when I ran it using the unit test runner in Resharper 4.1.

Usually when I develop, I write individual tests and then run individually with TestDriven.NET and collectively with Resharper.  In this case, as I was writing one unit test, it kept failing with TestDriven.NET.  At first I thought it was just me being stupid (always a good place to start), and then I was worried that perhaps the documentation for TypeMock was to blame.  So, I sent a email to Avi at TypeMock, mostly expecting confirmation of my stupidity.

Lately I’ve been experimenting with TypeMock Isolator,  and it’s new AAA syntax.  For the past two years I’ve been a diehard Rhino.Mocks kind of guy, but figured that it’s time to check out other tools.  Anyway, I had a situation where a unit test of mine was failing when I ran it with TestDriven.NET, but would pass when I ran it using the unit test runner in Resharper 4.1.

Usually when I develop, I write individual tests and then run individually with TestDriven.NET and collectively with Resharper.  In this case, as I was writing one unit test, it kept failing with TestDriven.NET.  At first I thought it was just me being stupid (always a good place to start), and then I was worried that perhaps the documentation for TypeMock was to blame.  So, I sent a email to Avi at TypeMock, mostly expecting confirmation of my stupidity.

Most who know me are aware that, despite being a .NET developer and a Microsoft MVP, I’m a bit of a Linux freak at heart.  I actually prefer Linux to Windows.  Linux has come a long way in the past 18 years, although I’ve only been tinkering with it off and on for the past 9 years or so.  I will admit that perhaps Linux on the desktop isn’t quite there for the average consumer, but for me it.  And, when it comes to servers, there is no question:   use Linux unless you’ve got a pretty compelling reason to run Windows.