Hatena::ブログ(Diary)

Yuya Yamaki’s blog このページをアンテナに追加 RSSフィード

2011年11月19日(土曜日)

SilverlightとWindows PhoneのBitmapImageの読み込みは非同期で行われる

no title


 以下のようなコードを実行した場合、WPFでは問題ありませんが、SilverlightやWindows Phoneでは最後の行の部分でInvalid pointerというメッセージと共にNullReferenceExceptionが発生します。


string name = Assembly.GetExecutingAssembly().FullName;
AssemblyName asmName = new AssemblyName(name);
BitmapImage image = new BitmapImage(new Uri("/" + asmName.Name + ";component/Images/Chrysanthemum.jpg", UriKind.RelativeOrAbsolute));

WriteableBitmap bitmap = new WriteableBitmap(image);


f:id:Yamaki:20111119143252p:image


 この現象はBitmapImageのCreateOptionsプロパティの既定値が異なることに起因します。WPFでは既定値はNoneですが、SilverlightやWindows PhoneではDelayCreationです。こちらのページでは既定値はNoneと書いてありますが、これは誤りです。


 CreateOptionsプロパティをNoneに設定することで、上記の問題を解決することができます。


string name = Assembly.GetExecutingAssembly().FullName;
AssemblyName asmName = new AssemblyName(name);
BitmapImage image = new BitmapImage();      
image.UriSource = new Uri("/" + asmName.Name + ";component/Images/Chrysanthemum.jpg", UriKind.RelativeOrAbsolute);
image.CreateOptions = BitmapCreateOptions.None;

WriteableBitmap bitmap = new WriteableBitmap(image);


 上記のフォーラムの回答に書かれているほかの解決方法として、BitmapImageのImageOpenedイベントを使って読み込み完了後に処理を行うようにする方法もあります。


2011年11月16日(水曜日)

ListBoxで各項目の間隔をあけて選択できない領域を作る

f:id:Yamaki:20111116122956p:image


 ListBoxで各項目の間隔をあけて選択できない領域を作りたい(単純に項目の間隔をあけるだけでなく項目と項目の間をクリック/タップしてもSelectionChangedイベントが発生しないようにしたい)場合、2007年の投稿で紹介したListBoxItemのControlTemplateを変更して選択できる領域を限定する方法でも一見実現可能なように思えますが、この場合最後の項目の後にも間隔があいてしまうという問題があります。このような場合、カスタムのPanelを作成し、それをListBoxのItemsPanelTemplateとして設定する方法で実現することができます。


C#

using System;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Ink;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;

namespace SkipPanelSample
{
    public class SkipPanel : Panel
    {
        public SkipPanel()
            : base()
        {
        }

        protected override Size MeasureOverride(Size availableSize)
        {
            Size panelDesiredSize = new Size();

            foreach (UIElement child in Children)
            {
                child.Measure(availableSize);
                panelDesiredSize = child.DesiredSize;
            }

            return panelDesiredSize;
        }

        protected override Size ArrangeOverride(Size finalSize)
        {
            double y = 0;
            foreach (UIElement child in Children)
            {
                child.Arrange(new Rect(new Point(0, y), child.DesiredSize));
                y += child.DesiredSize.Height * 2;
            }
            return finalSize;
        }

    }
}


 このSkipPanelでは項目1つの高さ分間隔をあけて配置するようにしています。SilverlightやWindows Phone OSではPanelクラスにInternalChildrenプロパティがないため通常のChildrenプロパティを使用していますが、WPFではMeasureCoreやArrangeCoreなどのオーバーライドの場合Panel.InternalChildren プロパティ (System.Windows.Controls)を使用することが推奨されています。


XAML

<ListBox ItemsSource="{Binding Collection}" FontSize="64">
    <ListBox.ItemTemplate>
        <DataTemplate>
            <Border BorderBrush="White" BorderThickness="2" Margin="5">
                <TextBlock Text="{Binding Property1}" Margin="10" Width="400"/>
            </Border>
        </DataTemplate>
    </ListBox.ItemTemplate>
    <ListBox.ItemsPanel>
        <ItemsPanelTemplate>
            <local:SkipPanel/>
        </ItemsPanelTemplate>
    </ListBox.ItemsPanel>
