Subscribe: IanG on Tap
Added By: Feedage Forager Feedage Grade B rated
Language: English
agenda view  app  appointments  apps  data  day  group  grouping  items  listview  phone  time  view  windows phone  windows 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: IanG on Tap

IanG on Tap

Ian Griffiths in Weblog Form

Last Build Date: Thu, 14 Aug 2014 07:20:00 GMT

Copyright: (C) 2004 I D Griffiths

Incremental Loading for Grouped Lists

Thu, 14 Aug 2014 07:20:00 GMT

This is the fifth article in my series exploring some of the technical challenges I encountered while writing my Agenda View Windows Phone app. This is the final entry about grouped data in the ListView control, but there will be more on other aspects of the app.As with most of this series, the techniques here are not limited to phone apps. They will work in Windows Store apps of any kind—Windows Phone, ordinary Windows, or Universal.My app presents appointments in the user’s calendar as a scrolling list, and this list could be extremely long—if you want to, you can scroll years into your future appointments, if your diary is populated that far. This sort of ‘infinite scroll’ is popular in mobile apps, so it’s not surprising that the ListView control has support for exactly this sort of usage, enabling you to fetch data gradually, rather than attempting to load it all up front.If a data source implements both ISupportIncrementalLoading, and INotifyCollectionChanged, the ListView will use the source’s HasMoreItems property to discover whether there is more as-yet-unfetched data, and if so, it will call LoadMoreItemsAsync to ask the source to fetch it. It only uses these members when the user scrolls, meaning that you only load data when it is needed. The source raises collection change notifications in the usual way to indicate when it has fetched new data.Unfortunately, this doesn’t work if you use the grouping features of ListView. It will simply ignore a source’s ISupportIncrementalLoading implementation when operating in grouped mode. Now as you saw in the previous blog, my app doesn’t actually use grouping—in the end I found it necessary to flatten the data completely to avoid some problems. However, I am hoping that the problem in question is in fact a bug in the ListView, and that one day I’ll be able to go back to using grouped data (because it would bring back the sticky headers), and in any case, I had already solved the incremental loading problem before I discovered that I wasn’t going to be able to use the ListView in grouped mode.Roll Your Own Incremental LoadingFortunately, it’s not particularly hard to implement incremental loading yourself. The basic requirement is to discover when items scroll into view. You can use this information to ensure that you always have at least some minimum number of data items ahead of that point pre-loaded, ready to scroll into view. If the number of loaded-but-not-yet-seen items drops below some threshold, you load some more.So how do you discover when an item has scrolled into view? I use an extremely low-tech approach: I wait for data binding to read one of the bound properties of a view model. Here is a slightly simplified version of one of the view models from my app:public class AgendaDayGroupViewModel : ObservableCollection {     private readonly string _dayText;     private Action _onFirstView;     public AgendaDayGroupViewModel( DateTime date, Action onFirstView)     { Date = date; _onFirstView = onFirstView; _dayText = date == DateTime.Now.Date   ? TimeAndDateStrings.TodayGroupHeading  : date.ToString("D").ToUpperInvariant();     } public DateTime Date { get; private set; }     public string DayText     {         get         {             Action cb = _onFirstView;             if (cb != null)             {                 _onFirstView = null;                 cb(this);             }             return _dayText;         }     } } I’ve removed the parts that aren’t directly relevant to the example, but the code that handles incremental loading is exactly what the real app uses.This is a view model representing a group—you can see that it derives from a collection clas[...]

Vertical Jiggle in Grouped ListViews

Fri, 25 Jul 2014 14:42:54 GMT

