Linearstar Logs

こないだひっそり公開した M4Toon2 ですが、 コントローラで強光沢または厨光沢の加算色が反映されず、 逆に乗算色が乗算と加算に同時に影響してしまうバグを見つけたので、さっくり直しておきました。 それ以外の更新はありませんので、使ってる方がいれば入れ替えておいてください。

MMD コーナーだったはずがこんなものが追加されてしまいました。もう 3DCG コーナーでいいですね。

肝心の内容に関してですが、C# で Metasequoia のプラグインが書ける何かと、そのサンプルです。 ソースは GitHub に投げてあるので、興味のある方はどうぞ。

ニコニコでいろいろ投下してたんですが、いろいろ増えてきたのでいろいろまとめました。
といっても、MMM のプラグインなんですが。
これから更新があったらまたここに流そうかと思います。

【MMM】いままで出したプラグイン一斉アップデート【プラグイン配布】 ‐ ニコニコ動画(原宿)

http://gist.github.com/1609233

システムの Turnstile 遷移は画面の左端よりも少し奥を起点にして回転するのに対し、
Toolkit に含まれる TurnstileTransition は画面の左端ちょうどを起点にして回転するため違和感があるので、
それを補正するためのラッパーを作りました。

TurnstileTransition を XAML 上で指定しているところをそのまま入れ替えられます。
-0.1 の数字は適当なので、まだ違和感が感じられる場合は最適な数字を教えてください。教えてください。

WP7 Development Tips Part 1
27 Oct 10
By Kevin Marshall

http://blogs.claritycon.com/kevinmarshall/2010/10/27/wp7-development-tips-part-1/

のゆるふわ翻訳です。 Mango が出る前の記事ですが、参考になるでしょう。

パフォーマンスはあらゆるアプリにおいて我々が最も多くの時間をかけるものです。
携帯電話向け開発はデスクトップ向け開発とは少々違う側面があります。
デスクトップ向け Silverlight では微小な違いでしかないチューンも、
電話向け Silverlight では非常に大きな違いを生むこともあります。

電話における開発ではリソースの利用をいかに節約し、有効活用するかが大きな課題となります。
開発者はバインディング、レイアウト コントロール、依存性注入などの便利で手軽な要素を使うことに対するパフォーマンス的トレードオフについて十分に理解しなければなりません。
私が最初電話向けアプリを制作する際、nRoute および MVVM、Resource Location、Messaging、Navigation などの素敵な要素を活用するのをとても楽しみにしていました。
あらゆる物に対してバインディングを使い、コードビハインドを最小限にし、強力なデザイナサポートを備え、動的にサービスやモデルを解決するこの疎結合アーキテクチャを完璧だと思っていました。
しかし実際のところ、それは一般的に電話上では高いパフォーマンスを発揮することはありません。
もしあなたが外部のフレームワークを使用しているなら、パフォーマンス的トレードオフについて検討し、本当にそれが必要かどうかを慎重に考えるべきです。
複雑なデスクトップ上では素晴らしい動作を実現する者も、電話上ではそれほど素敵な動作をしません。
電話が iPhone、WP7、または Android であるかどうかなどにかかわらず、最適な動作をするようコードを書かなければなりません。

Silverlight は「電話上で、いままでと同じ Silverlight」であることを要求されました。
それは API については実現しているのですが、実際のランタイムにおいてはあまりそうであるとは言えません。
Silverlight 3 をベースにいくつかの要素を追加した全く新しいランタイムなので、いくつかのコードは同じパフォーマンスでは動きません。

私はたくさんの「ぬるぬるなスムーズスクロール」およびその他のパフォーマンスに関する Tips の記事を見ました。
これらの Tips は少々一般化されすぎています。
もしあなたが本当にパフォーマンスを最適化したいのであれば、しっかりと問題を認識しそのアプリに合う正しい対処法で切り込まなければなりません。
しっかりテストしベンチマークを取ってください。
プロファイラを使わなければ非常に気づきづらい問題もありますが、あなたのできる最大限のことをしてください。
また一つ注意してほしいのは、サードパーティのアプリにおけるスクロールは現時点ではあまり良くありません。
OS ネイティブのアプリは別の UI フレームワークを使用しているため、もしあなたがネイティブのスクロールほどぬるぬるなスクロールを実現できなくても気を落とすことはありません。多分あなたのせいではないです。
そのうち、サードパーティアプリにおける動作は改善されるかもしれませんが、それにはランタイムの改良がより必要になります。現時点ではこれは新しいプラットフォームの第一バージョンにすぎないのですから。

最後に、これらの考え方は Twitter や Facebook のような、多量のネットワーク通信をし、たくさんの、あるいは複雑な項目の一覧を画面に表示するようなアプリに対するものです。
2 スクリーン単位変換アプリのような単純なものはそのままでも速いためあまり最適化について考える必要はないでしょう。

さて、あなたのアプリに使える Tips は、次のようなものが考えられます。