</ListBox>


2011年11月09日(水曜日)

DPIスケール変更時におけるWPFとSilverlightの違い

 以前の投稿@ITの.NET開発者中心厳選ブログ記事として転載されました。ここでは、以前の投稿では文章量の関係から書かなかったもう1つの要素について書きたいと思います。それは、高DPIへの対応です。


Windows 8時代のディスプレイ


 この15年くらいの間で、画面解像度*1は種類が増え、その大きさも大きくなりました。しかしながら、それとともに物理的なディスプレイのサイズも大きくなっているため、ピクセル密度は96PPI(pixel per inch)前後のままと大きな変化はありません。


 現在一般向けとして販売されているデスクトップPC向けディスプレイで物理的に一番大きいものは27インチです。おそらくこれが常用できる最大サイズであり、これ以上大きいディスプレイが普及するということはないのではないかと思います。そう考えた場合、この先のディスプレイの進化の矛先はディスプレイの物理的な大きさはそのままに画面解像度を高くする高精細化に向けられるのではないかと思います。


 2010年6月24日に発売されたiPhone 4のRetinaディスプレイのピクセル密度は326PPIです。


iPhone - Apple(日本)


 また、先月には東芝モバイルディスプレイがRetinaディスプレイを超える498PPIの液晶ディスプレイの開発を発表しています。


「写真画像並」の超高精細モバイルディスプレイ、東芝グループが開発 - ITmedia PC USER


 このような高精細ディスプレイは、スマートフォンなどの比較的小さいサイズの液晶から普及していくと思いますが、ゆくゆくはスレートPC、デスクトップ/ノートPCでも普及してくるものと予想しています。


 高精細ディスプレイではシステム側が何もしなければ文字やアイコンなどが通常よりも小さく表示されます。96PPIと192PPIのディスプレイでは実際に見える大きさが単純に4分の1になります。WindowsではDPIスケーリングを変更することでシステムフォントとシステムUI要素のサイズを大きく表示できるようになっており、120PPI前後の一部のノートPCなどでは初期設定でDPIスケールが125%(120DPI)に設定されているものもあるようです。


 今後の5年間を考えた場合、アプリケーションがDPIスケーリングによってきれいにスケールされるかどうかはとても重要な要素になるのではないかと思います。ここまで書いた内容は、MSDNライブラリの下記のページにほぼ同じことが書かれています。


高 DPI


2つのDPIスケーリング方式


 Windows Vista以降、DPIスケーリングには2つの形式があります。ここでは1つをXP形式、もう1つをVista以降の形式と呼ぶことにします。これは[カスタム DPI 設定]画面で「Windows XP 形式の DPI スケーリングを使用する」にチェックが入っているかどうかで決まります。144DPI(150%の設定)126%より小さいの場合、このチェックボックスはデフォルトでオンになりますが、144DPI(150%の設定)126%以上の場合はデフォルトでオフになります。


f:id:Yamaki:20111109172158p:image


 Vista以降の形式では、DPI仮想化と呼ばれる機能によってスケーリングが行われます。アプリケーションをいったん96DPIで画面表示領域外に描画し、それをDWM(デスクトップウィンドウマネージャ)がDPIスケーリングに合わせて拡大表示します。そのため、Visata以降の形式はDWMがオンの状態でのみ使用可能です。DPI仮想化が有効な場合、DPIスケーリングに対応していないアプリケーションでもほぼ期待する形でスケーリングすることができるというメリットがあります。しかしながら実際にはスケールではなくビットマップとして拡大表示されているため、どうしてもぼやけた印象の表示となってしまいます。


 96DPIの環境で作成したWindowsフォームの画面を144dpi(150%)で表示した結果が下の図です。


XP形式Vista以降の形式
f:id:Yamaki:20111109175832p:imagef:id:Yamaki:20111109175855p:image


 DPI仮想化は、あくまでDPIスケーリングに対応していないアプリケーションを救うための措置といえます。アプリケーションがDPIスケーリングに対応しているにもかかわらず、DPI仮想化が行われてしまい画面がぼやけてしまったのでは困ります。そのため、DPIスケーリングの設定がVista以降の形式になっていたとしても、そのアプリケーションにだけDPI仮想化を行わないようにする方法が2つ(SetProcessDPIAware関数を使う方法もあるため正確には3つ)用意されています。