This is the fourth article in my series exploring some of the technical challenges I encountered while writing my Agenda View Windows Phone app. I initially promised four entries on the topic of showing grouped data in the ListView control, but I’ll be adding one more after this. (There are more to come on other aspects of the app though—I’ve got another six planned.)Most of the articles in this series are applicable to both Windows and Windows Phone store apps, and the examples available for download in this entry are Universal apps. However, in this article I show how to work around a problem that only occurs on Windows Phone. The code works perfectly well in Universal apps with the workaround in place, but is not actually necessary if you’re only targeting Windows.As my first blog entry in this series described, my app needs two levels of grouping: appointments are grouped by time, and then by day. That was tricky because the ListView supports just one level of grouping, but in the second and third articles, I showed what appears to be a satisfactory way to handle this: provide the ListView with a single level of grouping (by day) and use different item types to represent time headers and appointments within that. (Likewise, in the address-based example I’ve been using, we provide data grouped by country, and each group contains a mixture of elements representing town headers and addresses.)However, there are two unresolved problems. First, there’s some occasional horizontal jiggling. That’s not a grouping issue—you can get the same issue with a flat list. As a quick fix for now, I’ll just set fixed widths on all the templates. This makes the problem go away but it’s not an ideal solution; I’ll show how to fix it properly in a later article. The second problem is that the approach I’ve shown so far only works if all your items are the same height. And since the nested group headers are just items as far as the ListView is concerned, this means your nested group headers must be the same height as your items.To show what happens if the heights differ, I can add the following attribute to the TownGroup header from the final example from last time:Margin="0,20,0,0" Here’s a copy of the solution with this change for download. The following two screenshots show the original version, and then the version with the additional vertical margin for the town groups: This makes it easier to see the group structure at a glance. My real app needs this sort of spacing to reproduce the look of the old app on which it is based.Unfortunately, if you run this app on a phone, you’ll see a problem if you scroll down a few pages through the list, and then back up again. Although it looks fine when moving forward through the data, as you come back up again the sticky group title at the top of the page jiggles around vertically. (The Windows app doesn’t have this problem, because it doesn’t seem to support the sticky group headers. These only seem to be available for Windows Phone apps.)This is a different issue from the horizontal jiggling I’ve mentioned before. That looks different, and it doesn’t occur in this particular example because I’ve applied a fixed width to every data template. (It’s superficially similar—both horizontal and vertical jiggle can be eliminated with fixed-size data templates. But the vertical jiggle seems only to occur with grouped data.)As far as I can tell, this is a limitation of the phone ListView—you cannot use mixed-height items in conjunction with grouping, because you’ll end up with a vertically jiggling sticky group header. And as far as I can tell, you can’t even disable the sticky group header to avoid the problem. If you want mixed item heights in a ListView, you cannot use it in grouped mode. So that’s how I eventually came to the solution I used in my app.Completely Flattened GroupsBecause I want to have mixed item heights, I cannot use even the single-level group support offered by the ListView. So I need to take the same tric[...]

Mixed ListView Item Templates for Store Apps

Fri, 18 Jul 2014 16:51:15 GMT

This is the third article in a series describing how to solve a variety of problems I encountered while writing a real store app.Although the app in question (Agenda View) is a phone app, everything in this article (and almost everything in the series) also applies to Universal apps and Windows store apps. In fact, I’ve built all the examples in this entry as Universal apps so that you can try them out either as Windows or Windows Phone apps.Last time, I showed how to present groups nested within groups despite the fact that ListView supports only a single level of grouping. The trick was to use a mixture of item types, with a distinct type for items representing list headers. Each day group is a collection containing these header items interleaved with the actual appointment items, as illustrated by this annotated screenshot:The challenge at the end of the previous article was how to display the different item types in different ways. In my simple example, both kinds of items displayed a single string, and I added some properties to my source objects to modify aspects of the appearance. This technique would not work easily in my app—as you can see from that screenshot, time headers have a completely different appearance from appointments.What I really want is to be able to express the appearance completely in XAML. Microsoft’s other XAML frameworks have a built in solution to this: you can associate data templates with types, meaning that list controls will automatically pick item templates based on the item type. (WPF has always had this. Silverlight was rather late to the party—it took five versions, but we got it eventually.) Unfortunately, XAML store apps (for either Windows or phone) cannot do this. This is presumably partly down to the fact that WinRT is not based on .NET, so there isn’t a single definition of what constitutes a ‘type’ in XAML for store apps.You need to roll your own solution. I came up with a few possible techniques for doing this. I’ll describe them all, finishing with the one I eventually used in my app.Binding to Visibility PropertiesMy app only has two kinds of items in a day group: time group headings and appointments. (Actually, as you’ll see later, my real app eventually ended up with three. But the point is that it’s a small number.) So one way of enabling different visuals for different item types is to define properties of type Visibility on your source objects.For example, in the address-based example I’m using in this series, I could modify the TownGroup to look like this:public class TownGroup {     public string Town { get; set; }     public Visibility ItemVisibility { get { return Visibility.Collapsed; } }     public Visibility GroupHeaderVisibility { get { return Visibility.Visible; } } } I can add a similar pair of properties to the individual item type, SourceData, with the values reversed:public Visibility ItemVisibility { get { return Visibility.Visible; } } public Visibility GroupHeaderVisibility { get { return Visibility.Collapsed; } } With these properties in place, my item template contains content for both kinds of item, and uses the properties to ensure that only the part required is shown:                             This works pretty well, and is visually indistinguishable from the final example in the previous article:You can download a solution containing a universal app illustrating this technique in use on both Windows Phone and Windows from here.The [...]

