AndroidやWindowsではバックグラウンドで定期処理を実行することは比較的容易です。これと同様にiOSでも同じ機能を実装しようとすると問題に直面します。直面するというか、その機能はiOSでは実装できません。
UILocalNotificationを使えば、指定時間後にiOSからアプリの処理を実行させることができます。アプリがバックグランドでも、起動していなくても可能です。しかし、これはNotificationの通知からアプリを起動したときに呼ばれるメソッドです。Notificationの通知が発生したら呼び出されるわけではありません。起動中だと呼び出されるのですが。バックグラウンドで継続して定期的な処理を走らせることはできません。なお、iOS10以降ではUILocalNotificationはdeprecatedとなっており、UNNotificationRequestを使うように勧告されています。
新卒で入社した企業では20年物のソースコードが現役で動いていたりしました。しかも協力会社に丸投げした部分やインドにオフショアした部分などが入り混じってカオスとなっていました。エンジニアも玉石混在で、カオスに練度の低いエンジニアが保守拡張したりしてカオスがさらにカオスに。そんなソースコードには発狂しそうになるレガシーコード（一部ではウンコードと呼ぶ人もいる）が豊富に眠っていました。今回はレガシーコードの反面教師としてその具体例を挙げてみます。
if ( path != null ) { str = Path.Combine(path, fileName); } else { str = path + fileName; }
たぶんpathがnullでPath.Combineでクラッシュする不具合があったんでしょうね。それを修正した結果が上のコードになったのでしょう。pathがnullのときクラッシュすることはこれで回避できた（できてるこれ？）かもしれませんが、nullのときstrは本当に問題ないんですかね…。この不具合修正で新たな不具合を作っていそうです。
C#でstring.Emptyを多様しているせいか、SwiftのisEmptyがnilとなることを想定せずにクラッシュさせてしまったことが昔ありました。そのときPlaygroundで挙動を確認したことがあったので、その結果を載せておきます。
case5において、初期化していない非オプショナル型の配列は、オプショナル型か非オプショナル型かを明示するとisEmptyを呼び出すことができます。ビルドエラーにはなりません。このcase5をオプショナル型としてisEmptyを実行するとnilが返ってきます。更に、このcase5を非オプショナル型にアンラップすると何も返ってきません。例外が発生します。また、case6のように初期化していないオプショナル型の配列も、明示することでisEmptyを呼び出し可能です。こちらの場合はcase6をオプショナル型、非オプショナル型どちらでisEmptyを実行しても例外が発生します。
CountもC#ではnullのイメージがないため、Swiftでは一瞬戸惑ってしまいます。
前職でコーディング規約を整備しましょうという話になり、配られたコーディング規約にC#の型指定でvarを使うという内容がありました。新卒の研修の際にはvarはネガティブな説明だったので驚いたのですが、採用した理由はMicrosoftのコーディング規約を参考にしたからとのこと。今ではvarをメインに使っています。
ローカル変数を定義するときは明示的な型指定を行う必要がありません。コンパイラがコードから型を推測してビルドしてくれるので、型に関わらずvarで良いわけです。
var integer = 1; var str = string.Empty; var byteArray = new byte[] { 0x00, 0x01 }; var intList = new List<int>();
C#で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; }
確かに先のコードで落ちていたところでは落ちません。でもその先で落ちます。このコードだったら気づきますが、パースの結果を変数に格納し、後で使う場合は気づきません。これなら前者のコードで落ちたほうがバグに気づくのでマシです。これは実際に本当にあったケースです。
XAMLのViewBoxを使うとViewのズームやズームアウトを導入することができます。このScrollViewerの中にViewBoxを配置し、更にViewBoxの中にWrapPanelを配置したときにWrapPanelをWindowやPageのサイズに合わせて機能させる方法について書き残します。
<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していたプロパティが、あるタイミング以降に変更が反映されなくなる現象に遭遇しました。原因はBindingしているプロパティに値を直接代入するコードが実行されていたためでした。
<TextBlock Text="{Binding Message}" Name="Message"/>
XamlでViewModelのプロパティにBindingしていたのですが、
private void LostFocus(object sender, EventArgs e) { Message.Text= "Hello"; }
xaml.csのイベントでもBindingしているプロパティを操作していました。
はてなブログにはブログのバックアップサービスがありますが、残念ながら画像ファイルのバックアップはできません。アップロードした画像はフォトライフというサービスで管理されているのですが、ブログと違うサービスのせいなのか、連動してバックアップを取れません。フォトライフにも一括ダウンロード機能はありません。今回は一括ダウンロードアプリケーションを開発しました。
Windows10で開発と動作確認を行っていますが、Windows7や8.1でも動くと思います。Windows7は別途.NET Framework4.5をインストール必要があります。
C#やJavaなどのオブジェクト指向型プログラミング言語に用意されている抽象クラスとインターフェースですが、コード的な違いは理解していても使い分けまでできているケースは意外と少ないです。中級未満のエンジニアだと、そもそも抽象クラスやインターフェースを使うことすらしない場合も。決して自分が完璧に理解し、使いこなしていると自負しているわけではないのですが、中級者レベルの理解と使い分けについてまとめます。
教科書的には上記が主な違いになります。ただ、上記の文法的な違いだけを根拠に使い分けているとコードは保守性、拡張性を落としてしまいます。
この考えはオブジェクト指向ではありません。
むかしむかしのSwiftにはByte型があったと思うのですが、あるとき突然廃止されました。Byte型の配列など使って低級の処理をしていたアプリやプログラムはコンパイルすらできない事態に。C#やJavaからやってきた人も一瞬戸惑うのではないでしょうか。どう調べれば良いかも分からないのですが、結論から言うとUInt8型がByte型に相当するっぽいです。
そもそも高級言語でバイト配列を触るなという話かもしれませんが、IoTやっていると触る必要が出てくるものですよね。相手がバイト配列でコマンドを定義していたりするので。例えばC#だと下記のようなバイト配列を定義できます。
var byteArray = new byte[8] { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }
これをSwiftで書くとこうなります。
let byteArray: [UInt8] = [ 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 ]
こういう痒い所の情報がなかなか出てこないSwiftはまだまだ辛いですなあ。
