Hatena::ブログ(Diary)

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

2013年07月31日(水曜日)

Windowsフォーム、Windows 8のシェア、タッチ対応

 以下の図は去年の12月のVSUG DAYのセッション資料の1ページです。


f:id:Yamaki:20130731152218p:image


 減ってきてはいるものの、依然としてWindowsフォームが強いことが分かります。


 そして、これはWindows 7も同じです。Windows 8Windows Vistaのシェアを抜き、確実にその数を増やしつつあるものの現時点ではまだWindows 7とWindows XPが主流です。


Windows 8の世界OS市場シェアが5.6%で初のVista超え──Net Applications調べ - ITmedia NEWS


 しかし、たとえ一部であってもタッチ可能なWindows 8デバイスが入ってきてしまうと、アプリケーション側はタッチによって操作されてしまうことを拒むことはできません。1年ほど前にグレープシティで公開したホワイトペーパーでは以下のように記載しています。


デスクトップアプリケーションのタッチ対応

デスクトップアプリケーションのタッチ対応を考える前に、まずデスクトップアプリケーションがタッチに対応する必要があるのかという点を確認しておくべきでしょう。タッチ操作向けのアプリケーションはMetroスタイルアプリケーションが適しているため、本来であればデスクトップアプリケーションがタッチに対応する必要はありません。しかしながら、これまで述べてきたようにタッチ可能なWindows PCは要不要に関わらず、身近に存在するようになります。そうなったとき、タッチ操作を意識していないデスクトップアプリケーションもタッチされてしまうという事態が発生します。それをアプリケーション側から拒むことはできません。

それ故に、既存資産であるデスクトップアプリケーションを最低限のタッチ操作に対応させたいという需要は、一定数存在するようになると予想しています。


 このような状況への一つのソリューションとして、今回グレープシティから、いつもの業務アプリケーションをそのままタッチ対応アプリにリメイクするという製品を発表しました。



 MultiTouch for Windows Formsは、Visual Studioのツールボックスから、コンポーネントをフォーム上へドラッグ&ドロップするだけで、タッチ操作によるフォームの拡大機能を追加する製品です。


 Windows 8がインストールされているタッチ可能なデバイスをお持ちの方は、以下にClickOnceによるデモがありますので、是非実際にタッチ操作を行って試してみてください。


デモアプリケーション


関連ページ

アプリケーション開発支援ツール/コンポーネント/ライブラリ | Developer Tools - &#

アプリケーション開発支援ツール/コンポーネント/ライブラリ | Developer Tools - &#

TouchToolkit for WinForms | ComponentOne - グレープシティ株式会社


2013年03月28日(木曜日)

2013年03月19日(火曜日)

Windowsフォームにおけるディスプレイ解像度多様化時代への対応

 下のグラフは、このblogの閲覧者のディスプレイの解像度(画素数)トップ10を、2007年2月と2013年2月で比較したものです。


f:id:Yamaki:20130319132445p:image


 6年前の時点では、「1280×1024」と「1024×768」という2つの解像度をサポートできれば、世の中の三分の二の環境で使用することができました。そして「1024×768」サイズの画面は、「1280×1024」のディスプレイに表示させてもさほど違和感はありません。


f:id:Yamaki:20130319152032p:image


 そのため、以前はウィンドウの最小化/最大化ボタンを非表示にしたうえで、ウィンドウサイズを「1024×768」(実際にはタスクバー部分を考慮するため縦方向はもう少し短い)に固定し、画面のレイアウトを固定的に作りこんだWindowsフォームアプリケーションが少なくありませんでした。


f:id:Yamaki:20130319152557p:image


 様々な解像度に対応するコストを考えると、2種類の解像度で三分の二の環境をサポートできる状況ではこの方法は妥当な方法だったと思います。使用する環境がある程度固定される業務アプリケーションともなればなおのことです。


 ところが、現在はトップ10すべてを足してやっと三分の二をカバーすることができる状況となっています。トップ10以外の部分である「その他」の割合を見れば、この6年間でいかに画面解像度の種類が増えたかがよくわかります。


 仮に、現在最も多い「1920×1080」(それでも全体の22%)のディスプレイに「1024×768」サイズの画面を表示させてみると、下の図のようになります。


f:id:Yamaki:20130319154029p:image


 このような状況で、ウィンドウサイズを固定化することは、あまり賢い選択とは言えないでしょう。


 では、様々な解像度に対応できる画面レイアウトにはどのようなものがあるのでしょうか。以下のページは、Windowsストアプリ開発のためのドキュメントですが、この資料の中に出てくる2つのレイアウト方式は、そのままデスクトップのWindowsアプリケーションにも当てはまるものです。