• データバインディングはいつだって直接値を設定するよりも遅いです。
  バインドする必要が無いのであれば、バインドを避けることを検討しましょう。
  私は積極的に MVVM パターンを使用しようとバインド可能な ApplicationBar を作成する人たちを多く見てきました。
  もっと気軽にイベントハンドラを書いたり、直接値を設定してください。
  パターンにガチガチにあてはめなくても、コードの再利用性を向上する方法は他にもあります。
  もしあなたがアニメーションを使用しつつバインディングを使用しデータをセットしたいと思うのなら、残念ながら多くの場合アニメーションは飛ばされてしまいます。
  単純にアニメーションするのに必要最低限のデータをセットし、アニメーションが完了してからバインドすることを考えてみてください。
• 上で言及した通り、同じパターンを使用することのトレードオフについて考えてみてください。
  メンテナンス性は上がるかもしれませんが、高パフォーマンスなコードはあまり見た目が良くないこともしばしばあります。
  柔軟性を持ってください。よく考え、アプリの部分部分でやりたいことに最適な近道を使用しましょう。
  これは決してクソコードを書けと言っているわけではなく、パターンの完璧な実装に囚われてパフォーマンスが失われてしまうのでは本末転倒であるということです。
  エンドユーザが目にするのは画面に映ったものです。コードではありません。あなたが MEF を使ったり格好良いメッセージングフレームワークを使ったりしても相手にとっては本当にどうでも良い事です。
• コンバータはアプリを低速化させます。
  モデル、あるいはビューモデルに表示用のプロパティを用意しましょう。
  小さな変更ですが、電話では有効な最適化です。

