5 Steps to Faster Mobile Web App Development

New Brunswick start-up Agora Mobile has developed a revolutionary platform for the visual development of mobile web applications.

As we move closer to launch, we are beginning a private beta targeting developers (and other forward-thinking sorts). To kick off this beta, we are beginning a series of webinars which introduce the platform and concepts. The first webinar is this Thursday (June 26).

Register for the webinar at http://developers.vizwik.com – and as a bonus you will become part of the private beta!

Microsoft: Get Your Shit Together on Touch Development

Testing Samples from Microsoft Surface Toolkit...

Image by John Bristowe via Flickr

I have been playing with multi-touch development for a while, both on Windows 7 with my 2740p and on the Microsoft Surface table (version 1, not the new one).

I have consistently had challenges using WPF4 multi-touch events on the 2740p, or using the Microsoft Surface Toolkit for Windows Touch Beta, and now with the newly released Surface 2 SDK.

With any of these tools, I have challenges getting the software to recognize touch events, and even more trouble getting the software to recognize 2 simultaneous touch points (the 2740p supports 2 touch points). A second touch point always cancels the first touch point.

What is funny (to me, anyway) is that the samples included with the machine in the Microsoft Touch Pack for Windows 7 work just fine on the 2740p. This indicates that it is something in the managed drivers used with WPF that is not working.

I am fairly certain that this is a driver issue. I had it working at one point after a lot of hacking and installing drivers different from the default updates. I guess an update somewhere (Windows Update, or HP Tools) has overwritten the driver I had setup to make it work.

Can I fix the drivers to make this work again? Absolutely! But that is not the point here.

This should just work!

How am I as a software developer, or as an ISV, supposed to recommend this platform to my customers, or build applications for it, when even getting it to run on different machines requires significant hacking of drivers?

If Microsoft wants to stop being seen as a joke in the multi-touch and/or tablet market, they really better find a way to get their shit together on this.

Displaying an XPS Document on the Microsoft Surface

As a part of an application I am prototyping, I ran into the need recently to display a document inside a ScatterViewItem on the the Microsoft Surface. Since there is (intentionally) no built-in way to display HTML content on the Surface, and displaying a Word document did not seem feasible, I settled on using an XML document, and using the WPF DocumentViewer control.

This seems pretty easy, right? Just put a DocumentViewer inside your ScatterViewItem, load the document into the DocumentViewer, and you’re done. Couldn’t be easier.

Well, displaying the XML document was indeed that easy. Unfortunately, as I expected, the DocumentViewer would not respond to touch at all. I posted a question to the MSDN Surface forums about this, and did not receive any response for several weeks.   The response I finally did receive was that I would have to develop a User Control, and handle the touch events myself.

Not being one to take advice, I decided to try another approach – I decided to see if I could hack the ControlTemplate for the DocumentViewer in such a way as to have it support touch (keep in mind that I am a relative noob when it comes to all of this WPF/Styles/ControlTemplate stuff).

So I created a simple Surface project in VS2008, and modified the SurfaceWindow1.xaml file to have a ScatterView control, containing a single DocumentViewer control, as shown below:

<s:SurfaceWindow x:Class="SurfaceDocumentViewer.SurfaceWindow1"
    xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation
    xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml
    xmlns:s=http://schemas.microsoft.com/surface/2008
    Title="SurfaceDocumentViewer" Loaded="SurfaceWindow_Loaded">
  <s:SurfaceWindow.Resources>
    <ImageBrush x:Key="WindowBackground" Stretch="None" Opacity="0.6" ImageSource="pack://application:,,,/Resources/WindowBackground.jpg"/>
  </s:SurfaceWindow.Resources>
    <s:ScatterView Background="{StaticResource WindowBackground}" >
        <DocumentViewer Margin=”15” Height="Auto" Name="docViewer" Width="Auto" />
    </s:ScatterView>
</s:SurfaceWindow>

Note that I added a margin around the DocumentViewer so that there would be something to grab on to in order to resize the ScatterViewItem. 

I then opened the project in Expression Blend so that I could get a copy of the “default” style/template for the DocumentViewer control. Opening the project in Blend, right click on the DocumentViewer, and select Edit Template | Edit a Copy…, as shown

2

Name the style (I used SurfaceDocumentViewerStyle), and define a location for it (I left it in the SurfaceWindow1.xaml file), as shown below.

3

Click OK, then save your changes and close Expression Blend.