ファイルのプロパティの[互換性]タブ


 ファイルのプロパティの[互換性]タブの[設定]というところに、「高 DPI 設定では画面のスケーリングを無効にする」というチェックボックスがあります。このチェックボックスをオンにすることで、DPI仮想化が無効になります。


f:id:Yamaki:20111110115417p:image


アプリケーションマニフェストを使用する


 以下のようなアプリケーションマニフェストファイルを作成し、mt.exeなどを使って実行ファイルに埋め込むことで、このアプリケーションはDPIスケーリングに対応しているアプリケーションであることを宣言できます。


<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" >
 <assemblyIdentity type="win32" name="app" version="1.0.0.0" processorArchitecture="x86"></assemblyIdentity>
  <asmv3:application>
    <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
      <dpiAware>true</dpiAware>
    </asmv3:windowsSettings>
  </asmv3:application>
</assembly>


mt.extの使い方の例


mt.exe /manifest WindowsFormsApplication.exe.manifest -outputresource:WindowsFormsApplication.exe;1


DPIスケーリング変更時のWPFアプリケーションの表示


 こちらの以前の投稿でも解説していますが、WPFにおけるピクセルという単位は物理的なピクセルに依存しない論理上のピクセルとなっています。これはDPIスケーリングが96DPIのときの1ピクセルを1論理ピクセルとするもので、144DPIでは1論理ピクセルが物理的なピクセルとして1.5ピクセルとなります。


 このようなWPFにおけるスケーリングの動作は、XP形式とVista以降の形式のどちらが設定されていても働きます。つまり、WPFアプリケーションではDPI仮想化は有効にならず、常に下の図のようにスケーリングされた表示となります。


96DPI144DPI
f:id:Yamaki:20111110133247p:imagef:id:Yamaki:20111110130603p:image


DPIスケーリング変更時のSilverlightアプリケーションの表示


 Silverlightの場合、通常のWebブラウザー内に表示される場合とブラウザー外実行の場合で動作が異なります。


Webブラウザー内に表示される場合


 Webブラウザー内で表示される場合、Webブラウザーの種類によって以下のように表示が異なります。なお、Internet ExplorerとFirefoxはDPIスケーリングに対応しているアプリケーションであるとマークされておりDPI仮想化は有効になりませんが、ChromeはマークされておらずDPI仮想化が有効となります。また実際にChrome自体がDPIスケーリングに対応していません。


Webブラウザーの種類XP形式Vista以降の形式
Internet Explorer 9Webブラウザーの拡大機能によって拡大Webブラウザーの拡大機能によって拡大
Firefox 8.0通常(96DPI)と同様通常(96DPI)と同様
Chrome 15.0通常(96DPI)と同様DPI仮想化によって拡大


 なお、Internet Explorerが異なるのはWebブラウザーの拡大機能が自動で実行される部分だけであり、FirefoxやChromeでも手動でWebブラウザーの拡大率を変更することでSilverlightコンテンツ部分も拡大されます。


96DPI144DPI
f:id:Yamaki:20111110141718p:imagef:id:Yamaki:20111110141740p:image


ブラウザー外実行の場合


 ブラウザー外実行の場合、sllauncher.exeという実行ファイルにホストされてSilverlightアプリケーションが動作します。そしてこのsllauncher.exeはDPIスケーリングに対応しているアプリケーションであるとマークされていないため、Vista以降の形式の場合にはDPI仮想化が有効となり下の図のようにぼやけた表示となります。


96DPI144DPI
f:id:Yamaki:20111110142053p:imagef:id:Yamaki:20111110142216p:image


 そして、XP形式にしてDPI仮想化を無効にすると、Webブラウザー内で表示される場合のInternet Explorerのときと同じ表示になります。


f:id:Yamaki:20111110142131p:image


 一瞬100%で表示されたのちに150%に拡大されるためおそらくはInternet Explorerの拡大表示機能が内部で使われていると思われます。


 なお、sllauncher.exeに対して、ファイルのプロパティの「高 DPI 設定では画面のスケーリングを無効にする」の設定や、マニフェストを埋め込むといった方法を実際に試してみましたが、有効でした。Vista以降の形式になっていてもこれらの設定をすることで、ブラウザー外実行でもDPI仮想化を無効とすることができます。


