2020-06-16

GitHubのmasterブランチはmainブランチ？

xamarin

[JP]The English translation is next to the Japanese. Please scroll down.

GitHubのmasterブランチはmainブランチ

GitHubのmasterブランチは、そのソースコードの大元のブランチです。

git-flowなどの流儀では、masterブランチは直接変更せず、developブランチを切って、更に変更内容ごとにfeatureブランチを切り、そこで変更が終わったらdevelopブランチにマージして、さらにリリースするときにはreleaseブランチにマージしリリース作業をします。

そして、リリースしたらreleaseブランチから、masterブランチとdevelopブランチにマージしてみたいな感じにします。

もちろん、ここでいう「master」は、masterディスクとかmasterファイルとかと同じ意味の「master」です。

マスターファイルは日本語で言えば、原簿とか基本ファイルと呼ばれているので（というかマスターファイルで通じるけどね）、あえて、masterブランチを日本語化するならば、原分岐とか基本分岐とかになるのでしょうか。

それくらい大切なmasterブランチですが、最近の流れでは「master」ではなく「main」と命名することがあるようです。

例：

github.com

これ、docsの方はmasterブランチで引用していて、ことごとくリンクが404になってしまうので、最近変わったようです。

EssentialsのShareのdocsで気づいてプルリクしたけど、これ、shareだけじゃなくて、Essemtials関係のdocs全部ですね。

docs.microsoft.com

ほぼすべてのページで、最後にAPI Source codeでgithubのmasterブランチを引用しています。

「main」ブランチでもいいといえばいいのですが、この「master」は、master/slaveのようなslaveと対をなすものではないので、そのままでもいいような気もしなくもないです。でも、masterからmaster/slave想像しちゃうっていうのならば変えるのがいいのかな（この部分を議論したい訳じゃないので、深追いをするつもりないです）。

ただ、私見ですが、先ほどの日本語訳からの逆翻訳した「original」ブランチの方が「main」ブランチよりもしっくりくるかなー。

あとは、「base」ブランチとかかな。

[EN]

From now on, will the master branch on GitHub be called the main branch?

The master branch on GitHub is the main branch in its source code.

In the "git-flow" style, you don't change the master branch directly, but instead use the develop branch, and then cut a feature branch for each change, where the change is done, and then and merge it into a develop branch, and release it when you release more. branch and work on the release.

Then, when you release, you merge them into the master branch and the develop branch from the release branch, and so on.

Of course, the "master" here is the same as the master disk and the master file.
In Japanese, the master file is called "original file" or "basic file", so if you were to Japaneseize the master branch, it would be "original branch" or "basic branch".

Although the master branch is that important, it is sometimes called "main" instead of "master" in recent years.

For example:

github.com

This seems to have changed recently, as the docs are quoted in the master branch, and the links are 404 at every turn.

I noticed this in the Share docs in Essentials and pulled it, but it's not just share, it's all the Essemtials-related docs, not just share.

docs.microsoft.com

Almost every page cites the master branch of github in the API Source code at the end.

I wish I could say that the "main" branch is fine, but the "master" is the master It's not a counterpart to a slave like /slave, so I think it's fine as is. It's not impossible. But if you're going to imagine master/slave from master, then changing it is a good idea.

If you're going to imagine master/slave from master, I'd change it (I'm not trying to argue this part, so I won't pursue it).

But in my opinion, the "original" branch, back-translated from the Japanese translation above, feels better than the "main" branch.

Then there's the "base" branch and so on.

2020-06-11

Xamarin Forms の ListView でコンテキストサイズを変更しても行の高さが更新されない

xamarin

[EN]

Xamarin Forms ListView Row Height Does Not Update When Changing Context Size

I've been having trouble creating iOS apps in Xamarin. It is.

That's why, in ListView and elsewhere, you can increase the number of characters in each element, and so on, to make the content more interesting by repetition. The problem of keeping the height of the ListView rows the same when the height is dynamic is.
This only occurs on iOS and the same XAML definition, and the same code, but on Android. This does not happen.

The problem is that when displaying a list with different content heights in a ListView, the This is confused with the issue of not being height per content. This problem can be solved on iOS by setting it to true with the HasUnevenRows property.

