This week I ran into a WPF data binding problem and spent about a day trying to figure out why it wasn’t working.  A day is a long time to spend on why a “Text” property is not binding to an object’s property which is of the type “String”.  Here’s some quick tips on identifying the source of the data binding problem.

1)  Ensure Data Binding Debugging Information shows in Visual Studio’s Output window.  Visual Studio has the capability of showing verbose data binding trace information.  This can help you get to the bottom of the issue quickly.  In my case, my output window was not showing any data binding information…  You’ll need to adjust some Visual Studio debugging options.  First, ensure that all debugging information is not being sent to the immediate window.  Tools >> Options >> Debugging >> “Redirect all Output Window text to the Immediate Window”.  Uncheck that.  Next, Tools >> Options >> Debugging >> Output Window >> WPF Trace Settings >> Data Binding.  Select an option here.  When I was debugging I wanted to see everything going on so I selected “Verbose”.  Unfortunately, the information did not tell my anything as to why my two-way binding was not updating the underlying object’s property…

2)  Understand Dependency Properties and the INotifyPropertyChanged interface.  In order for the UI to properly show object property changes or to perform two-way binding, the property which it binds to needs to be a dependency property or the object needs to implement the INotifyPropertyChanged interface so that the UI properly reflects the object’s property changes and the UI can also update the object’s properties (if two-way binding is enabled).  In my case, my UI control was bound to a dependency property which its type also implemented INotifyPropertyChanged and my two-way binding still didn’t work…

3)  Are you using a Converter in the data binding expression?  Sometimes converters can throw exceptions and break the binding.  Put breakpoints in your converter and ensure the conversions are not throwing exceptions and breakpoints are being hit.  In my case, the convert from was being hit, but the convert back (updating the object from the UI via two-way data binding) was not being hit.  So one-way was working, but two-way was not…

4)  Are you binding a Custom Control which overrides/overloads the property which you are wanting to bind to?  This was the problem for me.  I was wanting to two-way bind the “Text” property of a custom user control to my object’s property.  The custom control was inheriting from TextBox and they were overloading the “Text” property.  Apparently this broke the two-way data binding.  I figured it out by simply dropping a vanilla TextBox onto my UI and binding it’s “Text” property to my expression and two-way binding worked great.  So, when things get really hairy, simplify what you are doing and add more and more things back into the picture until something breaks.  Troubleshooting 101 for the win.

In case some of my readers do not know, I am a College of the Ozarks alumnus and I currently work for HealthMEDX.  I graduated from the C of O Computer Sciences Program in 2001.  Over the past year, I’ve had some great opportunities to assist C of O students and faculty.  I was able judge senior projects in May.  In July, HealthMEDX invited C of O faculty to share in its success with MO Governor Jay Nixon and HMX C of O alumni in the form of an incentives announcement.  In October, I was able to guest lecture on n-Tier application development and I recently had the opportunity to speak at the ACM Meet & Greet.  I wanted this post to serve as a big thanks to HealthMEDX for the chance to help assist the C of O Computer Sciences Program.  I’d also like to thank C of O students and faculty for the invitations to do so.  I truly hope that my experiences and knowledge help the program.

July of 2011 – C of O Faculty and Alumni (now HealthMEDX employees) with MO Governor Jay Nixon at a press release event in which an economic incentive package was announced to help generate 65 new jobs at HealthMEDX.

December of 2011 – ACM Meet and Greet - C of O alumni gave their career experiences and provided tips on: interviewing, landing the first job, and what to expect after graduation.  Guest Speakers: Melissa Wagner (FedEx), Bill Christenson (HealthMEDX), Joel Cash (Cerner).

If you are like me, you may be confused with all of the Android release code names.  Something I learned today is that the code names are in alphabetical order.  So if 5.0 is Jelly Bean, my wild guess is 6.0 will be Kiwi…