Flattening Groups for ListView

Thu, 17 Jul 2014 16:09:05 GMT

This is the second article in a series exploring some of the technical challenges I encountered while writing my Agenda View Windows Phone app. Last time, I described the grouping features built into the ListView control available to store apps. (My example was a Windows Phone app, but it also applies to Windows 8 apps and Universal apps that run on both phones and tablets.) This built-in functionality wasn’t quite sufficient, because it only works for a single level of grouping, and things go wrong if you try to work around this by nesting some sort of ItemsControl in each item.It took a couple of iterations to arrive at the solution the app eventually used. This article describes the first attempt. As you’ll see in the fourth article in this series, I ended up needing to refine it a little further, although the same basic idea described in this article still applies.The solution was to avoid using multiple levels of grouping. Now that may not sound like much of a solution, given that nested groups are a non-negotiable requirement. However, all my app really needed was to provide the appearance of multiple levels of grouping. So although the app needs to reflect the logical structure I showed in the previous blog:the user will be none the wiser if we implement it with this simpler structure.As with last time, the dotted boxes are just annotations I’ve added to a screenshot to illustrate how the areas on screen correspond to objects in the application. Now, we’ve only got one level of grouping—as before there’s a group for each day, but as well as containing items representing time groups, this also contains the individual list items directly.So although the time groups are present, the ListView does not seem them as groups at all—they’re items just like the ones representing the appointments themselves.The big change here is that my outer group objects must now provide a heterogeneous list of children. In the context of the town and country examples I used last time, instead of my root collection being a collection of groups, with its definition starting like this:public class CountryGroup : ObservableCollection or being a collection of the underlying items, as I had with my original single-level data:public class CountryGroup : ObservableCollection it now needs to be a collection where each item can represent either a town group or an item within a town group. There are a couple of ways to do this. One would be to introduce a new class called something like TownOrGroup (or, if you prefer, ItemViewModel, to make it clear that it’s a type whose purpose is to represent items in the list). The other option is to make the group class derive from ObservableCollection. (Sadly, the CLR doesn’t support additive types, so there’s no native way to represent ‘either a TownGroup or a SourceData’ but that’s what we mean.)I’ll go with the latter for now. So my country group looks like this:public class CountryGroup : ObservableCollection {     public CountryGroup(IEnumerable items)         : base(items)     {     }     public string Country { get; set; } } My town group is no longer responsible for actually containing the items—it just acts as a header that sits in front of the group. So it now looks like this:public class TownGroup {     public string Town { get; set; } } The SourceData class representing individual items remains unchanged.The code to build the data into what look like groups now looks a little different. For each country, we need to generate a single list which contains, for each town group, an item representing the town, and then all the items in that town. No matter how many towns groups there are, we want a single list, so the list might go TownGroup, SourceData, SourceData, TownGroup, SourceData, etc.While it would be possible to build one big hairy LINQ query to m[...]

Windows Phone ListView and Grouping

Tue, 15 Jul 2014 16:09:53 GMT