*1:本来は総画素数というのが正しいようですが、解像度が一般的に使われているため画面解像度とします。

2011年11月08日(火曜日)

4つのテクノロジーのControls名前空間を比較

クラス名Windows Runtime Developer PreviewWPF 4.5 Developer PreviewSilverlight 5 RCWindows Phone OS 7.1
ApplicationBar--○※5
AutoCompleteBox---
AccessText---
ActivatingKeyTipEventArgs-○※2--
AdornedElementPlaceholder---
AlternationConverter---
BooleanToVisibilityConverter---
Border
BorderGapMaskConverter---
Button
Calendar--
CalendarBlackoutDatesCollection--
CalendarDateChangedEventArgs--
CalendarDateRange--
CalendarModeChangedEventArgs--
Canvas
CaptureElement○※1---
CarouselPanel○※1---
CheckBox
ChildWindow---
CleanUpVirtualizedItemEventArgs
ColumnDefinition
ColumnDefinitionCollection
ComboBox
ComboBoxItem
ContentChangedEventArgs--
ContentControl
ContentPresenter
ContextMenu---
ContextMenuEventArgs---
ContextMenuService---
Control
ControlTemplate
DataErrorValidationRule---
DataGrid--
DataGridAutoGeneratingColumnEventArgs--
DataGridBeginningEditEventArgs--
DataGridBoundColumn--
DataGridCell--
DataGridCellClipboardEventArgs--
DataGridCellEditEndingEventArgs--
DataGridCellsPanel---
DataGridCheckBoxColumn--
DataGridColumn--
DataGridColumnEventArgs--
DataGridColumnReorderingEventArgs--
DataGridComboBoxColumn---
DataGridHyperlinkColumn---
DataGridLengthConverter--
DataGridPreparingCellForEditEventArgs--
DataGridRow--
DataGridRowClipboardEventArgs--
DataGridRowDetailsEventArgs--
DataGridRowEditEndedEventArgs---
DataGridRowEditEndingEventArgs--
DataGridRowEventArgs--
DataGridRowGroupHeader---
DataGridRowGroupHeaderEventArgs---
DataGridSortingEventArgs---
DataGridTemplateColumn--
DataGridTextColumn--
DataPager---
DataTemplateSelector--
DatePicker--
DatePickerDateValidationErrorEventArgs--
DateTimeTypeConverter---
DescriptionViewer---
Decorator---
DefinitionBase---
DockPanel---
DocumentViewer---
DragItemsStartingEventArgs○※1---
DrawEventArgs---
DrawingSurface---
ExceptionValidationRule---
Expander---
FlipView○※1---
FlipViewItem○※1---
FlowDocumentPageViewer---
FlowDocumentReader---
FlowDocumentScrollViewer---
FocusingInvalidControlEventArgs---
Frame○※8
Grid
GridSplitter--
GridView○※1--
GridViewColumn---
GridViewColumnCollection---
GridViewColumnHeader---
GridViewHeaderRowPresenter---
GridViewRowPresenter---
GroupBox---
GroupItem--
GroupStyle--
GroupStyleSelector---
HeaderedContentControl---
HeaderedItemsControl--
HyperlinkButton--
Image
InitializingNewItemEventArgs---
InkCanvas---
InkCanvasGestureEventArgs---
InkCanvasSelectionChangingEventArgs---
InkCanvasSelectionEditingEventArgs---
InkCanvasStrokeCollectedEventArgs---
InkCanvasStrokeErasingEventArgs---
InkCanvasStrokesReplacedEventArgs---
InkPresenter-
ItemClickEventArgs○※1---
ItemCollection
ItemContainerGenerator
ItemContainerTemplate-○※2--
ItemContainerTemplateKey-○※2--
ItemContainerTemplateSelector-○※2--
ItemsControl
ItemsPanelTemplate
ItemsPresenter
JumpViewer○※1---
JumpViewerLocation○※1---
JumpViewerViewChangedEventArgs○※1---
KeyTipAccessedEventArgs-○※2--
KeyTipControl-○※2--
KeyTipService-○※2--
Label--
ListBox
ListBoxItem
ListView○※1--
ListViewBase○※1---
ListViewItem--
ListViewItemTemplateSettings○※1---
MediaElement
MediaPlayer○※6-○※7
Menu---
MenuItem---
MenuScrollingVisibilityConverter---
MultiScaleImage--
MultiScaleSubImage--
NotifyEventArgs-○※4
NotifyDataErrorValidationRule-○※2--
OpenFileDialog-○※3-
OrientedVirtualizingPanel○※1---
Page○※9
Panel
PasswordBox
PopulatedEventArgs---
PopulatingEventArgs---
PrintDialog---
PrintDialogException---
ProgressBar
ProgressRing○※1---
RadioButton
RichTextBlock--
RichTextBlockOverflow--
RichTextBox-
RoutedPropertyChangingEventArgs<T>---
RowDefinition
RowDefinitionCollection
SaveFileDialog-○※3
ScrollChangedEventArgs---
ScrollContentPresenter
ScrollViewer
SelectedCellsChangedEventArgs---
SelectedDatesCollection--
SelectionChangedEventArgs
SelectorSelectionAdapter---
Separator---
Slider
SoundPlayerAction---
SpellCheck---
SpellingError---
StackPanel
StickyNoteControl---
StyleSelector--
SubImageRoutedEventArgs---
TabControl--
TabItem--
TextBlock
TextBox
TextChange---
TextChangedEventArgs
ToggleSwitch○※1---
TextSearch--
ToolBar---
ToolBarTray---
ToolTip
ToolTipEventArgs---
ToolTipService
TreeView--
TreeViewItem--
UIElementCollection
UserControl
Validation-
ValidationError-
ValidationErrorEventArgs-
ValidationResult---
ValidationRule---
ValidationSummary---
ValidationSummaryItem---
ValidationSummaryItemSource---
VariableSizedWrapGrid○※1---
ViewBase---
Viewbox
Viewport3D---
VirtualizationCacheLengthConverter-○※2--
VirtualizingPanel
VirtualizingStackPanel
WebBrowser-○※4
WebBrowserBrush---
WebView○※1---
WebViewBrush○※1---
WrapGrid○※1---
WrapPanel---
2127716511760


