Pitfalls and performance issues

v 2.0 - last updated 08/07/2006

Lack of uniqueness in DisplayName
One reason I'm not fixing this on the database side is that this is a classic problem when you create software that has real users--those "pesky users" often end up doing something you never expected and then you have to adapt the software somehow to deal with it.   In a production environment, this would likely get fixed on the database side, whereas you are required to deal with it in the client software.

Performance
It is not a good idea to download everything at once initially.  By some calculations, if one downloads everything at once, just the blog table will come up around 2 megabytes.  So that’s 2 megabytes if downloading everything all at once, versus ~300 bytes if downloading just the usernames.

If you don't get everything at once, you need to deal with the wait for server round-trips to get additional info.   It is important to avoid clearing everything and reloading from scratch; you'll probably want to make updates just update the things being displayed (or responded to, or posted) at that time in your client.

You want to avoid flashing, blanking, and repaints--but if for some reason a long refresh period will be needed, the user should be given an indication that there is a need to wait and that the program has not just hung in the meantime (a coffee-cup mouse icon is not quite enough).

Case Sensitivity lacking in the Blinky database
The Blinky database is not designed to distinguish case.  Some clients end up showing both a ‘Ravi’ node and a ‘ravi’ node, whereas in the database, the two are actually the same person.  That can happen if one person has logged in and posted as both ‘Ravi’ and ‘ravi’--then the Blogs table has both a row with ‘ravi’ and a row with ‘Ravi’.  When generating the list of users by grabbing the entire table and pulling out the unique names, it's important not just to do a string comparison to see if ‘ravi’ already exists unless you take measures to avoid treating ‘Ravi’ and ‘ravi’ as different users.  The ‘Ravi’ and ‘ravi’ nodes will actually have the same data underneath them because the “select … where UserID = ‘Ravi’” will return the exact same thing as “select … where UserID = ‘ravi’”.   A way to avoid this is to use the “SELECT DISTINCT UserID FROM Blogs” (or maybe Users), which will return a bunch of UserID’s without duplicates.

How many users?
You might want to use something resizable like an ArrayList (from System.Collections) to keep track of users, so it won't crash if the number of users gets very large.

Auto-Refreshing
You probably want to auto-refresh the displayed part of the TreeView (or similar widget) after posting of a Blog or Comment.
 

Visitors: Hit Counter