I’ve just posted a new version of Twitula (here).

The menu options had grown out of control, which simply wasn’t going to work well for Windows Mobile 6.5.

Consequently I’ve removed the “About”, “Followers” (because really, who cares?) and “Auto-refresh” menu items.

If you actually use the auto-refresh feature, don’t install this update (I’m thinking of putting auto-refresh back in but changing where it’s configured from).

I moved the “Log in” action from its own soft key to a menu item under the right-hand menu. The “Update status” option by contrast has been moved to the left-hand soft key and renamed “Tweet”. My reasoning is that most people will only log in once (when they run Twitula for the first time) and then use stored credentials, whereas tweeting is something people do just a little bit more often. If you have multiple accounts you still have the option to log in again, it’s just not as prominent as before.

I’ve also added an option to disable the sliding transitions between forms (just go to “Options” and un-tick “Animate form transitions”).

All this and bug fixes too. Well, mostly bug fixes.

For a couple of years now many people in the Windows Mobile development community (or as I think of us, the Brotherhood Of The Damned) have been eagerly awaiting the arrival of Silverlight Mobile.

I have long been saying that Silverlight is the last best hope for decent UI on Windows Mobile (in other words, something that doesn’t look like Windows 95 on a day when it was washing its hair and actually didn’t mean anyone to see it). Aside from powerful and easy animation and other effects it has a layout system that is ideally suited to the particular challenges of mobile devices (which is why Silverlight 1 was never a starter, since it lacked layout features – that and being limited to crappy JavaScript, of course).

As recently as late last year we were being promised a public preview for the first quarter of this year, but nothing appeared, and as usual in this area no reason that I am aware of was given for the change of plans. We were just told that it wouldn’t be included on Windows Mobile 6.5.

While Microsoft has been busily practising an Apple-esque level of un-communicativeness on this subject some preview versions have found their way into the fortunate hands of chosen partners, and I think it’s the feedback that has squeezed through the NDA filters that is most revealing: there seems to be agreement that what people have got to use has been so slow as to be unusable.

So, my take is that Microsoft, while beavering away improving performance and hopefully adding Silverlight 3 compatibility and even more hopefully local hardware access, have decided that Silverlight will be deployed as standard on Windows Mobile 7, but are unlikely to even offer it for other versions. Since they know very well that on past performance few OEMs if any will offer upgrades to Windows Mobile 7 (at this point I don’t even know if they’ll be possible), they can bank on Windows Mobile 7 appearing on faster devices, possibly all including hardware-accelerated graphics – thereby finally providing the hardware needed to allow the software to perform.

That’s my guess - and frankly, if that’s what it takes, so be it.

Wake me when you’re ready for us. In the meantime I’ll be boning up on the iPhone and Android stuff.

And playing with Silverlight of course, ‘cos it’s as nifty as something very nifty indeed.

 Update: I removed my earlier suggestion about static compilation, since after further thought, while it might be good for the “This is as close as we’ll get to WPF on the device” scenarios, it naturally wouldn’t work with XAPs, breaking compatibility with Silverlight content from the web.(I still think it’d be a good option to have for general Windows Mobile applications).

I know I said several months ago that I had an update for Diarist in the works…I may have mentioned that it was almost finished. That is true.

So what have I been doing all this time?

The truth is that apart from being distracted by other things I’ve been unhappy with my level of support for touch phones – frankly Diarist is way too menu-intensive. I’ve been looking for alternatives to the menus but not satisfied with what I’ve found (I have however dispensed with the tabs – mainly because they look so shitty, although the Windows Mobile 6.5 versions look fine).

So anyway, I plan to release a beta shortly and basically go with what I’ve got for now.

I’ve added Favourites (with the first bit of localisation as well so our American friends won’t be freaked out) and the ability to delete tweets (I initially inadvertently wrote that as “delete twits”. If only).

I’ve also cleaned up a few things and replaced some of the menu text with variations that I personally find less annoying (the word “My” no longer appears, since it reminds me of “My Little Pony”).