※1 Windows Runtime Developer Previewにのみ存在するクラス

※2 WPF 4.5 Devloper Previewで追加された新しいクラス

※3 Microsoft.Win32名前空間に存在するクラス

※4 Microsoft.Phone.Controls名前空間に存在するクラス

※5 UIElementではないがMicrosoft.Phone.Shell名前空間にあり

※6 UIElementではないがSystem.Windows.Media名前空間にあり

※7 SilverlightのクラスではないがMicrosoft.Xna.Framework.Media名前空間にあり

※8 Microsoft.Phone.Controls名前空間のPhoneApplicationFrameクラス

※9 Microsoft.Phone.Controls名前空間のPhoneApplicationPageクラス


※注意 Windows RuntimeのListViewとGridViewはWPFにおけるそれとクラス名は同じだがまったく異なるもの


2011年10月19日(水曜日)

Windows 8以降のマイクロソフトのアプリケーション開発技術

f:id:Yamaki:20111006091420p:image


 Windows 8が登場すると、Metroスタイルという新しいアプリケーションの形態が追加されるため、アプリケーションの開発技術の選択肢はさらに増えることになります。しかしながら、Windowsプラットフォーム上で実行される多くの業務アプリケーションにとっては、WPFSilverlightのどちらかになる(もちろんWindowsフォームも実行可能)という状況はそれほど変わっていないと思います。


 もし、どのアプリケーション開発技術を選択してよいかわからないという場合には、下記のblogに書かれたフローチャートが役に立つかもしれません。


Telerik Watch: When Should You Use Metro, Version 2


 ここからは私個人の意見です。あくまでも個人の意見ですので、書き手の都合の良いように解釈、判断している部分もあるかもしれません。


 WPFかSilverlightのどちらかを選択するということは変わっていませんが、今後はSilverlightよりもWPFを選択するケースがこれまでよりも多くなるのではないかと予想します。その理由は以下のようなものです。