This is the first article a series exploring some of the technical challenges I encountered while writing my Agenda View Windows Phone app. My first topic is multi-level grouping. Surprisingly, doing this well turns out to be sufficiently hard that I’ll be writing four articles on it!Note that although I'm discussing a phone app, most of the content in these articles is applicable to Windows 8 store apps and Universal apps.In this first article, I’ll show the ListView control’s built-in grouping features, and explain why they’re not quite sufficient for this app. I’ll also show an alternative approach that enabled multi-level grouping with very little work, but which turned out to have problems when applied to real data. In later articles I’ll explain what I ended up doing instead.The App’s Grouping RequirementsThe app displays appointments grouped by both time and day. If you happen to have conflicting appointments that start at the same time, these will come under a single heading showing that time. And at a wide scale, all of the day’s appointments are grouped under a heading showing either the text TODAY, or the relevant date if the appointment is further out. I’ve annotated a screenshot to show precisely how grouping occurs:I’ve outlined individual items in red. These are grouped by start time, as shown with the green outlines. And those time groups are in turn grouped by day, shown here with a blue outline. I’ve also shown the same hierarchy in a sort of treeview-like structure to the side.Most items have a distinct start time—people usually try to avoid scheduling multiple simultaneous appointments, so you’d normally expect each time group to contain exactly one item. But sometimes collisions occur, and in this case, you can see I’ve got two items in the time group for 6:30pm near the top. That’s why I need an additional level of grouping within the day groups.This logical structure was non-negotiable, because this is how the Calendar app used to show things (up until the Windows Phone 8.1 update removed the agenda view) and the entire point of my app was to provide something as close as possible to the original feature. However, this turns out not to be totally straightforward, because the ListView control available in store apps does not support multi-level grouping. (I can only assume that the original Calendar app didn’t use XAML.)ListView’s Built-In GroupingAll of Microsoft’s XAML frameworks support grouping, but the way this works has changed with the introduction of WinRT (or ‘store apps’ to use Microsoft’s current name for apps that use this API), first for Windows 8, and now for Windows Phone 8.1. With all the other versions of XAML, you would enable grouping with something like this:                             In pre-WinRT XAML, your data source supplied a flat list of items, and you asked the CollectionViewSource to gather it into groups for you, according to one or more grouping criteria. The example above states that items should be grouped by the value of their Country property, and then within each country group, items should be grouped by the value of a Town property. (By the way, the Windows Phone version of Silverlight doesn’t support this properly. It accepts the XAML above, but it appears to ignore everything after the first level.)But if you use WinRT (because either you’re writing a Universal app that targets both tablets and phones, or you’re writing a Windows 8 store app, or you’re writing a phone-only app and have chosen to use the ‘store app’ template instead of the Silverlight one) things are different. Data binding will not gro[...]

Agenda View for Windows Phone 8.1

Wed, 09 Jul 2014 08:33:39 GMT