画面に合わせたスケーリングのガイドライン (Windows ストア アプリ) (Windows)


 画面のレイアウトを保持したままで画面全体を拡大/縮小できるのが固定レイアウト方式です。この方法は、WPFやSilverlightなどのベクターベースのXAML UIプラットフォームでは簡単に実現できますが、Windowsフォームではそれを実現する直接的な機能は用意されていません。


 画面を複数のエリアに分割しエリアごとに拡縮の方法を設定するのが、アダプティブレイアウト方式です。この方法はWindowsフォーム2.0で追加されたTableLayoutPanelやFlowLayoutPanelを使用することになりますが、これらのコントロールはXAML UIプラットフォームのGridやStackPanel、WrapPanelと比べると、機能的に不足している部分があったり、デザイナーの操作性が劣っていたりといった問題があります。


f:id:Yamaki:20130319170742j:image


 このような問題に対応できるよう、PlusPak for Windows Formsには固定レイアウト方式とアダプティブレイアウト方式に対応した画面リサイズを可能にするための2つのソリューションが新たに追加されています。


固定レイアウト方式のためのソリューション


 固定レイアウト方式のためのソリューションとして、以下の2つのコントロールが追加されました。


コントロール名機能概要
f:id:Yamaki:20130319171223p:image"GcResize リサイズコンポーネント"フォームのリサイズにあわせたコントロールの拡大/縮小、コントロールごとのリサイズ設定、リサイズポリシーの追加
f:id:Yamaki:20130319171232p:image"GcResizePanel リサイズパネルコントロール"パネルのリサイズにあわせたコントロールの拡大/縮小、コントロールごとのリサイズ設定、リサイズポリシーの追加


 既存のフォームにGcResizeコントロールをドラッグ&ドロップするだけで、簡単に固定レイアウトへの対応を行うことができます。


f:id:Yamaki:20130319171836j:image


 GcResizeは特定のコントロールをリサイズしないといった細かな制御もできるようになっています。言葉で説明するよりも実際の動作を見ていただいたほうが理解しやすいと思いますので、下記のClickOnceデモを是非ご覧ください。


アプリケーション開発支援ツール/コンポーネント/ライブラリ | Developer Tools - &#


アダプティブレイアウト方式のためのソリューション


 アダプティブレイアウト方式のためのソリューションとして、これまであったGcFlowLayoutContainerに加えて、GcTableLayoutContainerが追加されました。


コントロール名機能概要
f:id:Yamaki:20130319172550p:imageGcTableLayoutContainer テーブルレイアウトコンテナコントロールレイアウトの基準となる行・列の追加や削除、行または列ごとのサイズ定義(固定、比率、自動)、セルのマージ、罫線の指定、背景色の指定、背景画像、テンプレートからのレイアウトパターンの選択
f:id:Yamaki:20130319172616p:imageGcFlowLayoutContainer フローレイアウトコンテナコントロールレイアウトの方向、折り返し、子コントロールへのキャプションの追加・立体表示、背景のグラデーション、パターン効果


 GcTableLayoutContainerでは、WPFやSilverlightなどのGridにおいてサポートされるVisual StudioのXAMLデザイナーライクな操作をサポートしており、簡単に列や行をデザインしていけるようになっています。また、行や列の最大値や最小値を設定する機能、セパレーターによるユーザーリサイズ機能など、Windowsフォーム標準のTableLayoutPanelでは実現できなかったレイアウトが可能となっています。


f:id:Yamaki:20130319172841j:image


 PlusPak for Windows Formsは、業務システムに求められる機能の実現を広範囲に支援する .NET Frameworkコンポーネントセットです。製品は「レイアウト」「UIコントロール」「情報表示」「データ出力」「設計支援」の5つのカテゴリから構成されます。


2012年11月14日(水曜日)

新しいsPread

 SPREADは1994年にVisual Basic 2.0向けのデータ グリッドコンポーネントとして登場したグレープシティ(当時はBOC)の製品で、18年間の間に計14製品をリリースしています。


f:id:Yamaki:20121114145000p:image


 コードベースとしてはVisual Basic向け、ASP.NET向け、Windowsフォーム向けの3つが存在していたことになりますが、今回ここに新しくWPF向けが加わります。