Silverlightの居場所は?


 これまでは、Silverlightがマイクロソフトのアプリケーション開発技術の中で最もマルチに対応できる選択肢だったと思います。それはWindowsアプリケーションからWebアプリケーション、ビジネス向けのアプリケーションからコンシューマ向けのアプリケーションまでといった具合にです。しかしながら、現在の状況、そして今後の流れを考えた場合、その状況は変わってくると予想します。


WindowsアプリケーションとWebアプリケーション(クロスプラットフォーム)


 かつてSilverlightはその特徴の一つとして「クロスプットフォーム」を大きく掲げていました。しかしながら、Silverlightは徐々にクロスプラットフォームをあきらめていったように思います。


 フルサイズのWebブラウジングがPCだけのものだった時代には、PCの主要なプラットフォームさえカバーできればクロスプラットフォームであると言えました。つまり、今現在のSilverlightがサポートするWindowsとMacの2つだけでも十分だったのです。しかし、スマートフォンやタブレットといったPC以外のWebブラウジング環境は、すごい勢いで増え続けています。かつてWindows MobileやNokiaをサポートするとアナウンスされていたSilverlight 2 for Mobileはキャンセルされました。そして、Windows Phone上に載っているSilverlightは通常のアプリケーションプラットフォームであり、Webブラウザーのプラグインではありません。


 Silverlight 4では、Mac環境をサポートしない「COMオートメーション」が追加されました。このことは、Silverlightのクロスプラットフォームに対する方向性の転換を示すものととらえることもできます。今年中にリリースが予定されているSilverlight 5でも、Windowsプラットフォームのみの機能である「P/Invoke」が追加される予定です。


 そして、マイクロソフトが本当の意味でのクロスプラットフォームはHTML5だと考えていることは、下記のボブ・マグリア氏発言、そしてMetroスタイル版のInternet Explorer 10がプラグインをサポートしないことからも明らかではないかと思います。


no title


no title


 これらのことから、私はSilverlightの活躍場所はクロスプラットフォーム(Webアプリケーション)ではなく、Windowsアプリケーションであると考えています。


コンシューマ向けアプリケーションと業務アプリケーション


 SilverlightがWPFに対して持っているアドバンテージとして、DeepZoomやSmooth Streamingといった機能があります。これらは業務アプリケーションよりも、コンシューマ向けのアプリケーションで使われる機能です。


 これまではWindowsアプリケーションの開発技術に、業務向けもコンシューマ向けも区別はありませんでした。しかしながら、Windows 8がリリースされると多くのコンシューマ向けアプリケーションがMetroスタイルとして作成されることになると思います。また、多くの場合、SilverlightはWPFに比べMetroスタイルアプリケーションへの移行が簡単です。そのため、新規のアプリケーションだけでなく既存のコンシューマ向けSilverlightアプリケーションもMetroスタイルアプリケーションとして登場することが予想できます。これは、今後MetroスタイルアプリケーションでDeepZoomやSmooth Streamingが提供されるかどうかも大きく影響するでしょう。


 これらのことから、私はSilverlightの居場所は徐々に業務向けに偏ってくるのではないかと考えています。


Silverlightの居場所


 Silverlightの主な活躍場所は業務向けのWindowsアプリケーションです。これまでと異なり、ほぼ同じ土俵でSilverlightはWPFと比較検討されることになるのではないでしょうか。


WPFのアドバンテージ


 業務向けのWindowsアプリケーションという土俵で両者を比較した場合、WPFはSilverlightに比べて以下の点でアドバンテージがあると思います。


Windowsフォームからの移行


 業務アプリケーションの開発において純粋な意味での新規開発は少なくなってきており、WPFかSilverlightかを選択する機会というのは主に既存のアプリケーションの移行になるのではないかと思います。現在、Windowsプラットフォーム上の業務アプリケーションで最も多いのは、Windowsフォームではないかと思います(その次はもしかしたらVisual Basic 6.0かもしれません)。したがって、Windowsフォームから移行がしやすいかどうかは、WPFかSilverlightかを選択するうえで重要なポイントになるのではないかと思います。


 WPFは、Silverlightに比べて以下のような点でWindowsフォームに近いと言えます。


  • サブセットではないフルの.NET Frameworkクラスライブラリを使用できる
  • サービスを経由することなく直接ADO.NETを使ってデータベースにアクセスできる


 また、Windowsフォームから段階的な移行がしやすいのもWPFの特徴です。WPFではWindowsFromsHostコントロールを使ってWPF要素内にWindowsフォームコントロールを表示することができます。先の投稿で紹介したように、WPF4.5において「WPFでホストされているWindowsフォームコントロールが常にWPFコンテンツの一番上に表示される」という問題が改善されるため、WindowsFromsHostを使って一部分をWindowsフォームのままとするWPFアプリケーションがより現実的なものとなります。


