Thanks to Cathy, we now have a revamped skin on our wiki. We also have acquired so update your bookmarks.<\/p>\n
I have been working on two areas of WeSay. The first is our data access layer. Db4o<\/a> provides a read only IList when queried. In the prototype, I had wrapped that result and provided our own read-write IList<\/a> that automatically kept the database up to date. With John\u2019s databinding work, we decided to provide a IBindingList<\/a> interface over db4o. I spent quite a bit of work creating tests for the various interfaces: IBindingList tests<\/a>, IList tests<\/a>, ICollection tests<\/a>, IEnumerable tests<\/a>. I had an implementation working with tests when we hit performance issues with filters and John found Marek Istvanek\u2019s work on providing a binding list over db4o. I chose to only use his db4oList class and implemented my own Db4oBindingList since we won\u2019t be needing the paging and didn\u2019t want to take on the associated risk. I had to modify the Db4oList class so that it would pass my previous tests.<\/p>\n Another big change to the Db4oList class had to do with unregistering the PropertyChanged event on classes which implement INotifyPropertyChanged<\/a>. A number of people have blogged about the \u201clapsed listener<\/a>\u201d problem which causes objects to remain in memory due to the event source retaining a reference to the listener after the listeners go out of scope.<\/p>\n The solution to this tricky issue is to either use weak delegates or require a call to dispose before the listener goes out of scope. Wesner Moise<\/a> claims that implementing weak delegates is a difficult proposition with a number of casualties (Joe Duffy<\/a> and Ian Griffiths<\/a>) to date. I found three implementations that still purport to be correct: Greg Schechter<\/a> (he also provides the best overview of the problem space), Xavier Musy<\/a>, and John Stewien<\/a>. We finally decided the best way to handle this was to remove the listener from the event source when dispose is called.<\/p>\n The other area is in moving our proof of concept lazy GTK nodestore to production standards. In the process I came across this blog entitled DataBinding an IList as DataSource for the Gtk.TreeView<\/a>. This obviously piqued my interest. At first, I adapted his code to use an IList<\/a> but when I tried to load the assembly, I discovered that templated classes cannot contain references to external methods, which makes sense so I\u2019m back to using an IList. This is still a work in progress for me too, but you can check out what I\u2019ve done in our subversion repository.<\/p>\n