docs.microsoft.com But the problem is when each element seems to change after it's displayed. As far back as 2015 or so, we've been asking questions in stackoverflow and Xamarin's It existed as a GitHub issue. The following is a clear description of the issue.

github.com

A valid method of targeting that we are currently able to see is to add an ItemSource to the ListView's The idea is to execute the following two lines when the binding element is changed (on iOS, the Only!)

            if (this.Parent is ListView list)
            {
                list.HasUnevenRows = !list.HasUnevenRows;
                list.HasUnevenRows = !list.HasUnevenRows;
            }

However, if you use this method, when you change the HasUnevenRows property and revert back to The entire ListView is flickering.

However, there is a bit of hope for solving this problem.

You can find this as a "To do-High impact" on GitHub at Xamarin.Forms The issue was posted 5 days ago on.

github.com

f:id:hatsune_a:20200611080913p:plain

github.com

I hope this will help you work things out.

[JP]

Xamarin Forms の ListView でコンテキストサイズを変更しても行の高さが更新されない

Xamarin.FormsでiOSアプリを作成しているときにずっと困っていることがあります。

それが、ListViewなどで、各要素の文字数を増やすなどして折返しによりコンテンツの高さがダイナミックに変わるようなときにListViewの行の高さが変わらないという問題です。

これは、iOSでのみ発生して同じXAML定義、そして同じコードでもAndroidでは発生しません。

この問題は、異なるコンテンツの高さをもったリストをListViewで表示したときにコンテンツごとの高さにならないという問題と混同されます。この問題はHasUnevenRowsプロパティとtrueにすればiOSでも解決します。

docs.microsoft.com

しかし、問題は表示した後に各要素が変化するようなときです。古くは2015年くらいからstackoverflowでの質問やXamarinのGitHubのissueとして存在しました。その中で、問題の説明がわかりやすいものが次のものです。

github.com

現在確認できている有効な対象方法は、ListViewのItemSourceにBindingしている要素に変更があったときに次の２行を実行することです(iOSのときだけ！)

            if (this.Parent is ListView list)
            {
                list.HasUnevenRows = !list.HasUnevenRows;
                list.HasUnevenRows = !list.HasUnevenRows;
            }

しかしこの方法を採用した場合、HasUnevenRowsプロパティを変更して戻すときにListView全体がちらついてしまいます。

しかし、この問題の解決に少しだけ希望があります。

Xamarin.FormsのGitHubで「To do-High impact」としてこの問題が5日前に掲載されました。

github.com

f:id:hatsune_a:20200611080913p:plain

github.com

これで解決に向かってくれるといいですね。

2020-06-09

iOSアプリビルド用のプロビジョニングプロファイル（Provisioning Profile）が設定できなかった件

xamarin

iOSアプリを作成するときに、開発用証明書、配布用証明書に加えて、アプリごとのプロビジョニングファイルを開発環境のMacOS上に登録しなければなりません。

それぞれのファイルはダウンロードしてダブルクリックすれば所定のアプリに連携されて、キーチェーンストアに登録されていきます。

それぞれ１年という期限もあるので、毎年同じ時期にApple Developerのサイトで再作成してダウンロードしなければなりません。

ちょうど６月が更新タイミングだったので（いつも手順を忘れかけたころにやってくる）作業していたのですが、どうしてもプロビジョニングファイルだけが登録されません。

プロビジョニングファイルはXcodeが登録を担うので、Xcodeを入れなおしたり、手動で登録しようとしたりしましたが、上手くいきません。

サイトを調べてみてもプロビジョニングファイルをダブルクリックすれば、キーチェーンストアに登録されるという簡単仕様である以上の情報はなかなか見つかりませんでした。

もう、ダメで元々と、プロビジョニングファイルを作り直そうかとしていたときに気づきました。

f:id:hatsune_a:20200609232040p:plain

なんど、Certficatesに「Xcode11以上」という選択肢があるではありませんか。

急いで、そちらに変更してセーブしてダウンロードしてダブルクリックしたところ、無事に登録されて、また、Visual Studio for Macでビルドができるようになりました。

2020-05-31

Xamarin.Androidで必要なXamarin.Android.Supportライブラリが大幅に少なくなった件

xamarin Mobile

起

事の発端は、Xamarin.Forms 4.4だったXamarin.AndroidなプロジェクトをXamarin.Forms 4.6に上げたときにエラーが発生したことでした。