I’ve written an app for Windows Phone 8.1 called Agenda View. It puts back a feature that was built into earlier versions of Windows Phone, but which went missing in the 8.1 update.Calendar App Before 8.1When I first installed a public preview of Windows Phone 8.1, I noticed some striking changes to the built-in Calendar app. For the most part, it’s an improvement—in addition to the old day and month views, we get two new views: year, and, most usefully, week. However, we lost something: the old agenda view.The agenda view, present up to Windows Phone 8.0, but not beyond that, presents all your upcoming appointments in a simple list:I much prefer this to the day view, because the day view makes it too easy to miss things. It can only show 8 hours at once, or less if you have a few all-day appointments. (Those sit at the top, reducing the space available for the rest of the day.) So if you have appointments early in the morning and also some in the evening, you can’t see them all at once. It’s really easy to look at the day view and think you’ve got nothing on for the day:In fact I’ve got a few appointments for that day in the morning, late afternoon, and evening. There’s no way to see that at a glance—I have to scroll up and down to look for early or late appointments.The agenda view doesn’t have this problem, because it shows all your appointments in order with no gaps—it makes no attempt to space items out according to the time between them. So on days such as the one shown above where I’ve got morning and evening appointments and nothing in the middle, I can see the whole day at a glance:Sadly, the Windows Phone 8.1 update removes this useful view.Windows Phone 8.1 CalendarWindows Phone 8.1’s new week view goes some way to making up for the loss of the old agenda view: it shows as many appointments for each day as it can fit, and like the old agenda view, it shows them in a simple list, rather than spacing them according to time of day like the day view. The problem is that by fitting an entire week onto the screen, it doesn’t take many appointments before they don’t fit. You can tap on a day to expand it, but this only makes a little more space:You can scroll through the items of course, but because the list is so small, this is more fiddly than with the old agenda view, and in any case, it’s a much less convenient way to see everything you’ve got coming up for the day than a straightforward list filling the screen.Putting the Agenda View BackBecause the agenda view was my preferred way to look at my calendar, I decided to write an app that works in the same way. It’s not identical—for one thing, it only supports this one mode. (You can use the built-in calendar app if you want the other views.) This removes the need for navigation chrome at the top, making the entire screen available for your appointments:This means you can see even more of your appointments at a glance.You can find the app in the Windows Phone store at and there’s also a simple site for the app at (Thanks to Felix at for the design work on that site.)Some aspects of this apparently simple app were surprisingly technically challenging. (E.g., getting groups within groups to work, when the ListView supports only a single level of grouping; updating a collection of view models from a source in which items may randomly appear or disappear without disrupting the scroll position, or scroll animations in progress.) So over the next week or two, I’ll be posting blog entries on various technical details of the app.[...]

Windows Phone 8.1 and MSB3774 Errors

Wed, 23 Apr 2014 09:53:25 GMT

During this year’s Build conference, Microsoft released a release candidate of update 2 for Visual Studio 2013, which enables you to build Windows Phone 8.1 apps (amongst other things). However, you may find that if you create a Unit Test project for a Windows Phone 8.1 Store App (i.e., using the new WinRT-based API) you get the following build errors:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1864,5): error MSB3774: Could not find SDK "MSTestFramework, Version=12.0".

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1864,5): error MSB3774: Could not find SDK "TestPlatform, Version=12.0".

This happens if you did not install the Windows Phone 8.0 tools when installing Visual Studio 2013. Apparently, the Windows Phone 8.1 unit test features in Update 2 rely on these 8.0 components, and the Update 2 RC installer will not install them for you if they are missing. If you’re in this situation, Visual Studio (with update 2) still offers a ‘Unit Test App (Windows Phone)’ project template under 'Visual C# -> Store Apps -> Windows Phone Apps' in the Add New Project dialog, but sadly, that template will produce the errors shown above when built.

Fortunately, this is easily fixed. If you re-run the original Visual Studio 2013 installer (not the update installer, but the one you used to install Visual Studio 2013 in the first place) it will detect that VS is already installed, and it offers a “Modify” button. If you click that, it will let you check the box for the Windows Phone 8.0 tools.

Once you’ve got the 8.0 tools installed, WinRT-based (‘Store’) unit test apps for Windows Phone 8.1 will no longer produce these errors.

Recursion Schemes and Functors

Thu, 20 Mar 2014 08:47:29 GMT