Favourites (or Favorites for the aforementioned en-US people – if anybody in Canada’s using Twitula could you contact me and let me know where Canadians stand on the colour/color thing? Thanks) appear as a menu option (yes, another menu option. I’m sorry), and if you open (by tapping their name) the context menu for a tweet by someone other than yourself (I could change that if necessary)  you have the option to “Favourite” or “Unfavourite the tweet. I hate committing the crime of using a noun as a verb (and then deriving another non-existent verb from that one), but I was forced into it by space considerations.
If I get to fancy stuff like owner-drawing the menu items (developers will know what I mean) I might replace that text with icons.

The “Delete” option is similarly available from the context menu.

As usual, provided you’re running Windows Mobile Professional and you have .NET Compact Framework 3.5 installed you can download the latest version from here.

PS. The CAB file this time is much smaller than the previous version, since this time I avoided including things that didn’t need to be included.

(At least I hope it’s fixed – it’s a bit hard to test because they’re an intermittent problem).

Anyway, the change I made should handle images that are larger than the default size.

Thanks to Jeroen for drawing this one to my attention.

PS. The fixed version can be found in the usual location on Skydrive linked to from previous posts.

If you have a Windows Mobile Professional device with .NET Compact Framework 3.5 installed you can get the latest version here.

As you can see from the screen shots above, there is now a context menu that pops up when you select the name of the author of a tweet, with several useful options. Additionally, the status update now includes the option to include an image (using TwitPic and the standard Windows Mobile Picture Picker).

Additionally, tags in tweets are now selectable (selecting a tag initiates a tag search).

Oh, and I fixed some bugs. It’s always best to do that to make way for new, improved bugs.

PS. If you want to follow my own incoherent ramblings (I mean the short version), my Twitter account is http://twitter.com/KevDaly

This one is more substantial: I’ve redesigned all of the dialogs.

If you have a Windows Mobile Professional device (you know, the ones with the touch screens)  and it has the .NET Compact Framework 3.5 installed, you can get it here.

I’m working on similar changes for my mobile blogging application (Diarist).

But right now it’s time to dive into some more ASP.NET MVC stuff. Have fun folks.

(Actually I refreshed the update just now to fix some annoying behaviour that’s been in the status/message dialogs since the beginning)

A few hours ago (last night by my time) I released an update to the .NETCF2 and .NETCF3.5 versions of Twitula, correcting an outdated link on the “About” form (dating back to when I could afford web hosting). I also added a “Done” SoftKey for that form in the latter case.

You can get the downloads here (.NETCF2) or here (.NETCF3.5)

PS. From now on update notices will be posted on http://twitter.com/twitulaapp

Update

I just noticed and posted a fix for a bug that could disrupt scrolling for keyboard users.

En attendant la mise à jour promise de Diarist...

I've updated Twitula to enable you to easily shrink hyperlinks in tweets via TinyUrl. Which is important when every letter counts.
On the status update form just tap-and-hold within the text entry area and the rest should be self-explanatory. If not, there's a brief explanation in the integrated help feature that nobody knows about.

In addition to the default .NETCF 2 (.NET Compact Framework v2.0) version there's now one for .NETCF 3.5 (this one also has some minor threading improvements, noticeable in that menus for the most part don't hang around being annoying once you make a selection. I should've applied that change to the other one as well, but I, um, couldn't be bothered ran out of time). Actually, while working on the 3.5 version I discovered that that version of the framework included a raft of changes to the HttpWebRequest class which for some reason were not particularly compatible with Twitter, so I had to do quite a bit of fiddling to get it to work. And that made me tired.

Anyway, the version for .NETCF2 is available here, and the .NETCF3.5 version can be found here.

PS. The .NET Compact Framework 3.5 Redistributable can be downloaded from Microsoft at this address.