開発生産性


 Silverlightは、ランタイムのサイズをコンパクトに保つため、同じ名前のクラスやメソッドでもWPFに比べてメンバ数が少なかったりオーバーロードの数が少なかったりします。特に、「結果的には同じことができるがこれがあると便利」といった類のものの多くは実装されていません。


 たとえば、WPFのColor構造体には新しいColor構造体を作成するためのメソッドが5つ存在しますが、Silverlightは1つだけです。


メソッド名WPFSilverlight
FromArgb
FromAValues-
FromRgb-
FromScRgb-
FromValues-


 このような差は機能レベルで比較された場合には違いとして出てきませんが、開発生産性に影響する可能性があります。


タッチ操作への対応


 Windows 8により、タッチ可能なWindowsというものが世の中に普及することになります。タッチ可能なデバイスではMetroスタイルのアプリケーションを使用するのがベストだと思いますが、業務アプリケーションにおいては既存資産やコストの兼ね合いから、既存のアプリケーションを最低限のタッチ操作に対応させたいといった需要も少なからず生まれてくると予想します。


 また、タッチ可能なデバイスはスレート/タブレットPCだけとは限らないと思っています。タッチディスプレイの生産コストが下がれば、需要があるなし関係なくタッチ可能なデスクトップPCというのも徐々に増えてくると予想します。PCメーカーとしても、Windows 8を搭載しているにも関わらずタッチ機能が備わっていないPCは売りづらくなるでしょう。これにより、デスクトップで基本的にはキーボードとマウスを使いながらも、一時的、あるいは部分的にタッチを使って操作するという人もちらほらでてくるのかもしれません。


 タッチ操作への対応において、WPFは以下の2点でSilverlightよりも有利です。


  • 標準コントロールがデフォルトでスクロール等の基本的なタッチ操作に対応している
  • Manipulationとよばれる高レベルなマルチタッチのインターフェイスが用意されている


これまでSilverlightが有利だったもの


 これまで業務向けのWindowsアプリケーションにおいてWPFよりもSilverlightが有利とされてきた点のいくつかは、今後改善されていくと思います。


ランタイム環境のセットアップ


 下記の記事で書いた通り、SilverlightはWPFに比べてランタイム環境のセットアップが容易です。


これから業務アプリを開発するならどっち?(1/3) - @IT


 これは主にランタイムのインストーラーサイズが5MB台と小さいためであり、いくら.NET Framework 4で大幅にインストーラーサイズが削減されたといっても、有利であることに変わりはありません。しかしながら、プリンストールされているOSがあるという点では、.NET Frameworkが有利であると言えます。そして、現在一般的に使用されているWindows OSの中で唯一.NET FrameworkがプリインストールされていないWindows XPは、もはや一番多く使用されているWindowsではなくなりました。


no title


アプリケーションの起動速度


 WPFではなくSilverlightを選択した理由として、WPFアプリケーションの起動の遅さをあげているケースがありました。.NET 4.5ではCLRに以下の5つの改善が施されており、それらは主にパフォーマンスに関するものとなっています。


  • Background mode for Server GC
  • Managed Profile Guided Optimization
  • Automatic NGEN
  • Multi-core background JIT
  • Re-JIT


 紹介のされ方を見るとMetroスタイルアプリケーションのためという要素が強いようですが、これらはWPFなどのMetroスタイルではない.NETアプリケーションにとっても有効な改善です。特にこれまでネイティブコードでしか利用できなかった「PGO (Profile-Guided Optimization) 」がCLRで実行されるアプリケーションでも利用可能になるというのは、非常にインパクトが大きいと感じます。


最後に


 このほかに影響しそうなものとして、WCF RIA ServicesとVisual Studio Light Switchをあげておきます。これらは特に今回動きがありませんが、今後注目しておきたいポイントです。