• テンプレート展開はとても遅いです。
  もし ItemTemplate にたくさんの Visibility コンバータがある ListBox があるなら、
  いくつかの理由によりパフォーマンスは劣悪となります。
  まず、すぐ非表示になるアイテムのテンプレートをパースする必要があります。
  さらに、コンバータを使用することは低速化の原因です。
  これを最適化するにはいくつかの策が考えられます:

  • テンプレート内の要素を減らすことに挑戦してください。これはいつでも最初に挑戦すべきものです。
    もしリスト内の項目に対して同じ固定されたテンプレートを使用できないのであれば、リストをもっと概要的な表示にし、別の詳細を表示する画面にリンクしましょう。
    Twitter アプリが良い例です。リスト中でテキスト中にリンクをパースしたり、写真を展開したりしません。
    Facebook アプリの場合はテキスト中のリンクをパースするためより低速ですが、Facebook 的な体験を実現するために必要なのでしょう。
  • もし複数のテンプレートを使う必要があるのであれば、リスト項目をカスタムコントロールにし、余計なレイアウト作業を減らすため必要な要素を動的に生成するようにしましょう。
    またこれは他のバインディングや余計なコンバータを減らすことができます。必要なバインディングはたった一つです。
    コントロールをコードで生成するのは XAML から生成するのより速いです。
    代わりにデザイナサポートが受けられずメンテナンス性が落ちますが、まずデザイナサポートについては
    どうせ Blend やデザイナなんて使わない人たちばかりなのでその点はあまり問題ないでしょう。
    また、コード内での生成の場合はコントロールへ参照を変数として持っておけますし、項目のリサイクル時に
    不要なデータが来たら切り捨てたり別のデータが来たら再配置したり思えば思うほど思ったときに思った通りに再利用することも簡単になります。
    もう一つの選択肢としては、全部読み込まずに [もっと読む] ボタンをリストの末尾につけることです。
  • UI スレッド上の作業を減らすことは非常に重要です。
    タッチイベントを拾うのは UI スレッドですので、UI スレッドで作業中に触られた場合はそれを拾うことができません。
    UI 要素に直接関わること以外のすべては別のスレッドで行ってください。
    少しの作業はしてもいいかもしれませんが、まずはバックグラウンド作業の分離に挑戦すべきです。

  • people hub のようないくつかのアプリのリストはヘッダやフッタを持っています。
    これを実現するためにもし ListBox のテンプレートを作り直せば、仮想化は失われてしまいます。
    仮想化を維持したまま実現するためには、いくつかの方法があります:

    • 一番簡単なのはバインドしているリストにヘッダやフッタ用のダミーアイテムを挿入することです。
      そして ListBox の継承コントロールを作り、ヘッダやフッタ用のテンプレートを取るプロパティを作り、
      それを PrepareContainerForItemOverride 内でダミーに対してテンプレートを適用します。
    • 全部のリストにダミーを追加するのが嫌であれば、代わりに内部にコレクションを持ち
      それにヘッダやフッタのコントロールを付け加えるコレクションを作り、それを使用するのがいいでしょう。
      また、ヘッダやフッタ以外にも、「読み込み中です」や「項目はありません」などの表示にも使えるでしょう。
    • PrepareContainerForItemOverride をオーバーライドするとコンテナのリサイクルにおける不都合があることもあるようです。
      そういう時は、オーバーライドする代わりに一つのテンプレートを持ち
      ヘッダやフッタ項目ではないときに Visibility を変更させると良いでしょう。
      これは自分で試してみるべきものの一つです。
    • (訳注: 現在は Silverlight Toolkit for Windows Phone に含まれる LongListSelector の IsFlatList, ListHeader などを使用しても実現できます。)

  • アプリが入力に対してすぐに反応するようにするよう努力してください。
    ユーザが何かしたときはすぐに処理をする必要があります。
    もし何かをロードする必要があるときは、読み込みインジケータを表示してください。
    例えば表示に少々時間のかかる複雑なリストがあるとき、インジケータを表示してからリストをバインドしなければ、
    表示までにタイムラグを感じることになります。

  • トランジションについて以前書きましたが、アプリはトランジションを使い、
    またそういったアニメーションがどういった場面でどう有効なのかを考える必要があります。
    アニメーションは Metro における重要な部分です。
  • 要素のヒットエリア (タッチに反応する範囲) について考えましょう。
    アプリをデザインする際はマウスカーソルと指の違いを意識する必要があります。
    エリアは最低でも 40x40 あれば大人の指に丁度良いそうです。
    またエリア同士の間隔が十分にあるかどうかも忘れないようにしましょう。
    ユーザが間違った項目をタップして違う画面を開き無駄に戻るボタンを押すなどという手間が発生しないようにしましょう。
  • 4 項目以上の Pivot があるとき、SelectedIndex を tombstone 時に保存するときは
    OnNavigatedTo で復元できないことに注意する必要があります。
    Pivot はこの時最初、次、そして最後のアイテムを生成しますので、3 つめのアイテムに設定しようとすると例外が発生します。
    もし 4 項目以上の Pivot の SelectedIndex を復元したい場合は OnNavigatedTo で保存しているインデックスを受け取り、
    変数に保存し、Loaded イベントで SelectedIndex に設定するようにする必要があります。
  • あなたはいつでも PhoneApplicationService.Current.StartupMode が Activated であるかどうかをチェックすることで
    tombstone からの復帰であるかどうかを確認できます。私は tombstoning のコンセプトは WP7 開発においてナビゲーションフレームワークやスクロールパフォーマンスをさしおき一番嫌いかもしれません。
    なぜ開発者が tombstone の責任を負わなければならないのか本当に理解できません。
    それはともかく、他のアプリを起動するタスクや Chooser がアプリを tombstone するので、それによって副作用が発生しないよう注意する必要があります。
    (訳注: Mango では dormant 状態になります。)
  • いろいろなキーボード (SIP) レイアウトがあります。
    TextBox の TextScope を変えることで URL、メールアドレス、電話番号、検索などそれぞれに特化したキーボードを使用することができます。
  • 現在、生ソケットを扱う方法がないので、チャットのようなアプリを作るのは難しいでしょう。
    ゲッホFacebook Chatゴホゴホ
    (訳注: Mango ではソケットが扱えます。)
  • もしページを素早く読み込みたければ、Loaded イベントをするまで何もしないようにしましょう。
  • Bing Maps を起動するタスクはないため、もしドライビングナビを表示したければ virtual earch web service などを使用しデータを取得する必要があります。
    (訳注: Mango では Microsoft.Phone.Tasks.BingMapsTask が存在します。)
  • また、コンパス API、カメラデータの直接取得、Bluetooth API、カレンダーへの項目の追加、Video Chooser、アラートダイアログのカスタマイズ、バックグラウンドでのアプリの動作、コピー＆ペースト、ページ履歴の編集、GIF のデコード (ImageTools を使用しての表示は可) などができません。
    いくつか足りないと思うものもありますが、それでも私は Xcode と Obj-C を使うよりも Visual Studio および C# を使いたいと思います。
    Silverlight チームは頑張ったと思います。UX 中心のアプリを作るための良いフレームワークです。
    (訳注: Mango ではコンパス API、カメラデータの直接取得、バックグラウンドでの限定的な動作、コピー＆ペーストは可能です。)

Windows Phone 7 向けのスラド閲覧アプリがことごとく微妙だったのと、/.j のアプリはまだなかったので、 自分でアプリ作りました。
本家 /. と /.j 両方に対応しております。同時には見れませんが。
見るだけです。書けません。

主な機能はリンク先にある通りです。
転載しますと、

特徴:
- 最近のストーリー、セクション、みんなの日記などから記事を探す
- 記事のタグから関連した記事を探す
- 共有、お気に入り、ブラウザで記事を開く
- 記事についているコメントをツリー形式で見る
- スラッシュ国民投票のコメントおよび結果を見る
- アプリをスタートに固定し最新ストーリーの記事名をタイルで通知
- セクションをスタートに固定しそのセクションの最新ストーリーの記事名をタイルで通知

試用中は以下の機能が制限されます:
- 記事一覧における次のページの取得

となっておりまして、ご覧のとおり試用中でも記事がそんなにたくさん辿れない程度の弊害しかないのでそれほど困らないと思います。
よろしく。

Microsoft.Windows.Shell Namespace .NET Framework 4

Contains types that provide managed code access to the enhanced functionality of the Windows 7 taskbar, and enable Windows Presentation Foundation applications to interact with the non-client area of a window.

あつくないですか

Card.ly が消滅していることに今更気づいたので、About を修正しました。

なんとかしました。 ついでにツールページのツール名もなおしておきました。