なお、Xamarin.iOSなプロジェクトはすんなりとXamarin.Forms 4.6にビルドエラーなく移行できておりましたので、本当になぞで２日ほど（途中、ACE COMBAT 7やWorld of Warshipなどをやりながら）かかりっきりでした。

承

そもそもとして、Xamarin.Forms 4.4まではTargetFrameworkとしてAndroid 8.1が指定できましたが、Xamarin.Forms 4.5以降ではTargetFrameworkの最小値がAndroid 9.0に変更になっていたため、もろもろの関係でしばらく上げられずにいたのですが、準備が整ったのでXamarin.Forms 4.6にnugetでさっと上げてみたのです。

するのなんということでしょう。さらに多くのライブラリを入れる必要を示唆されるではありませんか。

f:id:hatsune_a:20200531183731p:plain

でも必要だっていうのだから仕方がありませんね。[OK]を押して追加しましょう。

GItの機能を使って修正前の状態に何度も戻しながら試しました。

しかし。

クリーンしてからリビルドしてもビル度エラーは取れません。

Visual Studioを終了して、プロジェクト配下のbinフォルダとobjフォルダを削除してプロジェクトを再度開いてビルドしてもビル度エラーは取れません。

これは、TargetFrameworkをAndroid 9.0（ビルドエラー調査の途中で4.4のまま9.0にする分にはビルドエラーにならないことは発見）にするだけで、Xamarin.Formsは一生4.4で生きていくしかないのかとあきらめかけました。

転

しかしそんなとき、滝沢先生の「お前ら4.4か！4.4な人間なのか！いつ何をやるのもいい加減にして、一生4.4のまんま終わるのか！それでいいのか！お前らそれでも男か！悔しくないのか！」と叱咤される声が脳裏に響きました。

「くやしいです！」「よーし！何がんでも4.6にしてやるぞ！」「でもどうしたらいいだ」

そうだ、初心だ！。私たちにはVisual Studioの新規プロジェクト作成のテンプレートがあるじゃないか！

しかし、ここで問題が発生しました。Xamarin.Formsプロジェクトは共有プロジェクトとしてXamarin.iOSプロジェクトとXamarin.Androidプロジェクトから共有したかったのですが、Visual Studio 2019の新規プロジェクト作成では、以前はあったPCLプロジェクトか共有プロジェクトかの選択チェックボックスがありません。

f:id:hatsune_a:20200531191141p:plain

しかたがなしにこのまま進めると、Xamarin.Forms部分はPCLではなく.NET Standard 2.0プロジェクトとしてソリューションが作られます。

しかし、希望もありました。明らかにXamarin.Android.Support関連のライブラリが少ないのです。でも、油断は禁物です。もしかしたら、共有プロジェクトではないからそうなっているのかもしれません。

結

Xamarin.Formsなテンプレートではなく、Xamarin.Androidなテンプレートで作成し、後から共有プロジェクトとしてXamarin.Formsプロジェクトを確認してみましょう。

するとどうでしょう。あれだけあったXamarin.Android.Support関係のライブラリがたった２つだけになってしまったではありませんか。

Xamarin.Formsをいれても、たったの３つ。

最初、Xamarin.Forms 4.6に上げたときに要求された追加のライブラリも必要ありません。

f:id:hatsune_a:20200531184442p:plain

もちろん、デザインによっては追加でnugetするものも増えるかもしれません。

しかし、Xamarin.Formsを使ってそれなりのデザインを作っていた元のソリューションに移植してみて実機動作を確認してみても、この３つだけで、きちんと実機で動作確認ができました。

意図せずnugetで取得必要なライブラリの整理もできて（つまり実行モジュールサイズが小さくなって）無事に意図したXamarin.Forms 4.6化も完了しました。

やはり、時々はミニマムサンプルで最新のお作法を振り返ってみる必要がありますね。

追記：

なお、重要なのは新しく作ったXamarin.Androidプロジェクトのcsprojファイルの内容を使うことになります。つまり、（既存と同名で別フォルダに）新しいXamarin.Androidプロジェクトを作成して、既存のXamarin.Androidプロジェクトから要素をコピーして新しい状態をつくり保存したら、csprojファイルを既存のプロジェクトフォルダの方の同名ファイルに上書き保存することです。