SPREAD for WPF 2.0J | Developer Tools - グレープシティ株式会社


 この4つ目のコードベースとなる新しいSPREADは、後方互換性を意識することなくゼロから設計できるチャンスであることから、これまでにない新たな機能や使い勝手が実現されています。その詳細は下記の資料で紹介されています。


SPREADの再創造 〜日本の業務アプリ開発における最強のデータグリッドを求めて〜


 下の図は日本の業務アプリケーションにおける特徴的な表画面の一例です。


f:id:Yamaki:20121114152239p:image


 この表画面には以下のような特徴があります。


  • 1レコード分のデータが複数行にレイアウトされている
  • ヘッダーと明細行のレイアウトは必ずしも一致しない
  • 特定の列の値に基づいたグループ化とそのグループレベルでの集計が行われている
  • 本来の表示データとは直接関係のないデータ(コメント行)が挿入されている


 また、このような条件に加え、特定の値を含む行のみを集計するといった業務に依存した複雑な集計も珍しくありません。


 こういった表画面をデータグリッド系コントロールを使って実現しようとする場合、一般的には非連結(データバインディングを使用しない)で作成されます。コーディングを用いて1つずつデータをセルに配置していく方法です。従来のSPREADはExcelなどのスプレッドシートを基本的な設計概念としていたことから、あらゆる機能がセル単位で柔軟に設定できたため、このような非連結のかたちでよく使用されていました。しかし、非連結による手法は多くのコーディングを必要とするため、生産性や保守性は決して高くありません。


 新しいSPREADでは、データ連結を使用した上でこのような表画面を実現できるよう、以下のような機能が搭載されています。


1レコード複数行レイアウトを実現するための「テンプレートデザイナ」

f:id:Yamaki:20121114172917p:image


ヘッダを明細行とは異なるレイアウトにするための「ヘッダデザイナ」

f:id:Yamaki:20121114172941p:image


グループ化と集計を実現するための「グループデザイナ」

f:id:Yamaki:20121114173002p:image


連結時にもそれとは無関係に非連結業を挿入できるInsertUnboundRowメソッドやAddUnboundRowメソッド


複雑な集計時に必要となる数式で使用できる列名参照


 新しいSPREADであるSPREAD for WPF 1.0Jはすでに無償のトライアル版が公開されており、以下のページからダウンロードすることができます。


トライアル版 - ダウンロード | Developer Solutions - グレープシティ株式会社


2012年03月05日(月曜日)

Silverlightアプリケーション最適化ツール「XapOptimizer」がWindows Phoneアプリに対応

 XapOptimizerは2009年にリリースされたSilverlightアプリケーションの最適化ツールで、アプリケーションパッケージのサイズ削減やコードの難読化といった機能を持っています。


Silverlightアプリを軽量化するツール「XapOptimizer 1.0J」 - Yuya Yamaki’s blog


 今回、このXapOptimizer 1.0Jのサービスパックがリリースされ、Windows Phoneアプリの最適化がサポートされるようになりました。


アプリケーション開発支援ツール/コンポーネント/ライブラリ | Developer Tools - &#


 Windows Phoneでは、20MB以上のサイズのアプリケーションは3G回線ではダウンロードすることができないという制限が存在します。


7 - Windows Marketplace とのやり取り

電話にダウンロードするパッケージのサイズが 20 MB を超える場合、GPRS または 3G 電話接続では Windows Marketplace からダウンロードすることはできません。サイズが 20 MB を超えるパッケージは、Wi-Fi 接続または物理的な有線接続を介してダウンロード、インストールしなければなりません。


 これはiPhoneも同様となっており、開発の際に20MBの壁を意識することは比較的認知されているようです。


LINE流行に見るアプリにとって20MBの壁が非常に重要な理由。3G回線利用比率は4割に | スマホアプリ開発記

有料アプリの場合、購入することすらできないため、単純に20MBを超えるだけで販売機会を逃すことになり、iPhone開発者にとってアプリを20MBに収めることが重要であることはよく認知されています。


 もちろんこのレベルのサイズの場合、大部分を画像や音声といったコンテンツが占めているためXapOptimizerでサイズ削減できる割合はあまり大きくないことが予想されますが、アプリサイズをできる限り小さくするに越したことはありません。


 下の図は実際にMarketplaceで公開しているアプリをXapOptimizerで最適化した結果です。


f:id:Yamaki:20120305174705p:image


 今回のケースでは、アプリサイズだけでなく起動の速度やメモリ消費のピークも僅かに減っていることを確認することができました。


最適化前:

f:id:Yamaki:20120305181625p:image


最適化後:

f:id:Yamaki:20120305181624p:image