I normally don't like to talk about what I'm going to do (it seems like tempting fate, which I've become something of an expert on), but I'll break that rule/vague guideline now by saying that I am currently working on an updated version of Diarist (my Pocket PC blogging app).
The reason for the advance notice is that I will from time to time be posting utterly meaningless tests posts here, which you should ignore. Because they're um, utterly meaningless. I hope you'll be able to tell the difference (I'd be really embarrassed otherwise for obvious reasons).

The forthcoming release won't be anything particularly exciting: I'm including a fix for a longstanding bug that caused edits to always update the creation date/time of the post - this is going to take quite a lot of testing so I might need some help from anyone who wants to volunteer, since different blog engines handle these things in different ways (I still have nightmares about Community Server and dates).
I really, really wish I could include rich text editing and thereby provide a WYSIWYG formatting experience, but the only real free option is to write interop code that uses undocumented parts of the RichInk API, which is asking for trouble (as in: likely to break in any given new Windows Mobile release).
As a poor alternative I'm including an easily selectable preview option. It's not much I admit, but it's something. I really feel this is one of many areas in Windows Mobile where Microsoft could have used a bit more imagination, but it can't be helped.

The beta version at least will target .NET Compact Framework 3.5, although I might port the bug fixes at least to .NETCF2 when I get time.

If I go to The NZ MSDN home page and click on "NZ Events & Training" I'm taken to a page which has a link at the bottom Meet Your Local Evangelists.

Needless to say I was somewhat surprised by where that link leads. And I thought for Microsoft purposes we were part of Singapore...

This is cool.

Microsoft have released a Beta version of a new service and associated application that enables mobile phones (well, smartphones at least) to read coloured barcodes using their built-in cameras and automatically handle the associated content - at the moment they allow for URLs, vCards, free text and diallers.
You really need to go to the site and check it out to get an idea of what this really is (especially since I'm too tired and lazy to try to explain it).

Currently the Beta is limited to the US (isn't it always @$%!! that way?), but I've been able to use it (although the vCard address and phone number options were obviously inadequate for my location).

Microsoft Tag is currently available for Windows Mobile, iPhone,Blackberry, Symbian S60 and J2ME.

(go to http://gettag.mobi to download a reader for your device)

Anyway, just as a little experiment, here are some I baked earlier:

Download link for the "Diarist" CAB file:

(Only useful for Windows Mobile Professional of course, and once the link opens you have to hunt around a bit to see where the CAB file is...that's a peculiarity of the way SkyDrive handles links)

(I'm just adding a little more gratuitous space here so it won't be too hard to get the next tag without accidentally hitting the previous one)

My vCard:

The cool thing about this is that it effectively adds hyperlinks to the physical world: I hope the Beta pans out and the service is formally extended to the rest of the world, because this is frankly far more interesting than any of the Ozzie In The Sky With Diamonds Cloud offerings Microsoft has been going on and on and on about lately. It's seriously nifty. Also surprisingly fast.

There's currently no developer story - it would be good to be able to integrate this functionality with your own applications, so I hope they add something along those lines sooner or later.

A few days ago I received a message from Jeremy McPeak drawing my attention to a bug in the code I'd previously made available for enabling MetaWeblogAPI integration. In constructing the XmlRPC fault structure for reporting errors I was incorrectly wrapping the <fault> in a <params> element, and this was causing Windows Live Writer to throw a wobbly on receiving an error.

I've corrected both the C# and VB code (which you can find here and here respectively).

Thanks again to Jeremy for the heads up.

One of the pleasing characteristics of the ASP.NET MVC framework in my opinion is that it enables developers to work more or less directly once more with HTML, freeing them from the Web Forms control system. While the latter provides powerful abstractions it has also caused the proverbial carpet to bulge uncomfortably with the amount of complexity that's been swept under it,  and has arguably exacerbated the disconnect between developers and web designers.

   In some cases, as is often the case with frameworks, the abstractions used by ASP.NET Web Forms have had the effect of filtering out useful features in the underlying technology. One of these is the <optgroup> tag. This allows content in HTML selection lists to be organised by labelled groups, as in this example:

In this case a set of city names (incomplete) is grouped by country, adding a level of hierarchy to the list. The optgroup labels themselves
are not selectable, so the behaviour of the list is not affected.
   This feature is not supported by the Web Forms DropDownList and ListBox controls which together map to the HTML <select> element.
So, I was keen to see what could be done with the MVC bits.
There are HTML helpers for DropDownList and ListBox which broadly reflect their Web Forms equivalents, and as far as I can tell they still don't support <optgroup> (I could be wrong, and it wouldn't be the first time - in my defence there's not that much documentation at this stage of the game, and what there is is subject to frequent revision as things evolve).

So what to do? My first thought was that I could simply generate the relevant HTML inline, but when I thought about error handling and a few other things that suddenly didn't look like such a great idea.
So I decided now would be a good time to learn how to write an HtmlHelper.

There's really not a lot to doing this: just write an extension method for HtmlHelper that returns a string, and you're away. Like everything of course it's open to abuse: I'm not too optimistic about everyone being able to resist the innate programmer's urge to Gratuitously Wrap Every Damn Thing In Existence. People will do what people will do, and some people will do it where it makes an unpleasant mess. That's no reason for the rest of us to foreswear useful tools. But I digress.

In writing HtmlHelpers people generally seem to work with a StringBuilder and not much else, but I'm not entirely comfortable with that approach so I use an HtmlTextWriter on top of a StringWriter writing to a StringBuilder...this is possibly (OK, probably) overkill, but I think it slightly lessens the likelihood of introducing malformed tags, so I'm happiest working that way. But I might get over it.

The end result is that with a suitable data source - such as the following:

...I can produce the desired list with this piece of embedded code:

<%=Html.OptionGroupList("locationId",(ViewData["Countries"] as IEnumerable<Country>),
"Name", "Locations", "Name", "Id", "-- Choose a location --", null)%>

If you'd like to play around with the code or mock the unfortunate (or even find out what those parameters actually represent...) you can download the source for the OptionGroupList helper here.

I spotted a bug today in the test for er, relative freshness of posts (basically the bit that was meant to colour posts created within the past 5 days but not today blue was um, not quite right).

You can get the fix here.

This post has been percolating in my head for a while (which is probably useful since I can no longer afford coffee)...I've hesitated to put it down in writing because it will involve the saying the sort of things that never go down well at job interviews, and that incite the CompSci snobs to point their fingers and chortle. Oh well, never mind.

In recent years in our trade (yes boys and girls, that's what it is - get over it) there has been a welcome emphasis on re-using the fruits of accumulated wisdom and experience, and so people are expected to be conversant with design patterns and best practices.

This is a Good Thing, although I loathe the term "Best Practices" because it suggests that what is currently believed to be a good idea in most or many cases (but your mileage may vary) for reasons which should be considered in the context of your actual situation and requirements is actually Incontrovertible Wisdom Bestowed By God From On High. But that is not my issue.

A prime architectural concern is to reduce coupling, and usually for good reason. Strong coupling typically produces barriers to the use of automated unit tests, and also creates maintenance overheads if at some stage it is necessary or desirable to replace a component of the application (such as a remote service or a database engine) with something else.
There is of course a price to pay for reducing coupling, and that price typically comes in the form of more and arguably more complex code, which inevitably imposes an execution cost, may be harder for developers unfamiliar with the chosen abstractions to maintain, and because the surface area of code is increased there are more things that can fail (there may be bugs in the additional code or it may interact with the rest of the system in unexpected and poorly documented ways) - ironically enough, there is also the risk of introducing another type of dependency, since there is no guarantee that any framework you adopt for this purpose will be compatible with future versions of your system software.

Nevertheless it's still worth it. Generally. But...

An assumption behind much of today's design philosophy is that developer time is more expensive than machine time - in other words, time spent on code maintenance is seen as a major expense to be avoided if possible by doing additional work at runtime.
This makes sense for large applications, but is it valid for small ones? I know some people will say "but you're not allowing for scalability" - newsflash: not all applications need to be scalable.
And what nobody ever mentions is that below a certain size and level of complexity, maintenance effort is actually pretty trivial. It doesn't take very long, so it's not going to cost you a lot of money. If it's not possible to automate your entire test cycle, remember that testing can still be done by actual human beings. We're talking simple application here after all - this is honestly not rocket science folks.

So when someone tells me that it is always better to add additional abstraction layers that execute additional code every time the application is run in order to cater for an eventuality that may never occur (and wouldn't be the end of the world if it did), I have  a hard time believing they are not just parroting something they've been taught rather than speaking from real understanding.

So my advice to anyone who's interested is to evaluate each case on its merits, and most importantly to think.

Now having successfully trashed any remaining shreds of professional credibility I may have had, I think I'll go and compose a sonnet :-)

Within a few days my web hosting will expire, which is why I've started posting here on the sadly search engine-invisible Windows Live Spaces.

Once I'm back in permanent employment and my financial situation has improved sufficiently I'll be looking to establish an online presence once more. Given the crappy times I want to avoid unnecessary expense, so I'm going to be looking carefully at my database options.
The choice (where there is one) always seems to be between MySql and some flavour of the full Sql Server.

So my question for anyone who chooses to answer is this: is anybody offering ASP.NET 3.5 SP1 hosting with SQL Server (2005/2008) Express as an option?

If you know of anybody who is I'd appreciate hearing about it.

I've done some more work on the feed reader I wrote recently (it gets its data from the Common Feed List, so you need IE7 installed).

Previously, it wasn't listening to feed events raised outside the program (such as a feed being added or removed from IE, for instance), so I've fixed that.
The display of the selected item now includes the title and a link - if you click on the link it will open the page in your default browser. You can also right click and select the option to copy the link to the clipboard.

There is now an option from the feed list context menu to read the titles of all unread items in a feed (using the speech synthesiser - if no voices are installed it should do nothing).
From the same context menu you can also mark all unread items as read.

I've tried to make the display of unread items less obtrusive and naggy - so while a feed that has unread items posted on the current day will  have its title displayed in green text, feeds which only have older unread items will only be displayed in blue text if there is at least one less than 5 days old, otherwise the default black text colour will be used.

You can go here to download the installation file.

Note: In addition to IE7 (for the Common Feed List) you need to have .NET 3.5 SP1 installed.

(Originally posted on www.kevdaly.co.nz)

This is something I've been meaning to blog about for a while now, but a few distractions intervened before I got around to it.
But all things come to those who don't get out of the way soon enough, so here it is.

I'm personally a big fan of the AJAX Control Toolkit for ASP.NET AJAX, and in particular the calendar control: it meets a common need, the server-based ASP.NET calendar control has severe usability issues in many circumstances (and I've spent many painful hours writing server controls for the same purpose myself), and overall I find the AJAX version to be convenient, friendly and generally nifty. Additionally, the fact that it is implemented as an extender for the ASP.NET TextBox server control means that it is very easy to use the standard ASP.NET validators with it.

   Following the release of .NET 3.5 SP1 I made a point of checking out the new ASP.NET Dynamic Data feature: while cynics might regard it as the next step in drag-and-drop programming (and if used foolishly it could be), I think it has a lot of potential for many common uses. There are many applications where you just need to get some pages up as soon as possible to handle basic CRUD operations, and Dynamic Data projects fit that purpose very well. In particular they meet a need that is often overlooked when gathering requirements in certain environments, because the user never asks for it: providing an administration interface for your data. Dynamic Data lets you get up and running very quickly, which for much of the kind of drudge work internal web application programming that many developers have to spend their time on could be a life saver. It also fits my philosophy that some of the best code is the code that you don't have to write (you'll note that I'm using lots of qualifiers and weasel words here: it's because experience has taught me that the answer to most questions is "It depends").

So while I don't see myself using a Dynamic Data project for a complex web site (although maybe for part of one), it definitely has its place.
The skeleton code for Dynamic Data is AJAX-friendly, so it's natural that when you come to customise or go beyond the default layout and markup you may consider using some of the AJAX Control Toolkit controls. The calendar control is an obvious choice.
And here's where we encounter an "oops" moment:

This occurs whether you're editing in place or using a details page for the purpose.

When you create a Dynamic Data project you get a default CSS stylesheet, and while you can and almost certainly will (not to mention probably should) customise this, doing so is a non-trivial task where it's best to proceed with a degree of caution. There are better ways of spending a day than fiddling with CSS selectors and then retesting in a zillion browsers. The problem here is that the default styles define margins and grid lines in such a ways as to play havoc with the appearance of the calendar control: you get grid lines you probably don't want, and more seriously there is only room to display 4 days. Not wonderful.
What's even less wonderful is that in this particular case, any explicit CSS class you create for the calendar will be cheerfully ignored.

I spent several (happy?) hours struggling with this problem to no avail - I wanted a solution that was very specific to the calendar control (I'm a big believer in the Law Of Unintended Consequences, and avoiding it wherever possible), but to solve the problem I had to go in the other direction and create a global style for "a cell of a table that's nested within another table cell":

It's not pretty, but it does the job, and somewhat to my surprise does so without screwing up anything else.
The end result is what I was hoping to see in the first place:

So, that's a solution, although I have to admit that it leaves me with a sense of unease and vague foreboding...so if you know of a better one, let me know and I'll post it here.