Returning to Visual Studio, you will get a message that the project has been changed outside of Visual Studio. Click Reload to load the changes into Visual Studio. Opening SurfaceWindow1.xaml in design view, you should now see a <Style> element under <s:SurfaceWindow.Resources>, and within that, a ControlTemplate for the DocumentViewer. There are several parts to the ControlTemplate:

  • A ContentControl for the toolbar, that loads from an external assembly.
  • A ScrollViewer named PART_ContentHost that is the container for the actual document display
  • A DockPanel that provides background for PART_ContentHost
  • Another ContentControl names PART_FindToolBarHost where the search box is hosted

The only part important to me was the ScrollViewer. I also wanted to get rig of the toolbar and the search box in order to keep things as clean as possible. So I deleted the other parts.

Here then is the key step to making the DocumentViewer touch aware: I replaced the ScrollViewer with s:SurfaceScrollViewer. My new ControlTemplate now looks as shown below:

<Style x:Key="SurfaceDocumentViewerStyle" BasedOn="{x:Null}" TargetType="{x:Type DocumentViewer}">
    <Setter Property="Foreground" Value="{DynamicResource {x:Static SystemColors.WindowTextBrushKey}}"/>
    <Setter Property="Background" Value="{DynamicResource {x:Static SystemColors.ControlBrushKey}}"/>
    <Setter Property="FocusVisualStyle" Value="{x:Null}"/>
    <Setter Property="ContextMenu" Value="{DynamicResource {ComponentResourceKey ResourceId=PUIDocumentViewerContextMenu, TypeInTargetAssembly={x:Type System_Windows_Documents:PresentationUIStyleResources}}}"/>
    <Setter Property="Template">
        <Setter.Value>
            <ControlTemplate TargetType="{x:Type DocumentViewer}">
                <Border Focusable="False" BorderBrush="{TemplateBinding BorderBrush}" BorderThickness="{TemplateBinding BorderThickness}" CornerRadius="5" >
                    <Grid Background="{TemplateBinding Background}" KeyboardNavigation.TabNavigation="Local">
                        <Grid.ColumnDefinitions>
                            <ColumnDefinition Width="*"/>
                        </Grid.ColumnDefinitions>
                        <Grid.RowDefinitions>
                            <RowDefinition Height="Auto"/>
                            <RowDefinition Height="*"/>
                            <RowDefinition Height="Auto"/>
                        </Grid.RowDefinitions>
                        <s:SurfaceScrollViewer HorizontalScrollBarVisibility="Hidden" VerticalScrollBarVisibility="Auto" x:Name="PART_ContentHost" IsTabStop="true" TabIndex="1" Focusable="{TemplateBinding Focusable}" Grid.Column="0" Grid.Row="1" CanContentScroll="true" />
                    </Grid>
                </Border>
            </ControlTemplate>
        </Setter.Value>
    </Setter>
</Style>

Now, to test this, add an XPS document to your project (mine is name test.xps). Add an assembly reference to ReachFramework (XPS package support), and add using statements to SurfaceWindow1.xaml.cs as shown:


using System.IO;
using System.Windows.Xps.Packaging;

Add the following code to the end of the SurfaceWindow1 constructor to load and display the XPS document:


XpsDocument doc = new XpsDocument("test.xps", FileAccess.Read);
docViewer.Document = doc.GetFixedDocumentSequence();
docViewer.FitToWidth();
doc.Close();

Finally, to make the XPS document resize when you resize the ScatterViewItem, Add an event handler to your DocumentViewer to handle the SizeChanged event, as shown below:


private void docViewer_SizeChanged(object sender, SizeChangedEventArgs e)
{
    docViewer.FitToWidth();
}

If everything went according to plan, you should now be able to run your code and you should get a ScatterViewItem displaying your XPS file which is resizable, and which supports touch to navigate around the document.

(I think this should also work with the Surface Toolkit for Windows Touch, but I haven’t tried it yet)

First look at SharePoint 2010 for Developers

The past week has seen quite a bit of new information being published by Microsoft regarding Office 2010 and SharePoint 2010. This is just the start, I am sure, and by the time Office 2010 is released next year, we will probably all be getting sick of hearing about it (jk). A good place to start getting a feel for SharePoint 2010 is to look at SharePoint 2010 Sneak Peek videos recently posted by Microsoft.

