At the suggestion of Tim Heuer this week, I took a break from writing my Windows Phone 7 book to delve into HTML5 a bit. I wanted to see what was different and how it would possibly impact Rich Internet Applications (RIA).
I did a couple of HTML5 tutorials which include the new tags that I think will be really cool (like <nav/>, <article/>, etc.) for traditional web design. I think the <datagrid /> and <datatemplate /> tags are interesting but unsure about how they'll be implemented. I also very interested in the local storage story, but it feels a long way from full implementation. But I don't want to talk about the entire HTML5 stack as I am just scratching the surface.
My real goal was to look at the <canvas /> element as that's what I get asked about a lot when compared with Silverlight. In looking at it I was surprised. It seems that the only way to actually draw on the canvas is to use JavaScript. While this is useful for interactive drawing and that sort of application it leaves me a little bewildered. When I asked about this on Twitter, I got a couple of answers like "just use SVG". But SVG is another disruptive technology thrown into the mix. Browsers have to support it. I had expected that HTML5 was going to formalize the SVG support and make that the markup for the canvas. But it doesn't look like that happened. Maybe its me but if its not part of HTML5, then its another thing for the browser guys to agree on. It starts to feel hobbled together for me. Another answer I got was that markup for Canvas didn't matter. Canvas is for drawing and its just not necessary. But I will totally agree that I am viewing it from a XAML lens.
But for me, Markup matters. Without markup, it would be very difficult to build tools for the canvas. But this gets at a very heart of why I like XAML. Let's start a long time ago. As we would design user interfaces and we the designs would take different forms (including binary files, generated code, etc.) The problem with this was that the designs were not easy to edit. More importantly was that the separation of business logic was particularly difficult. It became too simple to add and glue business logic to the user interfaces which of course makes it very difficult to test and extend existing systems. The typical spaghetti code problem.
As I've discussed before, I think there is a benefit of markup is that separation. But keeping the user interface design (look, feel, data binding, etc.) in markup, it encourages business logic to be separate from the user interface. Declarative user interfaces are a key to simplifying how we're building applications.
Other basic idea here that is powerful in Silverlight is that the markup (e.g. XAML) represents the initial object graph that makes up the user interface. It is very common to change this as the application runs (in response to user input or other changes). This means we can build great tools to create the original look and feel and use code to make the application come alive and change the object graph as necessary. Again, on Twitter I was cautioned against changing it too much using JavaScript. A weakness in my eyes.
That's where I thought HTML5 was going to be doing great things. But at this point it feels like HTML5 is going to rely far too heavily on JavaScript (or any code for that matter) instead of allowing us to do more with design tools. In addition, I wish they had integrated SVG (or something similar) as a drawing/animation solution to be closer to a real, rich platform. Instead, HTML5 feels like another 1/2 measure. But that's my opinion with my prejudices...I am sure I'll get an earful in reply ;)
While my last blog post talked about how to debug when your application tombstones, I thought it deserved a video. So today I put together this little video to show off a couple of concepts:
- Debugging while Tombstoning
- Handling State during Tombstoning
- Getting Comfortable with
- Debugging Callbacks during Tasks
Hopefully this video will help you get your application off the ground with some of these concepts:
Here's a quick post to document something I am seeing with the Windows Phone 7 emulator. When you are running your application and you want to test it tombstoning (e.g. deactivating), you should notice that Visual Studio stops debugging when that happens. When you return to your applciation (via the back button or in the case of a chooser, once you've choosen something), you'll get a black screen. This isn't a bug...its a feature!
This black screen is giving you a few seconds (I think Pete Brown said 10 seconds) to run your application to activate and continue your debugging session. I found this in a Windows Phone 7 team blog about the tombstoning cycle, but it was buried in a comment so I thought bringing it as a first class topic might help. Remember, see the black screen on the emulator (or on hardware), just re-run your phone app in Visual Studio to continue debugging!
I was following a conversation in Twitter about the use of MessageBox in a WP7 application. I hate MessageBox as it usually looks nothing like the rest of my app. If figured I should try it first and the out of the box look of the MessageBox API is actually pretty good. It includes a Metro look and a decent animation:
Not bad, but the limitation of only "OK" and OKCancel" is something I run into sometimes so I recommended my old standby from Silverlight, ChildWindow. I love the ChildWindow class because you derive your own UserControl and you can edit it specifically. Unfortunately, there is not an Item type for the Windows Phone for ChildWindow. So I headed back to the Silverlight 3 to grab it. The ChildWindow class exists in the System.Windows.Controls assembly so I had to grab that from Silverlight 3.
Once I did this, I created a new UserControl (from the File->Add New Item...). I changed the root of the XAML file to be ChildWindow and changed the base class in the .cs file too:
<tk:ChildWindow x:Class="WindowsPhoneApplication2.TestChildWindow"
xmlns:tk="clr-namespace:System.Windows.Controls;..."
...
public partial class TestChildWindow : ChildWindow
{
...
Once I did that, I could use the new ChildWindow class the way I expected:
TestChildWindow wnd = new TestChildWindow();
wnd.Show();
The problem was it was styled with the non-Phone look. So ControlTemplates to the rescue. By using a ControlTemplate for the ChildWindow I could change the look and feel to better match the Phone. The look I came up with is ok, but I am no designer:
The problem was editing the ControlTemplate. Normally I'd go to Blend and have them make me a copy of the template and it would bring in the old template. But that doesn't work for some reason. But the template parts are supported so at first I just figured I'd make it by hand. After some hand-wringing, I went to a full Silverlight project and used blend to create the template and copy/pasted it into the Phone project's app.xaml file. Not perfect but it worked. Its beta, right?
Once the ControlTemplate was created I could edit my ChildWindow like any other user control:
(Click for larger version)
Its not very apparent from these static screenies, but the animations in the ControlTemplates are still there so the background is faded and the zoom all works. Because that behavior is in the ControlTemplate, if you wanted to make the look even more Metro-cized you could edit the template to create a flip animation instead...that's your call.
The source code is here:
http://wildermuth.com/downloads/wp7childwindow.zip
I've also added an ItemTemplate for the ChildWindow for Windows Phone 7 projects (though the ControlTemplate won't be there). Use at your own risk. Place it in your VS2010 Item Template directory (e.g. <Your User Docs Folder>\Visual Studio 2010\Templates\ItemTemplates).
http://wildermuth.com/downloads/wp7childwindowtemplate.zip
While I have been exceptionally fortunate to get a Windows Phone 7 device, I still am using my Motorola Droid as my primary phone. The primary reason is that I use Verizon and my WP7 phone uses a SIM chip (Verizon doesn't use SIM chips). I expect you're reading this post to gleam some information about the WP7 phone, but let's start with the Android.
As some of you may know, the 2.2 version of the Android operating system (a.k.a. Froyo) was released and finally made it's way to the Motorola Droid last week. Google had promised a big performance boost with Froyo (100-500% by some accounts) mostly based on the new JIT compiler. So my expectations were pretty high. I got Froyo installed and while I liked the new features and home page changes a lot, I didn't see much performance change. In fact, the new phone felt downright sluggish. Event swiping the home screen was slow. So what gives?
I decided to do a little digging. My installation of Froyo was over an existing 2.1 phone. So all the old apps I was using were all still installed after the update. So I pulled out my trusty OSMonitor app to see who was eating up all the cycles. OSMonitor (unlike the extremely popular Advanced Task Killer) shows all the processes on the machine. I finally found that the replacement SMS program I was using was performing like a dog. Uninstalling it and going back to the built-in SMS app fixed the performance problem and I am happy with how the phone behaves now. But there is an intrinsic problem here. I had to use some spelunking to find out what background processes were killing my performance. This is a big bucket of FAIL.
Phones aren't for geeks, they are for regular people like my mother and my sister. The fact that most Android users learn to use a task management app means there is something wrong. Arguably this was the biggest fault of Windows Mobile devices. It was too easy to kill the performance of the phone with a single bad-acting application., My mother and my sister won't do that. They'll just complain and put up with it and hate their phone. I think this is what Apple got right with the iPhone. The overall experience has been better because of the lack of true background processes.
So that brings us back to the Windows Phone 7. I've run into a lot of Windows Mobile developers who are angry. I empathize but most of those guys are Enterprise developers. I hope they read this because they aren't the audience for this phone. Sure, Microsoft will certainly help those guys do what they need to do eventually, but right now its about winning back the consumer-level phone. Give Microsoft a revision cycle to get back to you. I know its hard, but its the right thing.
I am ecstatic that Microsoft is protecting the sandbox in Windows Phone 7 so carefully. Sure it makes it harder on developers, but it doesn't make it impossible. Arguably even with the strict sandbox and tombstoning, writing apps for the new phone is going to be much easier than Objective-C, or maybe even for the Android. This is what I think is crucial. We (the developers) aren't the most important customers to the phone, the consumers are. We're all bright people, we can work around the restrictions to create better experiences for the phone users. Working around the limitations (using Notification messages, and the lifecycle of apps) means we have to work harder, but when consumers love this phone, they'll buy more apps...meaning we'll have fun making more apps.
Temper your cynicism and remember that this is the first revision of the phone. Sure, Apple is ahead but as we've seen with the XBox, no lead is insurmountable. With Microsoft's ability to update the OS without involving the carriers (unlike Android), additions to the OS to improve the experience for all phones (and developers) is an update away. The WP7 ecosystem is run by a similar team to the Silverlight ecosystem. Iterating quickly, frequent updates, and open source solutions to fill in the holes. Just wait for those first phones to hit the shelves, its going to be a fun ride...at least I hope so.
What do you think?
So it seems pretty clear that Windows Phone 7 is taking the Silverlight world by storm (and the XNA people too). But what if you're not already caught up in the Silverlight storm and you want to write applications for the upcoming phone? That's where I can help!
I run AgiliTrain, a training company specializating in cutting edge technologies. AgiliTrain teaches public courses all over the country (and all over the world through strategic partnerships). We've been teaching Silverlight since before it was called Silverlight (anyone remember WPF/E?). We wanted to take our experience teaching Silverlight these last few years and help phone developers learn how to build rich applications for the new phone platform.
To this end, we've added a new course specifically to teach Silverlight for the Windows Phone 7. The Silverlight Tour for Windows Phone Workshop is a three-day course on Windows Phone 7 Series development using Silverlight. It divides the content into three distinct areas: Design, Development and the Server-Side. Students should be able to develop applications for the phone once they have attended the workshop. The Workshop is structured with a mix of didactic lessons, demonstrations and hands-on labs. Each student will leave the workshop having created several small Silverlight applications. This variety of learning techniques will ensure that all students become proficient in the technology quickly and in an exciting way. Unlike other hands-on course, we teach our courses in small classes (we max out at twenty students) and a significant about of the class is writing actual code.
We are about to teach our first workshop for the phone in Atlanta on September 8-10th, 2010. Since its our first course, we are offering an opportunity for the early adopters out there to be part of our Beta version of the class for a significant discount. For this date only, we're offering a price of only $1,499 (normally $1,999) for the course. If you are interested in attending, you can register for the class on the AgiliTrain site and use the coupon code (WP7BETACLASS). You can review the course, outline and registration information on the AgiliTrain website here:
If you're not sure whether you can attend yet, but want to make sure it doesn't sell out, you can hold a seat using this link:
While I was giving my OData talk, someone asked about consuming OData on the WP7 phone. I had done this on the CTP earlier, but hadn't tried it during the beta. So I figured I'd look into it today. While this is still pretty easy to do, the tooling still isn't in place. This means that you can't simply do an "Add Service Reference" to a Windows Phone 7 project. Instead you have to follow these steps:
- Download the Windows Phone 7 OData Library here.
- Unzip the Windows Phone 7 OData Library to get access to the reference.
- In your project, add a reference to the System.Data.Services.Client.dll assembly from the .zip file.
- Create the proxy classes by using the .NET 4.0's DataSvcUtil.exe (located in the %windir%\Microsoft.NET\Framework\v4.0.30319 directory). See the example below:
%windir%\Microsoft.NET\Framework\v4.0.30319\DataSvcUtil.exe
/uri:http://odata.netflix.com/Catalog/
/out:NetflixModel.cs
/Version:2.0
/DataServiceCollection
- Include this new proxy class (containing the context object and the data classes) in your WP7 application.
- Use the class to call out to the service as necessary:
NetflixCatalog ctx =
new NetflixCatalog(new Uri("http://odata.netflix.com/Catalog/"));
var qry = from p in ctx.People
.Expand("TitlesDirected")
where p.Name == "Stanley Kubrick"
select p;
// Create DataService query since we're not
// using a DataServiceCollection
var dsQry = (DataServiceQuery<Person>)qry;
dsQry.BeginExecute(r =>
{
try
{
var result = dsQry.EndExecute(r).FirstOrDefault();
if (result != null)
{
Deployment.Current.Dispatcher.BeginInvoke(() =>
{
Titles = result.TitlesDirected;
});
}
}
catch (Exception ex)
{
MessageBox.Show(ex.Message);
}
}, null);
Note that you need to use a Dispatcher as this call is *not* guaranteed to be called on the UI thread. This was the one piece that was unexpected. Once I marshaled the update to the UI thread, all worked perfectly.
Here's the example: download
This last week or two has seen a number of interesting stories come out of Microsoft (some official, some not official), especially as it relates to developers and writing code. While I am sure that the announcements are not meant to indicate a trend, taken in conjuction they are confusing or disheartening to developers.
First out of the gate was the announcement of WebMatrix. WebMatrix is a new non-Visual Studio tool for building websites using ASP.NET MVC (and their new view engine) along with a standalone version of IIS and SQL Server Compact. This tool is squarely pointed at the PHP set and wants to make things simple for people who need to just build websites quickly without all the ceremony of ASP.NET.
Also mentioned was LightSwitch. LightSwitch is a tool for interactively building database-driven applications that are hosted on the web or desktop. While Microsoft says:
"With LightSwitch, developers of all skill levels will have the simplest way to build data-centric business applications for the desktop and cloud."
It is clear to me that the this new tool is aimed squarely at the small sized business or non-professional developer who just needs to get a just done; not to developers of all skill levels. Its clearly an answer to developers and professionals that built small apps using Access, FoxPro or FileMaker in the past.
These two announcements put together have been viewed with some suspicion by many Microsoft developers. While some camps out there are pushing for more structure and architecture, both of these solutions seem more suited for rapid application development solutions (RAD). Some developers seem to feel that Microsoft is trying to lower the bar on development so low that anyone can do their job. This isn't how I see these announments. Instead I see them as Microsoft attempting to reach to the full-breadth of developers out there...of all them. I don't see it as a threat to medium and large project development.
Unfortunately in the same timeframe two other annoucements (ill timed as they were) came out of Redmond: IronRuby seems to be losing Microsoft support and Quadrant (a tentpole of Microsoft's Oslo) looks like its been killed. These two stories might indicate that Microsoft is pulling away from the high-end of the developer stack. The problem is that some developers (including me) started to look at these four stories in as a trend. The reality is likely very different.
I probably shouldn't tell you this but there is a little secret about Microsoft that many developers seem to miss. Microsoft isn't a big company. I know, 85K+ employees sounds like a big company. But the reality is that Microsoft is a single HR department that services 100+ small companies. At least that's how each of the parts of Microsoft seem to operate. While at a high level Microsoft attempts to come up with overarching themes and strategies, on a project-by-project basis, teams can be quite myopic about what they are working on (not surprising actually).
This fact was never so obvious as a back when LINQ was announced. The C# team had produced a product called LINQ2SQL because they needed a good compelling story around integrated query. Problem was that over in the Data team (under SQL Server, not under Development Division {aka DevDiv}) they were working on a larger scale solution called the Entity Framework. So about the same time Microsoft released two ORM solutions that took very different approaches. The question was asked how the two teams didn't know about each other. In fact, like many companies, Microsoft thrives on competition so even if they had known about each other it may have been a good strategy to have both being developed in parallel. The mistake (in my opinion) was to release both. They should have picked a winner internally instead of confusing the community. But that is what happens.
Next time you ask yourself, "I wonder where Microsoft is going here." Remember that it is likely not a singular vision statement that is driving every product out of Microsoft, but instead the well-intentioned work of smart guys trying to help a segment of their users or potential users. While WebMatrix and LightSwitch may feel like competition for large application development, in fact "These aren't the IDE's you are looking for." If you feel threatened by them, its likely that you aren't their audience. At the same time other stories about pulling back support for certain tooling means that they didn't find their audience. If you want them supported, tell Microsoft. Write your angry blogs (they tend to listen to them) and contact your local Developer Evangelist and get them to escalate your feedback. Let them know how you feel...
UPDATE, Removed Embedded Slides for simply links as the Flash apps where killing my site perf.
I just got back from DevLink and had a great time. Great audiences as usual. I promised the attendees that I'd share my slides and code so here they are:
Architecting Silverlight Applications
Writing Applications for the Windows Phone 7
Picking a Silverlight Data Access Layer
Introducing OData
This week, from August 5-7th, DevLink in Nashville, TN will be holding their annual conference. If you haven't been before its too late to attend (its sold out). But you should really save the date for next year. This conference is a small conference (about 800 attendees) with lots of great content. The real magic is that its only $100 to attend which makes it really approachable and affordable.
For those of you who already are coming, i'll be there and I am doing four talks including one that hasn't been announced quite yet. Here are the talks:
- Architecting Silverlight Applications
- Picking a Data Platform for Silverlight
- An overview of OData
- Programming WP7 with Silverlight
The last talk (the Windows Phone 7 talk) is new and hasn't made it into the schedule yet. I'll be showing off WP7 development and an actual hardware device!
My company (Agilitrain) is also sponsoring the event so when I am not doing talks, stop by and say hello at our booth. We'll have some swag for those of you who love that stuff.
See you there!
