2014年9月30日火曜日

GitHub:Enterprise 環境下では CocoaPods を 0.34.0 以上にアップデートしてはいけません

タイトルの地点で結構出落ちですが、本日少々厄介な問題にぶち当たってしまったので共有いたします。

発生条件

CocoaPods 0.34.0以上を使用し、GitHub:EnterpriseのgitリポジトリをPodSpecないしSourceリポジトリとして使用している場合に発生します。

発生する問題

CocoaPodsのgitを利用するアクションが全く成功しなくなります。具体的にはpod install, pod updateなどが全く通りません。

問題の原因

公式ブログにあるとおり、0.34.0以上からCocoaPodsは高速にgitリポジトリをcloneするため--depth 1 (shallow clone) オプションを採用するようになっています。しかしながらGitHub:Enterprise側の技術的問題なのか、GitHub:Enterprise内のgitリポジトリに対するhttpないしhttps経由でのshallow cloneが成功しないため永遠にpod installやpod updateが終わりません。

対処方法

根本的にはCocoaPodsかGitHub:Enterpriseかいずれかが修正されるのを待つしかありませんが、CocoaPods側としてはあまり積極的に対応する気がないようなので、GitHub:Enterprise側に対応を期待するしかないでしょうか。もちろん全てのGitHub:Enterprise環境下で発生するとは限りませんが、いずれにせよ注意する必要があります。

2014/10/01追記

GitHub:Enterpriseに問い合わせてみたところ、こちらは既知の問題であり現在修正中で、次のリリース時に修正されるそうです。次のリリースが社内環境にデプロイされるまでの辛抱ですね。

こちらからは以上です。

投稿時間：

2014年9月8日月曜日

Swift から Core Data を操作するときはこの2点だけ気をつけよう (Xcode 6 beta 7編)

将来的にXcode側の対応が変わる可能性が極めて高いので暫定ですが、Xcode 6 beta 7でSwiftからCore Dataを触った時に注意するポイント2点まとめです。この2点にだけ気をつければSwiftでもCore Dataは案外あっさり動きますのでご安心ください！

1. プロパティの設定の仕方


  • @NSManagedを使うこと
  • Int, BoolではなくNSNumberを使うこと。StringはStringでOK
  • Many関連にはNSSetを指定すること



2. entityNameの与え方


  • コード上ではクラス名だけを与える
  • Model Editor上ではモジュール名.クラス名（完全修飾名）を与える



Model Editorではこのようにモジュール名.クラス名の形で設定する必要があります


あとは普段Objective-Cで使っている時と同じように使えばOKです。一応、簡単なSwiftからCore Dataを操作するラッパライブラリを書いてみたので、もし宜しければ見てみてください。
https://github.com/akisute/Dove
投稿時間：
タグ：

【ヤヴァい】リリース直前の Swift の仕様が早くも悲惨なことになってる

正式版リリースまで後一ヶ月と噂されるXcode 6と新言語Swiftですが、リリース一ヶ月前にも関わらずその仕様が早くも悲惨との声がごく一部から上がっているようです！！


public private(set)って結局どっちなの！？

beta 5から追加されたアクセス制限指定子ですが、その仕様に疑問の声が！


なるほど、public private(set) var numberはキモいですね〜。ちなみにこれはgetterがpublicでsetterがprivateな変数の宣言のようです。なんかもっといい文法はなかったんでしょうか・・・


一行closureを使うときに注意！思わぬ落とし穴が！




これはSwiftの言語仕様上、実行コードが一行しかないclosureは暗黙的にreturnするものとみなされてしまうからのようです。これはちょっとひどいですね〜〜！


中には良い一面も・・・？



Nil Coalescing Operatorというのは ?? 演算子のことです。これは A ?? B のように使い、AがNot NilならAを、そうでなければBを返すという演算子です。なかなか便利に使えますよ！ちょっとはSwiftも見なおしたかも！？


おわりに