Erik Meijer recently tweeted a link to Patrick Thomson’s post on recursion schemes. (Erik was the driving force behind two of my favourite technologies of the last decade: LINQ and Rx. If you’re interested in programming languages, he’s well worth following on Twitter: @headinthebox.) It was an interesting article, but I felt it had a small issue: it conflates a very useful idea (recursion schemes) with some related but not strictly necessary Haskell-isms: the Functor type class, and fixed points of recursive-defined parameterised types.I only dabble in Haskell, so it’s possible I’ve got this wrong. I was going to contact the article’s author (Patrick Thomson) directly for clarification, but couldn’t find his email details, so I decided to post this publicly, with the hope of drawing his attention to it via Twitter. I may yet be embarrassed if he points out a fatal flaw in my argument. Ah well.Recursion SchemesThe idea at the heart of Patrick’s post seems to be this: we should separate the mechanisms for traversing data structures from the way in which we would like to process the data. His example is a data structure representing a simple syntax tree, and a ‘flatten’ method which walks through an expression tree removing parentheses. Initially, this flattening logic is intermingled with the code that walks the tree:flatten :: Expr -> Expr flatten (Literal i) = Literal i flatten (Paren e) = flatten e flatten (Index e i) = Index (flatten e) (flatten i) flatten (Call e args) = Call (flatten e) (map flatten args) flatten (Unary op arg) = Unary op (flatten arg) flatten (Binary l op r) = Binary (flatten l) op (flatten r) There’s only one line of interest here, and it’s the version of the function that takes a Paren expression. The rest is essentially boilerplate that describes how to walk through his syntax tree data type.By the end, he has two functions, topDown and bottomUp, which encapsulate two styles of tree traversal. This enables him to separate out the actual logic—flattening of parentheses—into a much simpler function:flattenTerm :: Term Expr -> Term Expr flattenTerm (In (Paren e)) = e -- remove all Parens flattenTerm other = other -- do nothing otherwise It’s very much easier to understand what this does (strips out parentheses, leaving everything else in place) than it was with the previous example, because it expresses only the important logic. To use it, we combine it with one of Patrick’s traversal functions:flatten :: Term Expr -> Term Expr flatten = bottomUp flattenTerm This walks the syntax tree in a bottom-up fashion, passing each node through that flattenTerm function.Clever StuffThere are a couple of particularly clever aspects to the way Patrick achieves this. First, his topDown and bottomUp functions don’t know anything about his specific data type. They could work for any recursive data type. Second, he takes advantage of the Haskell compiler’s ability to generate code that can traverse a recursive data type for you; not only can you separate all the structural boilerplate I showed in the first example from the important logic, you don’t even have to write any of that code yourself.He then goes on to do one more very clever thing: he recursively constructs a parameterised data type which is, in a sense, infinite. This is an excellent party trick, but it is also where I part company from Patrick a little. My view is that the only reason he needs this clever trick is because he’s been forced into it by a shortcoming of how the compiler generates traversal code. An ideal solution would, in my view, enable you to avoid this. But he seems to regard it as front and centre, rather than an unfortunate workaround:“That these definitions emerged naturally out of fixed-points and functors, two concepts central to Haskell and to functional programming i[...]

When to Stockpile Computer Parts?

Fri, 17 Jan 2014 08:17:48 GMT