I had a look late last week at the new features from a general perspective – see my column over at Legal IT Professionals. In this post I want to have a look at some of the new features for developers. I will give my take on what I saw in the videos, and also mention a few things that I was hoping to see but didn’t.

The Developer Sneak Peek Video covers a number of features of SharePoint 201 for developers:

  • Visual Studio 2010 SharePoint tools
  • Language Integrated Query (LINQ) for SharePoint
  • Developer Dashboard
  • Business Connectivity Services
  • Client Object Model (OM)
  • Silverlight Web Part

The Visual Studio SharePoint tools are intended to improve programmer productivity when developing for SharePoint. A major new feature is the Visual Web Part Designer. As the name implies, this tool lets you visually design your web part UI, rather than coding it or using something like SmartPart. While the demonstration in the video is extremely simple, this tool should greatly improve the process of developing Web Parts for SharePoint 2010.

The support for Feature and Solution packaging seems to be greatly improved as well, and actually looks like it is a real Visual Studio tool rather than an afterthought.

Microsoft has also added a SharePoint node to the Server Explorer in Visual Studio. This allows you to look at the structure and content of the SharePoint site you are targeting without having to bounce back and forth between IE and Visual Studio.

Another big feature is the Business Connectivity Services design tools for Visual Studio. This is a set of tools for implementing BCS entities from within Visual Studio, allowing a developer to do more sophisticated BCS development than is possible from SharePoint Designer.

Moving beyond Visual Studio, there are a number of other important enhancements for developers.

One of these enhancements is the Developer Dashboard. This is a component which is enabled by a sight administrator, and can be added to any SharePoint page to support development and debugging. It provides diagnostic information regarding including the detailed page request, timing information, information on Stored procedures called, as well as details regarding resource usage, authenticated user, web part timings, etc. This should be a big help in troubleshooting issues.

Another addition is the addition of the Client Object Model, a client-side API for interacting with data on the SharePoint server using JavaScript, .NET code, or Silverlight.

Speaking of Silverlight, there is now a built-in Silverlight Web Part to facilitate deployment of rich UI components. The video shows a nice demonstration using Silverlight, the Silverlight Web Part, and the Client Object Model.  

While I definitely like what I see for developers in SharePoint 2010, there are a number of things I want to see but didn’t:

  1. The Visual Web Part Designer is great. I am curious, though, whether this tool will have any support for developing connectable web parts more easily? Creating the visual part of the Web Part is wonderful, but most useful web parts need to provide or consume connections.
  2. Another thought on the Web Part Designer – does it have support for developing async behaviours, or does it still have to be duck-taped together?
  3. Is there better support for development of Site Definitions, List Definitions, Content Types, etc.? This has remained a manual, tedious, and hence error-prone process. Similarly, is there support for editing of CAML for queries, etc.?
  4. SharePoint Workflow development support. The tools for workflow development in SharePoint 2007 are “ok” as far as they go, but there remain a fair number of very manual, very “cludgey” steps that make it non-trivial to implement real-world workflows, including the mechanisms for developing and using custom ASP.NET association, initiation, and task forms.
  5. Speaking of workflow, the execution environment for workflow in SharePoint is missing some pieces, most notably the tracking service. What has been added?
  6. Rumour has it that SharePoint 2010 will be running over .NET 3.5, not .NET 4.0. Say it ain’t so! So SharePoint Workflow will not take advantage of the performance improvements in .NET 4.0 – what’s the point?
  7. Does the Silverlight Web Part support connections? Or must any data flow into or out of the web part be done from within the Silverlight?

Well, those are my first thoughts on SharePoint 2010 for developers. I can’t wait to see/learn more over the coming months.

Don’t hide or disable menu items?

I wholeheartedly disagree with this over on Joel on Software.

Actually, I agree with not hiding functionality, but nothing (including menu items) should be enabled in the UI if it is not possible to perform that function. That is not to say developers should be lazy – don’t just disable things because it is inconvenient for you (the developer) to let them do it. If it is reasonable, leave it enabled, and lead the user through what they need to do to perform the task.

However, there are things in most programs which you really cannot do at a certain point in time, and that should be clear to the user, along with why it is not possible, and how to proceed. The user should never be left at a dead end. On the same not, however, the user should never be led to believe something is possible, only to be denied.

As I write this, I figure I do not wholeheartedly disagree, but I do disagree – like most broad, generalized statements,  it is wrong, or at least not entirely right.

