艦これ第二期がスタートしたのでスクリーンショットを撮るChrome拡張を作った
8月17日(金)に艦これ第二期がスタートして、FlashからHTML5に移行しました。リニューアルオープンです。
ゲーム画面が 800x480 から 1200x720 になりました。大きい！
それに合わせて艦娘の立ち絵などの画像素材も高解像度化されました。う、美しすぎる！
綺麗になったら艦娘たちのスクリーンショットたくさん撮りたいですね。
という訳で艦これ二期のスクリーンショットを撮るChrome拡張を作ってみました。ボタンひと押しでスクショが撮れます。 (初Chrome拡張たのしかったです)
ぴったりに切り抜けるようになった pic.twitter.com/OP1FYUSsFF
— ざまりん.ふぉーむずのコントリビューター🚲 (@ticktackmobile) August 18, 2018
せっかく作ったので公開します。
制限事項
スクロールしたりウィンドウを縮小していると正しく取れない
Chrome APIでタブの見えている範囲をキャプチャしてゲーム画面部分を切り抜いています。 なのでスクロールするとずれちゃいます。(スクロール量を取得すれば対応可能？)
高DPI環境で使うと正しく撮れない
例えばMacBook Proのような高DPIで画面が拡大表示されている環境。
High DPI環境で悲しいことになった pic.twitter.com/cK3NxCeoKk
— ざまりん.ふぉーむずのコントリビューター🚲 (@ticktackmobile) August 19, 2018
切り抜く範囲をDPIに応じて調整すれば対応できるけど、拡大された画像を縮小し直すことになるので画質劣化しそう。
スクショを撮るたびにいちいち保存場所を選ばされる
作り始める前はFileSystem APIでローカルに保存できると思っていたのですがChrome拡張からは使えないようなので、諦めてファイルとしてダウンロード形に落ち着きました。
保存場所を選ぶダイアログが出ている間も次のスクショが撮れるので連写は可能。
アイコンが無い
せっかく公開したので何か作ります。
試したけどダメだったアプローチ
ゲーム画面を描画しているcanvas要素から直接描画内容を画像化
canvas.toDataURL()しても真っ黒な画像しか取得できませんでした。
ゲーム側で使ってるPixiJS(？)の設定でレンダラーのバッファを保持するように使っていないと取得できない模様。
Xamarin.Formsのトロフィーをもらいました
Xamarin.FormsチームがGitHubリポジトリのコントリビューター宛にトロフィーを贈ってくれました。やったぜ。
I just received the trophy of my contributions, thank you #Xamarin Forms team! pic.twitter.com/vxVVZazJgv
— ざまりん.ふぉーむずのソースコード読むマン🚲 (@ticktackmobile) July 21, 2018
(P3PPPは私のGitHubアカウント名)
(ちなみにトロフィーの形はXamarin Universityの認定トロフィーと同じだったりする)
届くまでの紆余曲折
2018年 5月下旬
David(※)「Xamarin.Formsリポジトリにコントリビュートありがとう！贈り物をしたいのでmailing address(住所)を教えてもらえますか？」 ワイ「(細かいやり取りをするための連絡先をGitHub経由で聞いてるのかな？)、これです(e-mailアドレス)」 David「physical mailing addressを教えて？」 ワイ「ｱｯﾊｲ、ここ宛てでお願いします。」
※Xamarin.Formsのプログラムマネージャー
2018年 7月頭
David「アメリカ国外に発送するには荷受人の電話番号が必要みたい、教えてください。こういうことをするのは初めてで、学びがあります。」 ワイ「この番号でー。」
2018年 7月中旬
UPS(配送業者)「アメリカからの荷物が来てるんですが心当たりあります？住所が市区町村までしか入ってなくてどこに送れば？宛先がMicrosoftアワードセンター(？)になってますが会社受取にします？」 ワイ「その宛先は発送作業した部署か何かですかねぇ、普通に個人宅宛でお願いしますー。」 UPS「あー、Microsoftの従業員ではないんですね、承りましたー。」
数日後着弾
こうして見ると、ほぼ電話番号だけで届いてますね。無事に届いて本当に良かった。
Xamarin.Macのコントリビュータになりました
Xamarin.Macなアプリは作ってないんですけどね。
何故かNSDistributedNotificationCenter.DefaultCenterの型がNSObjectになってるというツイートを見かけたのでPRにしてみたけど通るかな？https://t.co/T2aOtmWp7B
— ざまりん.ふぉーむずのソースコード読むマン🚲 (@ticktackmobile) 2018年6月12日
この時のPRが修正を受けつつマージされました。
同様に戻り値がNSObjectになってしまっているAPI1がたまにあるらしいので、見つけた人はxamarin-maciosのリポジトリにissue登録してあげてください。NSObjectになっている箇所と、正しい型が載っているAppleのドキュメントのリンクを載せてissue登録すれば、バージョンアップのタイミングで対応してくれると思います。
なんだったらTwitterで@ticktackmobileに教えてくれるのでも良いです。
参考までにPRコメントのやりとり(超意訳)
ワイ「NSObjectから正しい型に変更するPR作ったやで」
中の人A「これじゃあ破壊的変更になるから取り込めないやで」
中の人B「API互換性を維持するために#if XAMCORE_4_0みたいなバージョン分岐作るとええで」
中の人C「ブランチ修正しといたで、これでいこか」
中の人D「ちょっとまって、古いバージョンでも正しい型で受け取れるメソッド追加するのはどうやろ」
中の人C「悪くないやん、ええんちゃう」
GitHub「マージしたやで」
ワイ「やったぜ」
#if XAMCORE_4_0の部分は次のバージョン番号によって変わると思うので、新しめのコミットから探して真似すればPRもすんなり通るんじゃないかな。
-
たぶんヘッダーファイルではid型で定義されているのだと思う。↩
ASUS ZenFone 4s MAXでXamarin.Androidの実機デバッグができない場合のトラブルシューティング
ASUS ZenFoneでXamarin.Androidアプリの実機デバッグをする際、「Mono Shared Runtimeのインストールがブロックされて失敗する」というのは既知の問題があります。
Can't deploy on device (Android MarshMallow) — Xamarin Forums
ZenFone 2や3では「Auto-start Manager」アプリのブロッキングを無効化すれば良いらしいです。
ZenFone 4sでも同様の問題が発生しますが、「Auto-start Manager」アプリが無くなっているので解決手順が異なります。
- 「モバイルマネージャー」アプリを開く。
- 「PowerMaster」を開く。
- 「節電オプション」を開く。
- 「自動軌道によりアプリを自動拒否する」をオフにする。
これで OK！
Visual Studio 2017で作成したXamarin.FormsプロジェクトをVisual Studio 2015でビルドする
さて、現時点のVisual Studio 2017(ver. 15.6.5)でXamarin.Formsプロジェクトを新規作成すると結構新しくてイケイケなプロジェクトをはいてくれます。
- packages.configファイルが無い
- 共通コードが.NET Standard 2.0(またはShared project)
これをVisual Studio 2015で開くと...
プロジェクトファイルが読み込めず、ビルドできません。
理由は...
- .NET Standard、ましてや2.0なんて対応してない。
- packages.configに代わり、
PackageReferenceというフォーマットが使われている。VS 2015(というかMSBuild 14では読めない)
逆マイグレーション
VS 2015でビルドできるようにするために
- .NET StandardプロジェクトをPCLプロジェクトで作りなおす。
- iOSやAndroidのcsprojファイルから
PackageReference要素を削る。(参照していたパッケージをメモしておく) - packagesフォルダの中身を削除する(だいたいslnファイルと同じ階層にあるやつ)
- 空のpackages.configファイルを追加する(必要ないかも)
PackageReferenceで参照していたパッケージをNuGetパッケージマネージャで追加しなおす。- アセンブリの参照方法が変わって通らなくなったコードが出た場合は修正する。
まとめ
特別な理由がない限りVS 2015を投げ捨てましょう。そろそろ限界です。
Xamarin.Forms VisualStateManager Support
Xamarin.Forms 3.0.0からVisualStateManager、およびVisualStateが追加されます。
VisualStateManager.GoToState()を呼ぶと対応するVisualStateのSetterが適用される機能です。
これにより、Viewの状態に対応する見た目を宣言的に扱うことが可能となります。
基本的な使い方
基本的な使い方を見てみましょう。入力された文字数に応じてEntryの背景色を変える、新規パスワード入力欄風のサンプルです。
<?xml version="1.0" encoding="UTF-8"?> <ContentPage xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" x:Class="VisualStateManagerSample.BasicSample"> <StackLayout VerticalOptions="Center" Padding="20"> <Label Text="enter new password" /> <Entry x:Name="_entry" IsPassword="true"> <VisualStateManager.VisualStateGroups> <VisualStateGroupList> <VisualStateGroup x:Name="LengthStates"> <VisualState x:Name="None" /> <VisualState x:Name="Short"> <VisualState.Setters> <Setter Property="BackgroundColor" Value="Red" /> </VisualState.Setters> </VisualState> <VisualState x:Name="Medium"> <VisualState.Setters> <Setter Property="BackgroundColor" Value="Yellow" /> </VisualState.Setters> </VisualState> <VisualState x:Name="Long"> <VisualState.Setters> <Setter Property="BackgroundColor" Value="Green" /> </VisualState.Setters> </VisualState> </VisualStateGroup> </VisualStateGroupList> </VisualStateManager.VisualStateGroups> </Entry> </StackLayout> </ContentPage>
VisualStateManager.VisualStateGroupsAttachedPropertyを通じてVisualStateをセットします。
VisualStateGroupsはStyleからセットすることが可能なので、VisualStateを含めてViewの規定のスタイルを作ることができます。
using System; using System.Collections.Generic; using Xamarin.Forms; namespace VisualStateManagerSample { [Xamarin.Forms.Xaml.XamlCompilation(Xamarin.Forms.Xaml.XamlCompilationOptions.Compile)] public partial class BasicSample : ContentPage { public BasicSample() { InitializeComponent(); VisualStateManager.GoToState(_entry, "None"); _entry.TextChanged += (s, e) => { if (string.IsNullOrEmpty(_entry.Text)) { VisualStateManager.GoToState(_entry, "None"); return; } var length = _entry.Text.Length; if (length <= 4) { VisualStateManager.GoToState(_entry, "Short"); return; } if (4 < length && length < 8) { VisualStateManager.GoToState(_entry, "Medium"); return; } if (length >= 8) { VisualStateManager.GoToState(_entry, "Long"); return; } }; } } }
コードビハインドではEntryのテキストが更新されるたびに、VisualStateManager.GoToState()で長さに応じたVisualStateに遷移しています。
同じViusalStateに遷移した場合はSetter適用がスキップされるため、パフォーマンスを気にして厳密に管理する必要はありません。
このサンプル実行結果はこんな感じ。
VisualStateGroup
VisualStateはVisualStateGroupにまとめられた中で排他的に遷移します。
<VisualStateGroupList> <VisualStateGroup x:Name="Gourp1"> <VisualState x:Name="On" /> <VisualState x:Name="Off" /> </VisualStateGroup> <VisualStateGroup x:Name="Gourp2"> <VisualState x:Name="None" /> <VisualState x:Name="Hightlited" /> </VisualStateGroup> </VisualStateGroupList>
上のようにVisualStateが設定されたViewに対して次の順にGoToSatateを実行した場合...
VisualStateManager.GoToState(view, "On")VisualStateManager.GoToState(view, "Highlited")VisualStateManager.GoToState(view, "Off")
結果は次のようになります。
VisualStateManager.GoToState(view, "On")- Group1/OnのSetterが適用される。
- Group2のSetterは何も適用されない。
VisualStateManager.GoToState(view, "Highlited")- Group2/HightlitedのSetterが適用される。
- Group1/OnのSetterは解除されない。
VisualStateManager.GoToState(view, "Off")- Group1/OnのSetterが解除される。
- Group1/OffのSetterが適用される。
- Group2/HightlitedのSetterは解除されず、適用されたまま。
「Setterが適用されていない初期状態に戻す」ということがしたい場合は、Setterを持たないVisualStateを用意しておくと良いです。
Style、Trigger、VisualStateの比較
Xamarin.FormsにはSetterクラスの集まりによってVisualElementのプロパティを方法として、StyleやTriggerが以前から存在します。
これらとVisualStateにはどのような違いがあるでしょう。
(便宜上Setterの塊をカタカナ表記でスタイル呼ぶことにします)
Style
- 特定のクラスに対して規定のスタイルを設定できる。
- 他のStyleを引き継ぐことができる。(
BasedOn)
Trigger
- イベントの発火やプロパティの変化を契機にVisualElementのプロパティをセットする。
- EnterActoins、ExitActionsを実行できる。
VisualState
- プロパティの設定値をVisualStateという纏まった単位で管理できる。
- VisualStateを変更する判定処理とVisualStateによって変更されるスタイルが分離できる。
状態遷移の判定処理とスタイルの分離がVisualStateの大きな特徴と言えるでしょう。
例えば独自のViewを定義する場合、取りうるVisualStateの名前と条件を公開しておけば、利用者は自分のアプリに合ったスタイルを自由に設定することができます。
規定のVisualState
実は、全てのViewは暗黙的にNomal、Disabled、Focusedの3つのVisualStateに遷移します。
それぞれのVisualStateへ遷移するタイミングは以下の通り。
- Nomal
VisualStateManager.VisualStateGroupsAttachedPropertyが更新されたとき。- Viewの
IsEnabledプロパティがtrueに変更されたとき。 - Viewの
IsFocusedプロパティがfalseに変更されたとき。
- Disabled
- Viewの
IsEnabledプロパティがfalseに変更されたとき。
- Viewの
- Focused
- Viewの
IsFocusedプロパティがtrueに変更されたとき。
- Viewの
(フォーカス中にIsEnabled = falseしたらマズいような……、最終的にDisabledになるのかNormalになるのか、Rendereの実装に依存する？)
本当にVisualStateが変更されているか確かめてみしょう。
こんな感じのXAMLを書きます、自分ではVisualStateManager.GoToState()しません。
<?xml version="1.0" encoding="UTF-8"?> <ContentPage xmlns="http://xamarin.com/schemas/2014/forms" xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml" xmlns:local="clr-namespace:VisualStateManagerSample" x:Class="VisualStateManagerSample.CommonStatesSamplePage"> <ContentPage.Resources> <!-- Normal <-> Disabled 確認用 for Image --> <Style TargetType="Image" x:Key="StatusIconStyle"> <Setter Property="VisualStateManager.VisualStateGroups"> <VisualStateGroupList> <VisualStateGroup x:Name="CommonStates"> <VisualState x:Name="Normal"> <VisualState.Setters> <Setter Property="Source" Value="{local:ImageResource VisualStateManagerSample.Images.online.png}"/> </VisualState.Setters> </VisualState> <VisualState x:Name="Disabled"> <VisualState.Setters> <Setter Property="Source" Value="{local:ImageResource VisualStateManagerSample.Images.offline.png}"/> </VisualState.Setters> </VisualState> </VisualStateGroup> </VisualStateGroupList> </Setter> </Style> <!-- Normal <-> Disabled 確認用 for Label --> <Style TargetType="Label" x:Key="StatusCaptionStyle"> <Setter Property="VisualStateManager.VisualStateGroups"> <VisualStateGroupList> <VisualStateGroup x:Name="CommonStates"> <VisualState x:Name="Normal"> <VisualState.Setters> <Setter Property="TextColor" Value="Green"/> </VisualState.Setters> </VisualState> <VisualState x:Name="Disabled"> <VisualState.Setters> <Setter Property="TextColor" Value="Gray"/> </VisualState.Setters> </VisualState> </VisualStateGroup> </VisualStateGroupList> </Setter> </Style> <!-- Normal <-> Focused 確認用 for Entry --> <Style TargetType="Entry" x:Key="EntryStyle"> <Setter Property="VisualStateManager.VisualStateGroups"> <VisualStateGroupList> <VisualStateGroup x:Name="CommonStates"> <VisualState x:Name="Normal"> <VisualState.Setters> <Setter Property="BackgroundColor" Value="Green" /> </VisualState.Setters> </VisualState> <VisualState x:Name="Focused"> <VisualState.Setters> <Setter Property="BackgroundColor" Value="Orange" /> </VisualState.Setters> </VisualState> </VisualStateGroup> </VisualStateGroupList> </Setter> </Style> </ContentPage.Resources> <StackLayout Padding="20" Spacing="30"> <Label Text="CommonStates Sample" /> <!-- SwitchでImageとLabelのIsEnabledを切り替える --> <Grid ColumnSpacing="20"> <Grid.RowDefinitions> <RowDefinition Height="*" /> <RowDefinition Height="*" /> </Grid.RowDefinitions> <Grid.ColumnDefinitions> <ColumnDefinition Width="Auto" /> <ColumnDefinition Width="*" /> </Grid.ColumnDefinitions> <Image Grid.Row="0" Grid.Column="0" Grid.RowSpan="2" Style="{DynamicResource StatusIconStyle}" HeightRequest="60" WidthRequest="60" IsEnabled="{Binding IsToggled, Source={x:Reference _onlineSwitch}}" /> <Label Grid.Row="0" Grid.Column="1" Style="{DynamicResource StatusCaptionStyle}" Text="@ticktackmobile" VerticalTextAlignment="End" IsEnabled="{Binding IsToggled, Source={x:Reference _onlineSwitch}}" /> <Switch x:Name="_onlineSwitch" Grid.Row="1" Grid.Column="1" IsToggled="true" /> </Grid> <Entry x:Name="_entry" Style="{DynamicResource EntryStyle}" Placeholder="IsFocused: true = Orange, false = Green" /> </StackLayout> </ContentPage>
local:ImageResourceはEmbeddedResourceから画像を読み込む
ためのXAMLマークアップ拡張です。(Guideに載ってるやつ)
実行結果がこちら。
Xamarin.FormsのVisualStateManagerで規定のVisualStateを確認するサンプル。 pic.twitter.com/ZJ6saTlTp8
— ざまりん.ふぉーむずマン🚲 (@ticktackmobile) March 22, 2018
Xamarin.Forms 3.0.0-pre2ではバグでIsFocusedを変更したときのVisualStateが逆になってます。(修正取り込み済み)
意図しないVisualStateの遷移を防ぐためNomal、Disabled、Focusedを使用しないのが無難ですかねー。
Xamarin.Formsにコントリビュートしよう
先日、Xamarin.FormsのVisualSateManagerの解説を書いている途中で、バグを見つけて修正PRを投げました。 せっかくなのでどんな感じだったのか共有します。レッツ貢献！
Xamarin.FormsのVisualStateManagerで規定のVisualStateを確認するサンプル。 pic.twitter.com/ZJ6saTlTp8
— ざまりん.ふぉーむずのソースコード読むマン🚲 (@ticktackmobile) March 22, 2018
「Entryの色が逆じゃね？」と思ったアナタ、鋭い！！Xamarin.Formsのバグです！
— ざまりん.ふぉーむずのソースコード読むマン🚲 (@ticktackmobile) March 22, 2018
この件。
概要
- バグを見つける
- ソースコードの問題個所を確認する
- Reproductionを用意する
- Issueを登録する
- Pull Requestする
- 自動テストがコケる
- 取り込まれる
バグを見つける
Xamarin.Forms 3.0.0-pre2を使って、暗黙的に変化するVisualStateのサンプルコードを書いていたところVisualElement.IsFocusedが変化したときの挙動がおかしい事に気づきました。
ソースコードの問題個所を確認する
条件演算時が逆になってます。修正も簡単なのでバグ報告と一緒に修正PRも投げることにしました。
// 実際のコード VisualStateManager.GoToState(element, isFocused ? VisualStateManager.CommonStates.Normal : VisualStateManager.CommonStates.Focused); // 正しくはこう //VisualStateManager.GoToState(element, isFocused // ? VisualStateManager.CommonStates.Focused // : VisualStateManager.CommonStates.Normal);
Reproductionを用意する
バグ報告にあたってReproduction、つまり最小の再現環境を用意します。 バグ報告者、Reproductionは義務です。え、Reproductionが無い？ZAPZAPZAP!次のバグ報告者はきっとうまくやってくれるでしょう。
もともとサンプルコードを書いていたところだったので、関係ないところを削ってGitHub置いておきます。
Issueを登録する
Xamarin.FormsのリポジトリにはIsuue登録のテンプレートがあります。
### Description 説明を書きます。 ### Steps to Reproduce 再現手順を書きます。 1. 2. 3. ### Expected Behavior 期待する動作を書きます。 ### Actual Behavior 実際の動作(バグ挙動)を書きます。 ### Basic Information バグが発生する環境のバージョンなどを書きます。関係ないのは削ってもOK。 - Version with issue: - Last known good version: - IDE: - Platform Target Frameworks: - iOS: - Android: - UWP: - Android Support Library Version: - Nuget Packages: - Affected Devices: ### Screenshots 見た目に関する問題の場合はスクリーンショットがあると良い。 ### Reproduction Link 最小の再現環境へのリンクを張ります。
実際に登録したIssueがコチラ
バグが報告されると中の人がTriageというGitHubのProjectsに乗せて行程管理するみたい。 「Ready For Work」にあるやつは修正PR受付中かな？
Pull Requestする
Pull Requestにもテンプレートがあります。
### Description of Change ### 変更内容の説明を書きます。 ### Bugs Fixed ### 修正するIssueの番号を書きます。 ### API Changes ### Publicなクラスやメソッドが増えたり減ったりシグネチャが変わったりする場合は列挙します。何も無い場合はNoneで。 ### Behavioral Changes ### 挙動が変わる場合は列挙します。何も無い場合はNoneで。 ### PR Checklist ### PRするときにやることリスト。 - [ ] Has tests (if omitted, state reason in description) - [ ] Rebased on top of master at time of PR - [ ] Changes adhere to coding standard - [ ] Consolidate commits as makes sense
(「Checklistは自己申告なのか？」とか「あからさまにbool逆だっただけなのにテストいるのか？」と悩んだ結果、とりあえず未チェックのままPRしたら結局そのままマージされてしまった。)
実際のPull Requestがコチラ
masterリポジトリ充てにPRしたところ、リリース用ブランチ(3.0.0)宛てに変えてくれと言われる。分岐点までresetしてから3.0.0ブランチの先頭にrebaseし、GitHubの機能で宛先を3.0.0ブランチに変更。
自動テストがコケる
気が付いたら自動ビルドが走っていて(中の人が手動でキックするっぽい？)、数十分後に自動テストが走っていました。 次の日、「UITestxxxxが失敗した」とコメントがついてました。
取り込まれる
件のUITestを確認すると私の修正とは関係なく(そりゃそうだ)、typo修正が不完全でAutomatonId不一致で失敗しているだけでした。 その旨を返答すると数時間後にマージされました。(見返すと英文間違っててヤバイ)
反省
- 一行程度の修正でも横着せずにブランチを切る。
- rebaseが面倒になった。
- CheckListは自分でチェックしていい。
- 雰囲気英文は見直す。
おまけ
- CONTRIBUTING.md
- バグ報告・修正、機能改善提案の仕方
- A Beginner's Guide for Contributing to Xamarin.Forms | Xamarin Blog
- バグ修正の仕方、UITestの追加方法も書かれている。Bugzilla前提であるもののIssueTrackerをGitHubに置き換えればIssueからに対しても同様なはず。