Something else I learned today… don’t set your SD card size to 16gb for your AVD.  It literally takes up 16gb of HD space and takes forever to allocate.  :(

In my last two posts on Android, I went over how to setup your machine to program for Android and I also went over how to create an Android project.  In this post I’m going to go over Android Virtual Devices and how they are used in Android development.  An Android Virtual Device (AVD) is an emulator configuration which models an Android device.  Before you can run your application, you have to define an AVD to run and test it on.  Setting up an AVD is very easy using the AVD Manager integrated into Eclipse.

To setup a new AVD in Eclipse, you’ll need to navigate to “Window >> Android SDK and AVD Manager”.  Click the Virtual Devices option on the left side.  I will show you how to create a Gingerbread (Android 2.3) AVD.  To create the AVD, click the “New” button and fill out the options as shown below.  Click “Create AVD” when you are finished.

Copying the options I have set above will create a generic Android Gingerbread emulator to use.  Next, I’ll briefly touch on what each of the AVD options do.

Name:  The name of the AVD.

Target:  The API level to which you want to test against.  Typically this is the API level that you setup for your application’s build target.  The AVD target level must be greater than or equal to what your application is set to.

CPU/ABI:  This is intended for Android devices which run on non-ARM processor architectures.  From my research, I’ve not seen any devices that supported such.

SD Card:  The size of the SD card.

Snapshot:  This option is a newer option which helps speed up the starting of the Android emulator.  You can enable this so that the emulator will launch quicker and when you stop it, it will save its state.  You can disable the save to snapshot after you’ve saved it once in the state you want to help it close faster.  On my machine, it’s still slow to start… but maybe that’s just my laptop’s poor disk speed.

Skin:  The skin of the emulated Android device.  HVGA is default.  You can download custom skins.

Hardware:  You can define all sorts of custom settings to emulate (e.g. RAM size).  I’m not going to list them here, but you can view the list here.

Override the existing AVD with the same name:  If you have an existing AVD created that has the same name as you just named this AVD device, it will override the old one.

In my last post, I showed what is needed to get started programming for Android.  There’s a lot that goes into setting up your machine’s environment (SDK’s, IDE’s, Plug-Ins, etc).  Once that’s all done, you are probably ready to start programming in Eclipse.  My first obstacle I encountered was creating a new Android Project.

When creating a new project in Eclipse, you are presented with a “New Project'” wizard.  If you installed & setup all the items I mentioned in my last post correctly, you’ll have a new project type of “Android Project” in the “Android” folder.  It should look similar to below:

Once you’ve selected to create an Android project, your SDK mapping will kick in and the subsequent step of the wizard will populate all the build targets for you as well as present you with a ton of project creation options.  If you don’t have any build targets, you’ve not set your SDK location properly.  You can do this by going to Windows >> Preferences >> Android and fill in the SDK location.  Below are screenshots of the “New Android Project” step in the wizard.  I’m going to go over what these project creation options are.

Project Name:  This is the name of the directory where all the project files will reside.  This is an "Eclipse” thing.  Just make sure that your project name will be intuitive and unique.

Build Target:  This is basically the minimum version of Android which your application will run on.  Keep in mind that Android applications are forward compatible.  So if you choose Android 2.2, it will compile against the Android 2.2 platform library, but technically it should be able to be ran on  Android 3.0.  So choose your minimum supported version for your target here.  Pick the lowest version your application can support.

Application Name:  This is the title of your application.  This will be seen by your users on an Android device.  It is good to be descriptive, but keep it somewhat short.

Package Name:  This guy is a bit tricky.  It is the namespace which your application’s source code will reside under.  The tricky part is the realization that on Android devices, the package name MUST be unique.  So if two applications are running under the same package name (namespace) of “HelloWorld”… bad things.  As a result, there is a “domain-style” naming methodology that should be employed to keep things unique.  The suggestion is to always follow a “com.companyname.packagename” type of a naming model.  The “companyname” can be your organization, company, or unique name which identifies the developing entity.  I’ve also read that com.google, com.android, and com.example are reserved.  So stay away from those.

Create Activity:  This is a class that is auto-created by the plugin which is a subclass of Android’s Activity class.  The class is a stub which will be launched when your application starts up.  Other activities can be created from your application, but this is the first one that the user will experience.

Min SDK Version:  As I previously noted with the build target, you choose the minimum SDK version which your application will support.  This option tells what the minimum API level will be along with the minimum SDK version.  Each build target should have a corresponding API Level assigned.  Pick the API Level for the build target you previously chose.  So again, the Min SDK Version number will match the Build Target number for most applications.