Fred’s Laws – How not to write software

This begins a series of posts on Fred’s Laws – basically a set of anti-rules on how not to develop software.

Over the past twenty-odd years, I have seen a lot of software projects crash and burn. Many have been doomed from the start, while many others died slow, painful deaths after hopeful beginnings. Some have finished, and the systems are in production, without ever having realized that the project was a failure. Others should have failed, but managed to struggle through due to the heroic efforts of one or more dedicated (and usually really smart) people.

I have also seen more than a few “failed” projects that were technical successes. We built really cool software. We were on time, on budget, and had good quality. They failed in some other aspect – usually they were business failures for one reason or another.

The environments in which these projects have died have been varied as well. Some tried to make it with no process at all. Some had lots and lots and lots (and lots and lots) of process. I have not seen a great deal of correlation between process and success (well, except that the process I pick for my projects is always successful 😉 ).

When I look back on these catastrophic projects, usually I can see where things went wrong. In fact, most of the time I could see where they were going wrong while it was happening, like watching a car crash in slow motion, but was frequently powerless to avoid the impact. More often than not (in fact, I would be willing to say always), the root cause was something completely avoidable (from a technical or project perspective). Never was it because we chose Windows over Linux (or vice versa), nor because of the programming language we chose, nor because what we set out to do was technically impossible.

As I have written Fred’s Laws (well, written them in my head, none of them are actually written yet!) it occurs to me that they all seem to be straight from the department of the bloody obvious. No rocket science here. If they are this obvious, why even write them down. Well, the reason is that, despite how really obvious all of this is, I watch projects not do them all the time. Most of the time, in fact.

So, stay tuned. I am going to try to post one law per day (or so) until I run out of ideas.

BTW, as a little footnote, I have been involved in a few successful projects along the way. It just always seems to be the ones that failed (and failed spectacularly) that stick out in my memory.

A Picture of the Multicore Crisis -> Moore’s Law and Software

I was reading A Picture of the Multicore Crisis, and got to thinking of something which has bothered me for a long time. This issue is related to Moore’s Law and the growth of processing capacity (whether through raw clock speed, or the multicore approach, or magic and hampsters). Looking at the last 10 years or so, we probably have something like 10-20 times the processing power we had 10 years ago.

As a producer of server-side software, a user of server software, etc., it makes me wonder – why are my servers (document management, document production, and many others) not providing a corresponding increase in throughput? Why do many server systems maintain the same performance over time, or offer only marginal improvements?

(I leave aside client side performance for now, because on the client side much of the performance improvements have shown up in different ways, such as new capabilities like multimedia, prettier graphics in the UI, the ability to multitask and keep 10 different applications open at the same time).

So, why are my servers not 10 times as fast as they were? I can think of a few reasons:

  1. As has been discussed in other places, the shift from clock-speed-driven improvements to a multicore approach has had an impact. Much software, especially older software, is not written in a way which takes advantage of multiple processors. And often, re-engineering this software to better use multiple processors is non-trivial, especially when you have to worry about things like backwards compatibility and supporting a large number of customers, finding time to add the new features product management wants, etc. Very few of us can afford to divert a significant group of our development resources for an extended period of time, and it is frequently hard to justify from a business perspective.
  2. Even if your software is architected for multiple processors, oftent he algorithm is inherently “single threaded” in places, which throttles the whole process.
  3. Also, even if you are well architected for multiple processors, this does not come for free. The overhead introduced in managing this algorithm can easily consume a non-trivial portion of your processor gains.
  4. Even excluding the shift to multicore, much software has not kept up with performance improvement provided through pure clock speed. There are a number of reasons for this:
    • We are frequently very feature driven. The desire to compete, expand and grow often leads us to add features to existing software at an alarming rate. Wile this is necessary from a business perspective, often the addition of these new features slows down the software faster than the hardware speeds it up. Note, this is why I think it is very important to be architect software so as to be able to isolate “core” processing from “features”. This way, features can be removed from the configuration when not needed, and not allowed to impede performance. Also, this is why it is important in each cycle of development on a product to assess whether performance on the same hardware is at least as good.
    • Processing power is not the whole story (yeah, I know, we all know this). Much of our software is not entirely CPU bound. The bottlenecks are often elsewhere. Much of our processing, especially for large documents, is more bound by memory, disk speed, network speed, and dependencies on other systems. Given that, there is only a limited amount of benefit to be gained through pure processor speed.