某まとめっぽくしたらなんかイマイチな感じになりました(´･_･`)
あとAppleふざけんな
投稿時間：
タグ： ,

Apple Push Notification で送られてきた通知を通知センターから消すたった一つの方法

いや、それがたった一つしか方法ないのはさすがにどうかと思うのですが。

皆さんもiOSのアプリを使っていて、通知を受け取った後にアプリを開いても通知センターから通知が消えず地味にイライラする現象に見舞われたことがあるのではないかと思います。私もお恥ずかしながらつい最近知ったのですが、実はこれアプリ側で何も対応しないと通知センターから通知は消えません。それどころかなんと通知センターからプッシュ通知を消すためのAPIも一切提供されていません。つまり普通にアプリを作ると通知センターから通知が消えないのです。Appleふざけんな

※注記: ここで私が消せない通知と呼んでいるものはApple Push Notification経由でのRemote Notiifcationです。UILocalNotificationは自由自在にアプリ側から消せるので、適切なタイミングで消してないのは単なる実装者の怠慢となります。

しかしながらTwitterやFacebookアプリはきちんとアプリが開かれたタイミングで通知センターから通知が消えるようになっています。不思議です。そこでちょっと調べてみました。

解決策

以下のリンク先にあるように、一度applicationIconBadgeNumberを1以上の数字に設定してから、0に戻すと、全てのApple Push Notification経由での通知が消えるようです。

http://stackoverflow.com/questions/8682051/ios-application-how-to-clear-notifications
http://stackoverflow.com/questions/9925854/remove-single-remote-notification-from-notification-center

iOS 5~8のすべてのバージョンで動作することを確認しています。少々ダサいですがこの方法でしのいでいきましょう！

※注記: 個別に通知を消す方法はありません。なおiOS 8より、ユーザーが直接通知センターから通知をタップしてアプリが起動した場合のみ、タップされた通知が自動的に消えるように仕様が変更されています。相変わらずアプリから明示的に消すことはできません。Appleふざけんな

投稿時間：
タグ： , , ,

2014年8月25日月曜日

Silent Push / Background Fetch 時の fetchCompletionHandler に渡す引数ごとの挙動の違いを調べてみた

2014/09/10追記: 追加調査によって判明した事項を追記しています。


iOS 7から追加されたPush通知によるバックグラウンド処理機能 (Silent Push) および定期的なバックグラウンドフェッチ機能 (Background Fetch) ですが、これらの機能はバックグラウンド処理が完了したタイミングでいずれもfetchCompletionHandlerにUIBackgroundFetchResult型の値を渡すような設計になっています。

ちょっと調べれば、大体どこの解説サイトにも以下のように説明があります。


  • UIBackgroundFetchResultNewData
    • 新しいコンテンツの取得に成功し、新しいデータが存在した場合
  • UIBackgroundFetchResultNoData
    • 新しいコンテンツの取得には成功したが、新しいデータが用意されていなかった場合
  • UIBackgroundFetchResultFailed
    • 通信エラーなどの理由でコンテンツの取得そのものに失敗した場合


問題は、これらの値をfetchCompletionHandlerに渡したら「何が起きるか」を解説しているサイトや文献がほとんど存在しません。そこでこのたび独自に調査してみました。

UIBackgroundFetchResultの値が影響する項目

いろいろ調べてみた結果、以下の参考文献によりUIBackgroundFetchResultの値は２つの項目に影響することがわかりました。
http://www.objc.io/issue-5/multitasking.html
https://codeiq.jp/magazine/2013/12/3022/

ひとつは、以降のSilent PushおよびBackground Fetchの挙動に対する影響です。OSが返された値を元に、アプリが使用したプロセス時間・電力消費などを判断し、以降のSilent PushやBackground Fetchの頻度に反映させるというものです。ただしどのような判断が行われどのように頻度に対して影響するかは完全にブラックボックスとなっており文献がありません。

もう一つはApp Switcher（ホームボタンをダブルタップした際に表示されるアプリ切り替え画面）のサムネイル画像、スナップショットを更新するために使用しているようです。値が渡されたタイミングで必要に応じてアプリのスナップショットを再描画するために、なんとアプリがバックグラウンドにいるにも関わらずその場でUIの再描画が行われます。この際通常のフォアグラウンドにアプリが存在する場合とまったく同様に、UIViewやUIViewControllerのメソッドが呼ばれます。例えばviewWillAppear, viewDidAppear,  didMoveToSuperViewなどが呼び出されます。

従いましてUIBackgroundFetchResultを渡す際には必ずメインスレッドで行う必要があります。NSURLSessionのdelegateを受け取ったスレッドから直接値を渡すとバックグラウンドでひっそりクラッシュします。ひっそりクラッシュする程度ならまだしもですが、これらのUI処理の中にバックグラウンドで呼び出されることを考慮していない処理が入っていると数々の問題を引き起こします。例えばviewDidAppearのタイミングでユーザさんがその画面を見たものと判断してデータやフラグを更新するですとか、Google Analyticsに統計情報を送っているですとか、そういうことをやっていると一気に大問題になります。

長くなりましたが、以上を踏まえまして、各値ごとにどのような影響があるかを実際に実機でテストして調べました。

UIBackgroundFetchResultNewDataを渡した時

スナップショットの更新が発生します。
Silent Pushの受取可能頻度に対して影響はないようです。一日４回程度、３〜６時間程度の間隔が空いていれば、全く問題なく受取可能です。ただし１０分〜１５分間隔で受取を行うとレートリミットがかかりはじめ、１〜２日以内に受信不可能になります。一度受信不能になったデバイスが再度受信可能になるかどうかはわかりませんが、数日間程度置いていても効果がなかったので、再度受信ためには最悪デバイスの完全なワイプとリセットが必要になるかもしれません。
Background Fetchの発生頻度に対しても影響はないようです。

UIBackgroundFetchResultNoDataを渡した時


スナップショットの更新が発生します。
三ヶ月程度様子を見ているところ、Silent Pushの受取り頻度に対してNewDataの場合とほぼ同様に影響はなさそうです。したがってNewDataを返す場合と何が違うのか現在のところわかっていません。

以下、旧記述です。
スナップショットの更新は発生しません。スナップショットの更新に伴って大問題が発生する場合には一番簡単な解決策になります。
ただし毎回毎回UIBackgroundFetchResultNoDataばかりを返却していると、Silent Pushの受取可能頻度およびBackground Fetchの発生頻度に対してペナルティがかかる恐れがあります。何度試行してもデータが取れないので、システムが再試行頻度を下げるのではないかという推測ですが、実際に観測できたわけではありませんので、なにか情報が入り次第また詳しくお伝えします。

UIBackgroundFetchResultFailedを渡した時

スナップショットの更新は発生しません。
こちらもUIBackgroundFetchResultNoDataと同様、UIBackgroundFetchResultFailedばかりを返却していると、Silent Pushの受取可能頻度およびBackground Fetchの発生頻度に対してペナルティがかかる恐れがあります。何度試行してもデータが取れないので、システムが再試行頻度を下げるのではないかという推測ですが、実際に観測できたわけではありませんので、なにか情報が入り次第また詳しくお伝えします。


投稿時間：
タグ： ,

2014年8月12日火曜日

Apple Push Notification (APN) 使用時の delegate の挙動について、 iOS 7以降 / iOS 6以前の差をまとめた

iOS 7以降とiOS 6以前で、俗にいうリモートPush通知の受け取り方と受け取った際の挙動がまるで違っているので、最近リモートPush通知を実装した時につまづいた箇所をまとめてみました。

使用するdelegate methodの違い

iOS 7以降


  • いかなる種類のPush通知においてもapplication:didReceiveRemoteNotification:fetchCompletionHandler:を使用します。
  • application:didReceiveRemoteNotification:fetchCompletionHandler:とapplication:didReceiveRemoteNotification:が両方実装されている場合も、application:didReceiveRemoteNotification:fetchCompletionHandler:しか呼び出されません。application:didReceiveRemoteNotification:fetchCompletionHandler:のみ考えればOKです。
  • ただし、application:didReceiveRemoteNotification:が実装されており、application:didReceiveRemoteNotification:fetchCompletionHandler:が存在しない場合は、iOS 6以前同様の挙動になります。
  • 以下、長ったらしいのでapplication:didReceiveRemoteNotification:fetchCompletionHandler:を新メソッドと呼称します。

iOS 6以前


  • application:didReceiveRemoteNotification:を使用します。
  • 新メソッドが実装してあっても一切反応しません。
  • 以下、長ったらしいのでapplication:didReceiveRemoteNotification:を旧メソッドと呼称します。

挙動の違いまとめ

以下に表にしてまとめました。ここで、
iOS 7以降とは新メソッドを使用する場合、iOS 6以前とは旧メソッドを使用する場合のことを指します。


iOS 6以前iOS 7以降
初回起動application:didFinishLaunchingWithOptions:に
UIApplicationLaunchOptionsRemoteNotificationKeyが付いて呼び出される。
旧メソッドは呼び出されない。		application:didFinishLaunchingWithOptions:に
UIApplicationLaunchOptionsRemoteNotificationKeyが付いて呼び出される。
その後、UIApplicationStateActiveの状態で、新メソッドも呼び出される。
handlerについては、content-available指定が1の場合のみ付いてくる（未確認）。
起動中UIApplicationStateActiveの状態で、旧メソッドが呼び出される。UIApplicationStateActiveの状態で、新メソッドが呼び出される。
handlerについては、content-available指定が1の場合のみ付いてくる（未確認）。
未起動UIApplicationStateInactiveの状態で、旧メソッドが呼び出される。UIApplicationStateInactiveの状態で、新メソッドが呼び出される。
handlerについては、content-available指定が1の場合のみ付いてくる（未確認）。
データ取得不可能。UIApplicationStateBackgroundの状態で、新メソッドが呼び出される。
handlerは必ず付いてくる。
この通知がアラートや通知センターに表示された場合、ユーザーがそれらとインタラクションしたらさらにもう一回UIApplicationStateInactiveの状態で新メソッドが呼び出される。

バックグラウンドでの通知受け取りとデータ取得

iOS 7から、Push通知のペイロードのapsオブジェクトにcontent-availableというプロパティが新たに追加されました。content-availableプロパティの値を数字の1に設定すると、ユーザーのインタラクションを介さずにバックグラウンドでアプリケーションが起き上がることができ、サーバから最新のデータの取得を行ったりする事が可能です。詳しくは「Push通知 バックグラウンド iOS7 content-available」とかその辺の単語を適当に組み合わせてググってください。山ほど解説しているページがあります。

サイレント通知が届かないときの処方箋

さて、上記バックグラウンドでの通知受け取りとデータ取得について、余り解説が見当たらなかった点についてまとめました。

iOS 7以降のPush通知は、apsオブジェクトのalertプロパティの有無とcontent-availableプロパティの有無によって挙動が変わります。具体的には以下の表のようになります。

content-availableがあるcontent-availableがない
alertがある通常通知
同時にバックグラウンドデータ取得も可能		通常通知
alertがないサイレント通知
バックグラウンドデータ取得のみ可能		送信できない

content-availableがない場合はiOS 6以前のPush通知と全く同じなので説明を割愛します。次にcontent-availableとalert両方が指定されている場合ですが、これはiOS 6以前の通常通知と基本は同じで、異なる点は通知を受け取った瞬間にバックグラウンドでアプリが立ち上がってデータの取得ができるという点だけです。したがいましてちょっと上記に記載しましたが、通知を受け取った瞬間と、ユーザーがインタラクションした瞬間で2回新メソッドが呼び出されるので、必ず新メソッドの中でUIApplicationStateを見て処理を分岐するようにしてください。

問題になってくるのがcontent-availableだけが指定されている通知、サイレント通知についてです。ほかのサイトでもよく紹介されていますが、この通知を使ってバックグラウンドでアプリを起動させて最新のデータをダウンロードしたりすることができます。以下にサイレント通知のペイロードの例を示します。

上が通常のサイレント通知ですが、下のようにサイレント通知と同時にバッジの数を更新することもできます。

さてこのサイレント通知ですが、とにかく「届かない！」というトラブルを耳にします。実際私が試した際にもなかなか届かないで弱りました。そこで調査したところ、サイレント通知のペイロードを工夫することできちんと通知が到達するようになりました。以下に到達率を改善したサイレント通知のペイロードの例を示します。

ご覧のように、空のsound要素を追加することで到達率が劇的に向上します。また2つ目の例のように、priorityというプロパティを10に設定するとこれまた到達率が劇的に向上します。どうやらこのpriorityプロパティはalertプロパティかsoundプロパティが設定されている場合はデフォルト10に、設定されていないサイレント通知の場合はデフォルト5に設定されているようで、それが原因で到達しない事が多いということがわかりました。
参考記事: http://stackoverflow.com/questions/19239737/silent-push-notification-in-ios-7-does-not-work

それから、Xcode上からプロジェクトのCapabilitiesの設定をするとき、Background fetchとRemote notificationsの両方の指定がおそらく必須と思われます。中にはRemote notificationsだけ設定しておけば良いと解説しているところもありますが、どうやらRemote notificationsは通知を受け取る箇所までだけで、肝心のバックグラウンドでのデータの取得はBackground fetchがないと実行できないのではないかと思われます。
投稿時間：
タグ： , ,

UINavigationController.interactivePopGestureRecognizer の挙動を魔改造して変えてみる

注意: 今回の記事は久しぶりの誰得記事です。こちらで紹介されている手法を用いるにはプライベートAPIを操作する必要があるため、おそらく審査に通りません。じこせきにんでお願いします。

iOS 7からUINavigationControllerにinteractivePopGestureRecognizerというプロパティが新たに追加されました。これは「ナビゲーションコントローラの左端から右にスワイプすると前の画面に戻る」機能を司るgesture recognizerで、同じくiOS 7から追加されたUIScreenEdgePanGestureRecognizer(画面端からのみ反応するPan Gesture Recognizer)とUIViewControllerInteractiveTransitioning(ViewController間の画面遷移時に、ユーザーのインタラクションを追加する。例えば画面半分までスワイプしたら50%画面遷移するとか)の仕組みで実装されています。

ここで、例えばこの「ナビゲーションコントローラの左端から右にスワイプすると前の画面に戻る」機能について、見た目はそのままがいいんだけど左端からしか反応しないのが気に入らないから画面の中央でも反応するようにしたいという要望があったとします。自前で実装してもよいのですが、やはりApple純正の動きが良いですよね。

そこで以下のページで紹介されている黒魔術を使ってみたいと思います。
http://blommegard.se/blog/2014/01/31/a-take-on-custom-transitions-with-uinavigationcontroller/
こちらのページにUINavigationController内部でどのようにinteractivePopGestureRecognizerが実装されているかという解説があります。

  • 先述の通り、UIScreenEdgePanGestureRecognizerのインスタンスが使用されている
  • targetは_UINavigationInteractiveTransition型のオブジェクト、調査の結果_cachedInteractionControllerという隠しプロパティがそれに相当することがわかった
  • actionは@selector(handleNavigationTransition:)

ここまでわかったので、あとはtarget/actionを自分で生成したUIGestureRecognizerにセットしてやれば、標準の動きをジャックすることができるというわけです。今回はUIPanGestureRecognizerを使用しました。



このコードを実行してみると確かに画面中央からでもいつものスワイプジェスチャで戻る挙動が可能になっています。やりましたね＼(^o^)／
投稿時間：
タグ：

2014年6月25日水曜日

App Extension や Widgets に App Container を使わないで簡単にデータを渡す方法

iOS 8から利用できるApp Extensionはアプリ本体とは別のプロセスとして動作するため、そのままでは簡単にデータを渡すことができません。公式のドキュメントではApp Containerという仕組みを使う方法が推奨されていますが、この方法はiOS Dev Center上でApp IDの設定が必要になったりするなど面倒がつきまといます。そこでより簡単にApp Extensionにデータを渡す方法がないか調べてみました。

方法1: UIPasteboardを使う方法

一番おすすめなのがこちらです。UIPasteboardというのは要するにコピペ用のクリップボードみたいなものなのですが、こちらシステムが用意している共通のもの以外にも自分のTeam IDでコードサインされたアプリ間すべてで共用できるPasteboardを作成する機能があります。この機能を使用すると非常に簡単にデータをやりとりすることができます。面倒な設定も不要ですし、persistentプロパティを設定することでディスクへの永続化も面倒を見てくれます。

以下にサンプルコードを掲載します。本体アプリのUIApplicationDelegate内でクリップボードを作成してデータを突っ込み、App ExtensionのWidgetViewController内でその値を使用するサンプルです。

注意点として、UIPasteboardのnameはあなたの作成したアプリ全体（同じTeam IDでコードサインされたアプリ全体）で共有になります。ですのでWidgetですとかTestのような単純な名前ではなく、com.akisute.MyApp.Widgetのような一意になる名前をつけることをおすすめします。

UIPasteboardについての詳しい使い方については、以下の記事をご覧ください。

方法2: Keychainを使う方法（未確認）

未確認なので確定情報ではありませんが、Keychainには複数のアプリ間で値を共有する機能がありますので、そちらを使えばおそらくアプリ本体とApp Extensionの間で値を共有する事が可能になります。詳しくは以下の記事をご覧ください。

投稿時間：
タグ： ,

2014年6月9日月曜日

既存の Objective-C のメソッド引数の Swift 上での扱われ方を調べてみた

前置き

こちらの記事には2014/06/09現在、公式にはリリースされていないiOS8プレリリースドキュメントへのリンクが含まれます。iOS8にて新しく追加された内容には一切触れておらずAppleとのNDA規約にも違反するものではないという認識ですが、場合により予告なく削除する可能性があります。予めご了承ください。

本題

iOS8プレリリースドキュメントを眺めていて気になったのですが、ほとんどのCocoaのメソッドの引数に!がついています。例えばNSKeyValueObservingプロトコルのaddObserver:forKeyPath:options:context:メソッドのシグネチャは以下のようになっています。

func addObserver(_ anObserver: NSObject!,
      forKeyPath keyPath: String!,
         options options: NSKeyValueObservingOptions,
         context context: CMutableVoidPointer)

第1引数と第2引数に!がついているのがわかると思います。
更にもうひとつ気になったのが、このメソッドの第3・第4引数です。これらは元々0やNULLポインタを渡すことができる引数だったのですが、見ての通り引数が?で宣言されておらず、そのままnilを渡してしまうとエラーになってしまうように見えます。

直感的に考えると、

  • !がついている引数は呼び出し時に強制的にunwrapされるので、nilを渡してはいけない、必須引数なのではないか？
  • !がついていない第3第4引数はnilが渡せないのではないか？

という風に思うのですが、実際には

  • !がついている引数にnilを渡すことができる。さらにnilを渡してもランタイムでクラッシュしない。
    • 今回の例のaddObserver:forKeyPath:の場合はクラッシュしますが、これは元々のAPIがそうだったからで、例えば他のCocoaのAPIで!がついているものでnilを渡しても問題ないものが多数存在します。
  • !がついていないNSKeyValueObservingOptions, CMutableVoidPointerにnilを渡してもコンパイルエラーにすらならず、何の問題もなくそのまま動作する。

このような私の理解とは正反対の挙動をします。大変気になったので調べてみることにしました。

!がついている引数の謎

これについてはそもそも私のSwiftに対する理解が完全に間違っていました。正しい理解は以下のとおりです。

  • 無印型 - nilを渡すことができない。nilになる瞬間が一瞬もない。これこそがnilを渡せない必須引数である。
  • ?型 - Optional型であり、nilを扱うことができる。これについては問題ない。
  • !型 - ImplicitlyUnwrappedOptionalという特殊なOptional型であり、Optional型なのでnilを扱うことができる。すなわち!が付いている引数については任意引数でありnilを渡すことができる。
    • !も?も演算子でも命令でもなく型であり、!や?をつけることで対象を型に包んでいる、と考えれば良いと思います。
    • !と?の違いはメンバにアクセスした際に暗黙的かつ強制的に元の型にアンラップされるか、そのままOptionalとして扱われるかの違いだけです。

ではなぜCocoaのAPIは引数で?ではなく!を使ってnilを受け取れるようにしているのでしょうか？これは引数を受け取った後に、その引数にアクセスした場合の挙動がおそらく影響しているのではないかと思われます。以下の例を見てください。

こちらのコードですが、safeSwim()メソッドが旧Objective-Cと完全に同じ挙動を示します。これは以下の様な理由によるものです。

  • self.name（!型）が?型によってラップされる。
  • self.name?の.descriptionにアクセスする。このとき?型によってラップされているので、self.nameがnilであれば何も起こらず、self.nameがnilでなければまず?型からアンラップされ、次に強制的に!型からアンラップされ、その結果通常通りdescriptionが呼び出される。
  • 通常だと?型の返り値は?型にラップされてしまうが、self.nameが!型なので強制的にアンラップされ?型ではなく素のString型を返すことができる
    • ここだけよく理解できてないです・・・

間違っていたらすみません(´･_･`)

