- MSはデバイスとサービスのカンパニーになる
- 世界でイケてる開発者を目指してほしい
- 開発者に元気がない
- しかし環境はよい(クラウド、ソフトウェア…)
- デバイスとソフトウェアを組み合わせることを意識する
- 生まれ変わったWindows
- タッチが最優先
- 複数のフォームファクター
- 8-inch もある
- 今後増える
- Windows ストア
- 皆さんに儲けてほしい
- 新しい開発モデル
- エンドユーザーの便宜を最優先
- 覚えておきたいショートカットキー
- Win+X は必須
- Surface
- RTはARM
- デスクトップアプリは動かない
- 皆さんがアプリを作ってもらいたい
- RTはARM
- Windows ストアアプリ
- 余計な飾りはない
- コンテンツに集中させることが基本
- 開発者はアプリの使われ方やクラッシュレポートを見ることができる
- Windows 8 プラットフォーム
- 新しい試練がある
- C/C++/C#/VBで開発できる
- Direct X/XAML or HTML/JavaScript
- 今後多様なデバイスにWindows 8が登場するので、大きなビジネスチャンス
- 開発環境
- Visual Studio 2012
- Windows 8は必須
- Windows Azure Mobile Services (BaaS: Backend as a Service)
- 認証、通知、DBなどを提供
- デモ (SignalR)
- Windows Azure
- 様々なサービス
- 管理コンソールからMobile Serviceを作成
- アプリとサービスのつなげ方
- 管理コンソールからテンプレートをダウンロード
- URLとAPIキーを設定するだけ
- Windows 8.1: Free for all Windows 8 PCs
- パーソナル設定
- タイルのサイズ変更
- 標準・ワイドのほかに小・大が追加
- Bingが検索に統合
- 検索結果からストアアプリへの誘導も
- 開発者の作成したアプリ一覧
- 過去にDLしたアプリからおすすめ
- 縦にスクロールするとアプリ一覧
- 開発中アプリをスタート画面に出さないように(全アプリ一覧のほうにでる)
- Windows 8.1 開発者向け機能
- コントロール強化
- Webview, Hub コントロール
- IEがWebGL, MPEG-DASH対応
- 本当に8.1?
- Text To Speech
- 日本語も読めるエンジンもある
- PDFのレンダリング
- POSや3Dプリンタへの対応
- New API
- HttpClientがPCLで使える
- コントロール強化
- 開発者ツール
- Visual Studio
- スクロールバー
- Sublime2っぽいやつ
- ピーク
- 定義をその場で確認できる
- Hubの注意点
- テンプレートに間違い
- Strings/en-US -> Strings/ja-JP にリネームする!
- テンプレートに間違い
- スクロールバー
- Blend
- サンプルデータ
- デザイン時にサンプルを使って設計できる
- HTML
- ビヘイビアー
- アニメーションの編集機能
- リニア編集できる
- サンプルデータ
- Visual Studio
- Build
- VBの新機能のセッションはないよ
- WebView
- 細かいイベントをとれる
- GoBack, GoForward
- Windows 8.1へ移行すべきか
- Win 8.1
- ListViewのパフォーマンスが5-8%改善
- 使用メモリの削減(XAML)
- Windows 8.1のほうがメールアプリの動作が速い
- 考慮すべきこと
- ターゲットを変える
- 8.1の機能を入れる(必要に応じて)
- 8のコードと8.1のコードの管理
- 分けたほうがいい
- SnapViewは忘れろ
- Win 8.1
- 固定幅から可変になった
* 最少のサイズを定義する(500px規定)
- ApplicationViewStateも忘れてください * 乗り越えよう
- HTML+JavaScriptでのアプリ開発のデモ
- データバインディングとは
- データソースとUIを結合する技術
- 「データバインディングとは2つのデータポイントの同期を保つための技術」- エッセンシャルWPF
- 片方のデータが変化したらもう片方も同じように変化し、逆も同じように行われる
- 主に FrameworkElementクラスとBindingクラスで実現
- BindingTarget
- FrameworkElementクラスの派生クラス
- BindingSource
- 任意のオブジェクト
- データバインディングの二つの課題
- XAMLはプロパティで見た目の設定をする
- 同期するには変化を検知する仕組みが必要
- プロパティだけでは実現できない
- 依存関係プロパティ
- INotifyPropertyChanged/INotifyCollectionChanged
- 同期するには変化を検知する仕組みが必要
- プロパティ指定にとってデータバインディングの指定
- 同期を実現しつつ、オブジェクトの依存関係を表現する
- XAMLで階層構造やプロパティを記述
- マークアップ拡張
- TypeConverter
- FrameworkElement/DataContext
- XAMLはプロパティで見た目の設定をする
- 依存関係プロパティ(DependencyProperty)
- プロパティの値の変化を検知・通知するためのインフラ
- DependencyObject/DependencyPropertyクラスによって実現
- つまり、データバインディングは言語仕様ではなくクラスライブラリによって提供されている
- 統一的な手段
- 依存関係プロパティの実装例
- DependencyPropertyを継承する
- DependencyProperty.Registerメソッドで依存関係プロパティを登録
- INotifyPropertyChanged, INotifyCollectionChanged
- プロパティの変化をBindingTargetに通知するためのインタフェース
- マークアップ拡張
- 属性構文で一部のオブジェクトを指定できるようにするための仕組み
- 冗長な要素構文を使わずにオブジェクトを指定できる
- {}で指定する
- MarkupExtensionのサブクラスだけが指定できる
- コンストラクタの引数またはプロパティでXAMLから値を渡すことができる
- 属性構文で一部のオブジェクトを指定できるようにするための仕組み
- XAMLのプロパティ要素
- XAMLはテキスト
- 型変換が必要
- プリミティブ型→直接変換を試みる
- 列挙型→メンバ名とマッチング
- 型コンバーター→型コンバーター (TypeConverter) による変換
- TypeConverterのメソッド
- 変換可能かどうか - CanConvertFrom, CanConvertTo
- 変換ロジック - ConvertFrom, ConvertTo
- XAMLはテキスト
- FrameworkElement
- すべてのUIのスーパークラス
- Bindingターゲットの指定が行える
- Bindingクラス
- バインディングソースとなるオブジェクトの指定
- Source, ElementName, RelativeSouce
- バインディングソースのプロパティの指定
- Pathプロパティ
- XMLからバインディングソースの指定(WPF)
- XPathプロパティ
- バインディングソースとなるオブジェクトの指定
- Bindingの挙動
- FrameworkElement.DataContextプロパティ
- 子は親のDataContextを参照することができる
- FrameworkElement.DataContextプロパティ
- データフロー
- データバインディングの同期は常に双方向である必要はない
- データフローの指定
- OneWay - BindingSource => BindingTarget
- 同期にはBindingSourceはINotifyProperty(Collection)Changedを実装している必要がある
- TwoWay - BindingSource <=> BindingTarget
- OneTime - BindingSource -> BindingTarget
- OneWayToSource (WPF only)
- OneWay - BindingSource => BindingTarget
- 同期元と同期先のデータ型のミスマッチ
- 同期の際に変換をかける
- TargetNullValueプロパティ (WPF only)
- StringFormatプロパティ (WPF/Silverlight only)
- IValueConverterクラス
- 値の変換のロジックを実装する
- Convert
- ConvertBack (OneWayでしか使わない場合は実装省略可)
- patterns & practice チームの作っているXAML系 platformの開発を行うためのライブラリ
- Prism 4.1
- 複合型アプリケーションの作成を目的
- Regionと呼ばれる領域を定義、いろんなところから画面を流し込む
- Prixm for WinRT
- MVVM + WinRT + α
- MVVM+現在のWinRTに足りないものを補う
- PageとViewModelのマッピング機能
- ViewModelでのページのライフサイクルへの対応
- ICommandの実装であるDelegateCommandを提供
- 非同期処理で使う
- ページ遷移、サスペンドのサポート
- 入力値の検証
- Prism 4.1
- MVVM Support
- VisualStateAwarePageクラス
- ViewModelクラス (ViewModel)
- ページ遷移のコールバック
- サスペンド・復帰時の処理
- BindableBase (Model)
- INotifyPropertyChanged
- ValidatableBindableBase
- バリデーションできる
- ViewModelLocatorクラス
- Viewのクラス名から自動的にViewModelを生成してDataContextに設定
- WinRTの固有機能のサポート
- VisualStateAwarePage + NavigationService
- 状態保存・復元のサポート
- フライアウト
- なぜか標準でサポートされていない
- 設定チャームのコマンドのサポート
- 検索チャームのサポー
- VisualStateAwarePage + NavigationService
- MvvmAppBaseクラス
- Prismのクラスの初期化
- 実際に使う
- Appクラス、PageクラスをMvvmAppBase,VisualStateAwarePageに変更
- などなど
- 結構大変
- プロジェクトテンプレートあります
- Prism App
- Prism App using Unity
- Unity (ゲームじゃないほう)にModelやViewModelのインスタンス管理を任せる
- アイテムテンプレート
- FlyoutView
- Model
- バリデーション付
- Page View
- ViewModelと接続されている
- Search Conract
- UserControl View
- 存在意義がわからない
- 超シンプル
- MvvmAppBase <-[NavigationService]-> VisualStateAwarePage <-[ViewModelLocator]-> ViewModel
- 標準のWindowsストアアプリテンプレート
- クラス多い(とくにCommon以下)
- Prismのテンプレート
- Commonの下にはStandardStyles.xamlしかない
- 共通のコードはPrism側で用意されてる
- 実行すると単純な白紙のページがでる
- GridViewアプリだと大変かもしれないけど、Commonフォルダに縛られたくない場合はアリ
- 標準のよりイケている
- 命名規約がある
- NavigationService
- NavigationService.Navigate("ページ名", args)でページ遷移
- "ページ名"+Page.xamlが呼び出される
- NavigationService.Navigate("ページ名", args)でページ遷移
- ViewとViewModelの接続
- "ページ名"+ViewModelという名前のオブジェクトが自動でDataContextに設定される
- 命名規約はViewModelLocatorクラスからカスタマイズや個別設定が可能
- NavigationService
- あとは育てる!
- How To
- サスペンドへの対応
- 保存したいViewModelのプロパティにRestoreableStateAttributeをつけるだけ
- 入力値の検証
- サンプルがアップされています
- サスペンド時のスクロールバーの位置の保存
- サスペンドへの対応
- Windows 8.1 Previewについて
- 検索コントラクトの挙動が違う
- VisualStateなくなった
- VS2013の標準テンプレートが激変
- API増えた
- XAMLのCLRオブジェクト
- ResouceManagerを使うことでプログラマブルに多言語化できる
- 業務ロジックに依存した視覚制御の配置
- 視覚制御はViewModel側でやる
- リストに該当しているかどうか、該当なしの場合は何を返すかを処理するはViewModelの責務
- コードビハインドはイベントの通知とディスパッチだけ
- M:V:VMはふつう1:1:1になる
- しかし、業務ロジックによっては1:1:1にならない場合がある
- コピペ案件とか
- リストに該当しているかどうか、該当なしの場合は何を返すかを処理するはViewModelの責務
- 視覚制御はViewModel側でやる
- カルチャの定義順
- Invariant
- マニフェストで指定
- ApplicationLanguages.PrimaryLanguageOverride
- 言語コードをBCP-47で指定
- ResourceManager
- 通知
- ViewModelにINotifyPropertyChangedを実装
- JavaScriptでのリソース操作
- WinJSでのDOMの構築
- data-win-res属性にオブジェクトを設定
- 文字列ならinnerHTML、それ以外ならattributesに格納される
- WinJSもXAMLも同じアーキテクチャ上に存在する
- 移行は難しくない
- マネージャーの仕事は言語に依存しないアーキテクチャ作り
- data-win-res属性にオブジェクトを設定
- WinJSでのDOMの構築
- 動的にリソースを変える
- ApplicationLanguages.PrimaryLanguageOverrideを変更
- コントロールのオブジェクト構造をトラバースしつつ、
- ResourceManager.MainResourceMap.GetValueで取得した多言語化リソースを読み込んで反映
- DataTemplateなど、トラバースする必要のないコントロールはTagに値を設定してスキップできるようにしておく
- Visual Studioのモデリングツール
- ER図とコードを同期させることができるし、画像ファイルにも出力もできる
- きっかけ
- NewRelicでサーバー/サービス監視
- 障害時にプッシュ通知する
- ただしiPhoneのみ
- Windows Phone でも受信したい!
- NewRelicでサーバー/サービス監視
- システム概要
- NewRelic (Web Hook) -> Windows Azure Web Sites (Push通知) -> Windows Notification Service (Push通知)
- Web Sitesを選んだ理由
- SSLが無償で使える
- Web Hookを受ける必要がある
- 6月からMobile Serviceでも可能
- C#でコーディングしたい
- Mobile Service ではJavaScriptを使う
- サーバーサイドの実装
- Channel URIの登録を受け付けるAPI
- 端末IDを受け取って保存
- 認証を入れたほうがよう
- WebHookを受けるAPI
- サービス(今回はNewRelic)の実装に従う
- たいていJSONが飛んでくる
- Web Hookはインターネット側から到達可能な場所でないと受信できない
- ローカルネットワークで試したいときはRequestBinというサービスを使うとよい
- 実際のリクエストを見ないとわからない仕様もある
- Web HookのリクエストのJSONをパースしてWNSにプッシュ
- Channel URIの登録を受け付けるAPI
- クライアントサイドの実装
- WNSの認証
- 通知が降ってきたらトースト通知を発行
- Azure Wev Site のデバッガビリティ
- VSから直接ログを確認することができる
- 出力ウィンドウにWeb Siteのログを表示させることができる
- リモートデバッグほしい
- VSから直接ログを確認することができる
- ストアアプリの実装
- 起動時にChannel URIを取得
- アクセスの競合を回避するためにSQLiteに保存
- バックグラウンドタスクの実装
- ストアアプリと共通のコードをライブラリ化
- アプリケーションマニフェストでトリガーを指定
- システムイベントはタイムゾーンでトリガーする
- デバッグに使える
- 今回はプッシュ通知を指定
- システムイベントはタイムゾーンでトリガーする
- Runメソッド中でasyncメソッドを使う場合はDeferrelで待機する必要がある
- Windows Phone Appの実装
- 基本はストアアプリと同じ
- 通知を受信したらトースト通知
- プッシュ通知の配信先やフォーマットが多少異なる
- NewRelicのWeb Hookにバグがある。。。
- Interactive Whiteboard
- 大型 (40-80型)
- ペンや指による入力
- 対応ソフトウェア開発
- タブレットPCで表示が崩れる
- 高DPIによる表示の崩れが原因
- タブレットの小型化、高精細化による高DPI環境の標準化
- Retina 13.3-inchだと16pxが1.8mmぐらいに(小さい!)
- タブレットPCで表示が崩れる
- DPI (Dots Per Inch)
- Windowsでは1-inch = 96px
- コントロールパネルから変更可能(拡大率)
- UIの要素が大きくなる
- 画面領域は小さくなる
- 適切な設定とは?
- ppi(画素密度)が30-40ぐらいが見やすい(好みだけど)
- 解像度が小さいとDPI設定に制限
- High DPI Issues
- UI要素やテキストが切れる
- レイアウトやフォントサイズが不適切になる
- UI要素がぼやける
- 座標空間の位置調整がずれて入力に影響
- 全画面アプリで一部分しか描画されない
- DPI-aware application
- Win32アプリ
- マニフェストで
<dpiAware>true</dpiAware>
- 各種API
- マニフェストで
- Windowsフォーム
- AutoScaleModeプロパティをDpiに
- 開発環境のDPI設定を記憶
- Win32アプリ
- DPI仮想化
- 救済措置的な
- DPI設定に合わせて自動で拡大
- ただし、ぼやける(重要)
- DIP (デバイス非依存ピクセル)
- アプリ内部では環境にかかわらず 1dip = 1/96 inch
- WPFではDIPで計算するため、解像度やデバイスに依存しない
- WPFでDPIを意識しなければならないケース
- WPFの外から取得した座標は非DIPなのでDIPに変換する計算が必要
- ラスター画像
- ベクター画像を用意する or DPIごとに画像を用意
- または…
- Pathを使う
- ベクター形式なのでDIP対応
- Blendなら簡単
- 頂点を打つ
- 曲線に変える
- 微調整
- UIのアイコン作成にも
- モニターごとのDPIスケーリング
- Windows 8.1 Preview の新機能
- ログオン時にモニターごとに最適なDPIをWindowsが判断
- ウィンドウがモニター間を移動すると自動でスケーリング
- つまり、アプリ側では動的なDPIスケーリングに対応する必要がある
- 現状(Preview)ではAPIは公開されているが、WPFアプリのスケーリングは対応していない
- タッチエクスペリエンス
- NumericUpDownコントロールの上下ボタンは指で押せない
- MouseEnter、MouseMoveに頼った動き(ToolTipとか)に注意
- Windows User Experience Interaction Guidelines
- デスクトップアプリ向けのUI/UXガイドライン
- タッチしやすい、快適だと感じる大きさが示されている
- Officeは準拠してる
- タッチ操作とマウス操作で出てくるメニューが違ってたり
- PowerShwll
- すべてがオブジェクト
- .NET, COM, WMIが使える
- ExcelのCOMが全部使える
- Excel方眼紙を見なくてすむ!
- 高階関数が使える
- ネットワークなくてもプログラミング可能
- 連想配列からの
- Webアクセスのコマンドレットが標準に
- PowerShell ISEにIntellisense
- shのキーバインドにしたい
- AutoHotKeyで設定
- ウィンドウを最大化したい
- Terminal2 or ckw
- yumやaptは?
- Chocolatey
- アプリはすべてPowerShellから起動できる
- シャットダウンもできる
- VS拡張機能
- Managed Extensbility Framework
- Managed環境で拡張機能をいい感じに
- MEFでIntellisenseを拡張可能
- IVsTextViewCreationListener
- Ctrl-Spaceに反応するコードを書く
- ICompletionSourceProvider
- ICompletionSourceオブジェクトを作成する
- ICompletionSource
- コード補完のコア部分をを実装する
- IntelliTranslate
- Intellisenseで翻訳するのを作った