XcodeのFrameworkでBridging Headerは使えないのでmodule.modulemapを追加してエラー回避する

外部ライブラリをラップするライブラリを作成して社内で使いまわすということをWindowsやAndroidでは当然のようにやってきたのですが、iOSでは簡単にできない場合があります。それはObjective-Cで書かれたライブラリをSwiftのFrameworkでラップする場合です。

FrameworkでObjective-CのFrameworkの組み込み時にエラー

error: using bridging headers with framework targets is unsupported

プロジェクトにObjective-Cで書かれたFrameworkを組み込む場合、Bridging Headerを追加して参照できるようにします。Frameworkで同じようにするとエラーが発生してビルドできません。エラーメッセージそのままですが、FrameworkではBridging Headerが使えないようです。

ググってもObjective-CのFrameworkを修正する方法ばかり

ではどうやって組み込むのかどうか、ググって調べてもObjective-CのFrameworkを修正してビルドし直すという方法ぐらいしか見つかりませんでした。しかし、今回のFrameworkはサードパーティー製でソースコードは手元になく修正はできません。

C#でcsharp2nemを使ってNEMのウォレットの残高などの情報を取得する

NEMはRESTFulな思想で開発が容易という特徴がありますが、さらに各言語にライブラリが公開されているので、NEMのブロックチェーンから情報を取得するのが容易になっています。今回はC#向けのライブラリであるcsharp2nemを使ってNEMのウォレットの情報取得を行ってみました。

NEMのC#向けライブラリcsharp2nemとは

Githubで公開されています

有志によって開発されGithubで公開されています。
github.com

Nugetでも公開されています

Nugetで公開されているので、Windowsアプリケーションとして利用する場合はこちらからインストールすると簡単にプロジェクトに導入できます。
www.nuget.org

Unityで使用することも可能

C#向けなのでUnityで利用することができます。つまり、AndroidやiOS向けに利用することも可能ということです。

C#のTaskを使った非同期処理のタイムアウトの実装方法について

データ量に比例して処理時間が増えるコードを非同期処理で実行していたのですが、データ量が少ないとプログレスリングがすぐ消えて画面のチラつきになってしまうことがありました。このため、処理時間が一定以上の場合はプログレスリングを表示し、一定未満の場合は表示しないというコードを書く必要があります。今回はその処理を実装するためTaskのタイムアウトを使用しました。

プログレスリングを毎回表示する場合

まずは基本的な非同期処理の実装についてです。時間のかかる重い処理をTask.Runで実行することで別スレッドで実行します。Thread.Sleepが実行されている間はUIスレッドは空いているので、UIがフリーズすることはありません。

async void Method()
{
     ProgressRing.Visibility = Visibility.Visible;
     await Task.Run(() => Thread.Sleep(10000));
     ProgressRing.Visibility = Visibility.Hidden;
}

このケースはこれで問題ないのですが、Thread.Sleepの時間が動的に変わる場合はどうでしょうか？

async void Method(int time)
{
     ProgressRing.Visibility = Visibility.Visible;
     await Task.Run(() => Thread.Sleep(time));
     ProgressRing.Visibility = Visibility.Hidden;
}

多くの場合が100とか200とかだとプログレスリングのチラつきを指摘される可能性があります。このケースだとシンプルなのでtimeの値によってプログレスリングの表示を制御できますが、当然ながら実行してみなければ時間が分からないケースのほうが多いでしょう。

SwiftとiOSで定期的なバックグラウンド処理の実行は不可能なので諦めるべき

AndroidやWindowsではバックグラウンドで定期処理を実行することは比較的容易です。これと同様にiOSでも同じ機能を実装しようとすると問題に直面します。直面するというか、その機能はiOSでは実装できません。

iOSのバックグラウンド処理

UILocalNotificationで実行

UILocalNotificationを使えば、指定時間後にiOSからアプリの処理を実行させることができます。アプリがバックグランドでも、起動していなくても可能です。しかし、これはNotificationの通知からアプリを起動したときに呼ばれるメソッドです。Notificationの通知が発生したら呼び出されるわけではありません。起動中だと呼び出されるのですが。バックグラウンドで継続して定期的な処理を走らせることはできません。なお、iOS10以降ではUILocalNotificationはdeprecatedとなっており、UNNotificationRequestを使うように勧告されています。

レガシーコードの特徴を具体的な4つの例を示して問題点をまとめます

新卒で入社した企業では20年物のソースコードが現役で動いていたりしました。しかも協力会社に丸投げした部分やインドにオフショアした部分などが入り混じってカオスとなっていました。エンジニアも玉石混在で、カオスに練度の低いエンジニアが保守拡張したりしてカオスがさらにカオスに。そんなソースコードには発狂しそうになるレガシーコード（一部ではウンコードと呼ぶ人もいる）が豊富に眠っていました。今回はレガシーコードの反面教師としてその具体例を挙げてみます。

レガシーコードの具体例

意図が分からない

if ( path != null )
{
    str = Path.Combine(path, fileName);
}
else
{
    str = path + fileName;
}