とにかくこれこそが旧Objective-CのAPIについて!で型が表現されている理由ではないかと考えています。

!がついていないのにnilが渡せる引数の謎

こちらの謎はカラクリがわかってしまえば簡単です。前回の記事をご覧になった方はお気づきになったかもしれませんが、これらの型はAppleが__convertion()メソッドをNilTypeに対して追加しているため、nilを問題なく扱うことができます。

まとめ


  • !が付いている引数は?と同様にnilを渡しても良い引数である。nilを渡せない必須型は何もついていない引数のみである。
  • !はImplicitlyUnwrappedOptionalという特殊なOptional型であり、アクセス時にOptionalではなく強制的に元の型を返す点がOptionalと異なる、と考えれば理解しやすい。
  • 変数をすべて!で定義し、メンバアクセス時に常に?をつけるようにすると、どの変数にもnilを渡すことができ、実行時にnilがあればそこで実行がスキップされ、さらに返り値もOptionalではない通常の型にできるため、旧Objective-Cとほぼ同じ挙動になる。
    • ただしSwiftで新しく用意されているAPIを見る限りnilを扱う必要がある箇所については可能な限り!ではなく?を引数や返り値に使っているように見えるため、新しくSwiftで書く箇所については!を乱用するべきではないと思われる。
  • Cocoaの用意している型のうち、元々nilやNULLや0を渡すことができた型については、NilTypeに__conversion()メソッドが追加されているので、そのままnilを渡すことができる。