This is the end of the golden age for those of us who like to buy computers.It’s all Apple’s fault. A significant force at the start of the personal computing revolution, Apple is now instrumental in its destruction. Thanks to the path beaten by the iPhone and iPad, the computer industry now understands how to make phones and tablets that do most of the jobs for which individuals used to buy a computer. This development of ‘just barely good enough’ tablets and phones has meant that demand for new PCs is falling drastically.This has some negative consequences. Those of us who need (or merely want) a proper computer are going to find that it looks increasingly less like a commodity, and more like an exotic piece of specialist kit. In other words: PCs will get much more expensive. (Falling demand leading to higher prices may seem to contradict some conventional economic ideas, but this is an industry that relies heavily on economies of scale.) This will come as a nasty shock after several decades of decreasing prices and increasing performance.And just in case it’s not obvious, ‘PC’ includes Macs here. Around a decade has passed since Apple last created Macs with truly original technical designs. The economic logic of building around commodity PC components was inescapable. In 2006 I bought two new laptops, one Mac and one PC, and out of curiosity, I did a little investigation. I enumerated all of the internal components making up each system. The Mac looked much fancier on the outside, but its innards turned out to be very nearly identical to my Dell’s. Apple instead specialised in areas where they could still charge a premium: physical design, the usability of their software, and things that aren’t PCs. Their profits illustrate the wisdom of this strategy.The fact that Macs use commodity PC components (albeit mounted on Apple-designed circuit boards in beautiful boxes) means that the collapse of the PC market will raise Mac prices too.Price hikes for personal computers of all kinds are inevitable because it just won’t be economically viable for parts suppliers to produce the necessary components at the scale that has historically enabled them to become so cheap.It’s Happening NowIf you’re wondering how soon this will be upon us, be aware that Intel has recently decided not to complete a massive new chip factory despite having done most of the building work. Weak demand means that even though they’ve put a lot of money into this site, it’s just not worth the remaining investment it would take to bring the plant online.If you were thinking of buying or building a new computer in the next couple of years, that factory may well be where its most important components would have been built. But not now.It’s Not Happening All at OnceIn some ways, the change will seem gradual. For one thing, PC components have a surprisingly long life, because today’s high-end parts often become tomorrow’s cheap bits. Designs remain on the market in various guises for much longer than you might guess from the inflated rhetoric about how fast things move in the computing industry. But if you build your own systems, you will probably see it sooner rather than later.Some things will remain cheap for a good while. Anything needed in either a phone or a tablet will continue to be worth manufacturing in high volume. For example, graphics processors just capable enough to drive a full-size tablet panel with retina resolution will be a mass market component for a long time yet. And there’s not going to be any shortage of cheap ARM-based system-on-a-chip components either. This suggests that laptops will be affordable for a good while, because there will be a cheap way to make them: bolt a keyboard to a tablet. (Although quite what will happen to Intel’s venerable processor architecture in this new worl[...]

Ten Years

Tue, 07 Jan 2014 16:15:16 GMT

This blog has been running for ten years as of today!I’m only counting elapsed time, of course. It ground to a halt a couple of years ago—there are no entries for 2012! In my defence, my first child was born around that time, and I also moved house twice. Oh, and I wrote a book—a complete rewrite of Programming C#.(Apparently I didn’t get around to blogging about the book! Oops. Well better late than never. If you happen never to have looked at it, it’s a very different animal from the previous editions of that title. I wrote the book I would want to read, so it’s a book for people who already know how to program, and are looking for a lot of in-depth information.)Anyway, even though I can’t claim 10 years of continuous blogging—it’s more like about 8.5 years spread across a 10 year interval—I didn’t want to let this anniversary go completely unmarked. So here are some random thoughts inspired by this decimal milestone.Homebrew Blog EngineThe code that serves up this blog may have enjoyed greater longevity than anything else I’ve written. (I could be wrong—I worked on various embedded systems in the 1990s and early 2000s which might, for all I know, still be going. But it’s certainly the longest running software for which I’ve been responsible over its entire lifetime. I may even add support for comments any decade now.) I wrote it back at the end of 2003, partly as a way of learning about ASP.NET, and partly because I was deeply unsatisfied with the URL handling that most blog engines of the time offered.I’ve been using the code I wrote back then with only minor modification ever since. It has moved servers a couple of times—initially it was on a shared ASP.NET host, then on a dedicated Windows 2003 server up until last year (!) when I finally moved it over to Azure. There were a couple of minor modifications to upgrade from .NET 1.1 to 2.0, and then to 4.5, but not much else has changed.Loose EndsI’ve just been browsing through the archive. (You can see entire years at a time by cropping URLs by the way, e.g. etc.) I realise I never answered the question I posed in so, better late than never: this was an attempt to render something similar to Adobe illustrator gradient meshes as a triangle mesh in DirectX (with wireframe mode enabled so I could inspect it more closely). At the time I was frustrated by the relatively small repertoire of gradient fill types in WPF (or Avalon as it was called back then). Mind you, more recent versions of XAML have seen fit to reduce the options further still!Foolish PredictionsI notice that in 2004 I was rash enough to make a prediction. In I referred to Craig Andera’s prediction (a year or so before Herb Sutter’s The Free Lunch Is Over article) that the exponential speed increases we’d hitherto enjoyed in computing would shortly be ending. He got that right. With the exception of highly parallelizable work (e.g. video encoding) that can exploit all your cores (8, on my current machines), the speed increase with each new computer purchase has been marginal since that time. Up to around 2003/2004, each new computer was around twice as fast as its predecessor, and you felt a profound difference every time. But these days, a new machine feels like a very minor upgrade. (Strangely, the popular press still hasn’t noticed this. I still see frequent references to exponential speedups, particularly in the context of predicted ‘singularities’ in which AI becomes intelligent enough to build better AIs, and the machines take over. The fact that computers settled into the S-shaped fate of all techn[...]