たぶんpathがnullでPath.Combineでクラッシュする不具合があったんでしょうね。それを修正した結果が上のコードになったのでしょう。pathがnullのときクラッシュすることはこれで回避できた（できてるこれ？）かもしれませんが、nullのときstrは本当に問題ないんですかね…。この不具合修正で新たな不具合を作っていそうです。

SwiftのisEmptyやCountはnilを返す可能性があることを忘れてしまう

C#でstring.Emptyを多様しているせいか、SwiftのisEmptyがnilとなることを想定せずにクラッシュさせてしまったことが昔ありました。そのときPlaygroundで挙動を確認したことがあったので、その結果を載せておきます。

nilの可能性を忘れてしまう変数

isEmpty

case5において、初期化していない非オプショナル型の配列は、オプショナル型か非オプショナル型かを明示するとisEmptyを呼び出すことができます。ビルドエラーにはなりません。このcase5をオプショナル型としてisEmptyを実行するとnilが返ってきます。更に、このcase5を非オプショナル型にアンラップすると何も返ってきません。例外が発生します。また、case6のように初期化していないオプショナル型の配列も、明示することでisEmptyを呼び出し可能です。こちらの場合はcase6をオプショナル型、非オプショナル型どちらでisEmptyを実行しても例外が発生します。

Count

CountもC#ではnullのイメージがないため、Swiftでは一瞬戸惑ってしまいます。

C#でもvarを使うべき3つの理由｜Microsoftも使用を推奨

前職でコーディング規約を整備しましょうという話になり、配られたコーディング規約にC#の型指定でvarを使うという内容がありました。新卒の研修の際にはvarはネガティブな説明だったので驚いたのですが、採用した理由はMicrosoftのコーディング規約を参考にしたからとのこと。今ではvarをメインに使っています。

C#のvarとは

暗黙の型指定

ローカル変数を定義するときは明示的な型指定を行う必要がありません。コンパイラがコードから型を推測してビルドしてくれるので、型に関わらずvarで良いわけです。

var integer = 1;
var str = string.Empty;
var byteArray = new byte[] { 0x00, 0x01 };
var intList = new List<int>();

TryParseを例外発生の防止に使うのは間違った使い方

C#でTryParseは安全な型変換のために使われますが、単に例外を回避するためだけに使っているケースがあります。今回はTryParseのアンチパターン（悪い使い方）と正しい使い方について書きます。

TryParseの間違った使い方

問題回避の先延ばし

string str = null;
int value;
int result = Calculator(10, int.Parse(str));
    
...
    
private void Calculator(int val1, int val2)
{
   return val1 / val2;
}

当然なのですが、上記のコードは落ちます。この問題を回避するために下記のように書いているコードがありました。

string str = null;
int value;
int.TryParse(str, out value);
int result = Calculator(10, value);
    
...
    
private void Calculator(int val1, int val2)
{
   return val1 / val2;
}

確かに先のコードで落ちていたところでは落ちません。でもその先で落ちます。このコードだったら気づきますが、パースの結果を変数に格納し、後で使う場合は気づきません。これなら前者のコードで落ちたほうがバグに気づくのでマシです。これは実際に本当にあったケースです。

ViewBoxの中に設置したWrapPanelを親の親であるScrollViewerの横幅でレスポンシブルにさせる

XAMLのViewBoxを使うとViewのズームやズームアウトを導入することができます。このScrollViewerの中にViewBoxを配置し、更にViewBoxの中にWrapPanelを配置したときにWrapPanelをWindowやPageのサイズに合わせて機能させる方法について書き残します。

問題の現象

WrapPanel内のコンポーネントが改行しない

<ScrollViewer HorizontalScrollBarVisibility="Auto" VerticalScrollBarVisibility="Auto">
    <Viewbox Stretch="None">
       <WrapPanel>
           <Button x:Name="button1" Content="Button" Width="75" Margin="10"/>
           <Button x:Name="button2" Content="Button" Width="75" Margin="10"/>
           <Button x:Name="button3" Content="Button" Width="75" Margin="10"/>
           <Button x:Name="button4" Content="Button" Width="75" Margin="10"/>
           <Button x:Name="button5" Content="Button" Width="75" Margin="10"/>
           <Button x:Name="button6" Content="Button" Width="75" Margin="10"/>
           <Button x:Name="button7" Content="Button" Width="75" Margin="10"/>
           <Button x:Name="button8" Content="Button" Width="75" Margin="10"/>
       </WrapPanel>
    </Viewbox>
</ScrollViewer>

このように書いてしまうと、WrapPanelの幅に制約がないのでButtonは改行なしで横一直線に並んでしまいます。

XAMLのBindingが途中で動かなくなる現象の原因を調べてみました

XAMLにBindingしていたプロパティが、あるタイミング以降に変更が反映されなくなる現象に遭遇しました。原因はBindingしているプロパティに値を直接代入するコードが実行されていたためでした。

問題の現象の詳細

問題のコード

<TextBlock Text="{Binding Message}" Name="Message"/>

XamlでViewModelのプロパティにBindingしていたのですが、

private void LostFocus(object sender, EventArgs e)
{
　　Message.Text= "Hello";
}

xaml.csのイベントでもBindingしているプロパティを操作していました。