投稿時間：
タグ： , ,

Swift で __conversion メソッドを使ってカスタムの型変換を定義する方法

2014/10/21追記:
Xcode 6.0 beta 6以降、__conversion()を使った暗黙的なas演算子を用いた型変換はサポートされていません。Xcode 6.1(Swift 1.1)現在、暗黙的な型変換を行う手段はないため、型変換を行いたい場合はイニシャライザを定義する方法を取るのが通例として良いと思います。

class 変換対象の型 {
  init(_ obj: 変換元の型:) -> 変換対象の型 {
    return 適当に変換対象の型を返す
  }
}


Swiftではas演算子を使ったり、型の定義されている変数・定数へ代入したり、メソッド呼び出しの引数にオブジェクトを渡す際に型変換が行われますが、デフォルトでは対応していない型変換があったりします。例えばStringはasを使ってもIntに変換することはできません。

また、SwiftではnilはNilTypeという型のシングルトンとして実装されており、nilを渡すとNilTypeから当該型への型変換が行われるようです。?(Optional)型や!(ImplicitlyUnwrappedOptional)型はNilTypeからの型変換に対応しているからnilが代入でき、それ以外の型は対応していないためコンパイルエラーになるというのがカラクリのようです。

この型変換ですが、__conversion()というメソッドを変換元の型に実装することで、任意の型変換を自分で実装する事ができます。以下のようになります。
class 変換元の型 {
  //@conversion属性は付けても付けなくても大丈夫みたいですが、一応つけます
  @conversion func __conversion() -> 変換対象の型 {
    return 適当に変換対象の型を返す
  }
}
以下にNilTypeを使ったnilからカスタムクラスへの型変換サンプルを示します。こうすればnilを引数にとってもエラーになりません。

ご覧のとおり、extensionとの組み合わせで既存のクラスも含むどのような型からどのような型への型変換にも対応可能になりますので色々はかどります。ぜひご活用ください。
投稿時間：
タグ： , ,

2014年6月6日金曜日

Swift の enum型を for-in でイテレーションする方法

例えばJavaのEnum型などはそのまま以下のようにイテレーションすることが可能なのですが、

なぜかSwiftのenum型はそのままではイテレーションすることができません。対策としてGeneratorという仕組みが標準ライブラリに用意されてますので、それを使ってenumをイテレーションできるようにします。

具体的には、Generatorを継承したクラスを作成して next() -> Element? を実装してください。ElementはAnyObjectのtypealiasなので実際には好きな型を返していただければOKです。あとはSequenceOf<T>型でGeneratorをラップしてあげればOKです。next()メソッドがnilを返すまでSequenceOf<T>はイテレーションを続けてくれます。

以下にサンプルコードを示します。

Generator内部でyieldが使えれば便利なんですが、おそらくyield構文は無さそうです。Enum型を一覧したい場合以外にもGeneratorは便利に使えますのでぜひお試しください。
投稿時間：
タグ： , ,

Swift を使ってみてがっかりした点まとめ



数日間iOS8/Xcode6/Swiftな環境で色々試してみて、Swiftを使っていて思ったよりがっかりした点が多かったのでちょっとまとめてみようと思います。

動的な処理がSwiftだけでは一切できない

[NSObject performSelector:]の類と、NSInvocationがSwiftからは一切呼び出せません。使おうとすると怒られます。objc/runtime.hは試していませんが、同様に直接Swift経由では呼び出せず間にObjective-Cをかます必要があるのではないかと思われます。

@optionalなprotocolが限定的にしか使用できない

具体的には@objc属性を付けないと使えません。しかしながらこのような後方互換性のためだけに存在する属性をいつまでもAppleがサポートするかは疑問が残るというのと、もう一つ以下の様な問題があります。

@objc属性のついたSwiftの型はただのObjective-Cクラスになる


こういう問題があるのであまり使いたいとは思えません。ちなみになのですがCocoaのクラスはほぼすべて@objc属性が付いているため、それを継承して使うことになるアプリでは事実上Swiftの本来の能力を出せないのではないかと思っていますが、実際のところはわかっていません・・・

メモリ管理が相変わらず必要

Swiftのメモリ管理はGCではなくARCでありただの参照カウント方式にすぎないため、Swiftでも循環参照が発生しないようにプログラマが明示的に参照の種類を指定しなければなりません。その上Objective-Cでも存在したstrong, weakに加えunownedという新しい種類のメモリ管理が追加されています。これはweakは参照が消滅するとnilにするという挙動であるためOptional型を使わなければならないのに対し、unownedは参照が消滅してもnilにならない代わりに通常の型がそのまま使えるというもののようです。

closureでselfをキャプチャするときの循環参照対策が相変わらず必要

いちばんがっかりしたのがこれです。Swiftはdelegateよりもclosureを使ったcallbackのほうが言語構造上向いているためclosureを大量に使うことになると思うのですが、このときselfがclosureを強参照し、closureがselfをキャプチャするようなコードを書いてしまうと、循環参照になるためメモリが開放されなくなるという問題がObjective-Cから引き続き発生します。対策としてclosure capture listと呼ばれる新たな構文が追加されています。closureの先頭、引数宣言の前に[unowned self]のような構文を追加することで、selfをunownedとしてキャプチャすることができます。

以下に使用前・使用後の例を示します。

Objective-CのweakSelfよりはマシに思えますが、とはいえこの辺りはコンパイラが自動的に対応してほしいところです(´･_･`)

投稿時間：
タグ： , ,
登録: 投稿 (Atom)