tomoyaonishiのブログ

iOSのことを中心に・・・その他もあるよ!

iPhoneX && UITabBarController && UIToolbar && SafeArea && Blur

iPhoneXでUITabBarControllerのタブをhiddenにしてもSafeAreaが伸びてくれずに、タブ上部に表示しているUIToolbarのblurがHomeIndicatorまで伸びてくれない場合に以下の対応で対症療法できることが判明しました。

UITabbarの上にUIToolbarの構成で、UIToolbarはSafeArea.bottomに対して貼り付けている状態です。

f:id:tomoyaonishi:20171020195548p:plain:w300

UITabbarをhiddenにするとHomeIndicatorまでBlurが伸びません。

f:id:tomoyaonishi:20171020195821p:plain:w300

UITabBarがない場合のSafeArea.bottomの位置までUIToolbarを下げてあげる(-49.0pt)となんとBlurがHomeIndicatorまで伸びてくれます。たぶんiOSのバグですが、その場しのぎの対応であればこれがいいかもしれません。

class FirstViewController: UIViewController {
    @IBOutlet weak var bottomMargin: NSLayoutConstraint!
    
    @IBAction func hideBar(_ sender: Any) {
        guard let tab = tabBarController?.tabBar else { return }
        if tab.isHidden {
            tabBarController?.tabBar.isHidden = false
            bottomMargin.constant = 0.0
        } else {
            tabBarController?.tabBar.isHidden = true
            bottomMargin.constant = -49.0
        }
    }

}

f:id:tomoyaonishi:20171020200716p:plain:w300

UIBarPositioningなど考えうるものすべていじりましたがこれでしか直せませんでした。

なんかバックグラウンドいって戻ってくるとUITabBarがhiddenでもSafeAreaの位置が正しくなってるような気がするんですが、よくわかりません。。

FoursquareのAPIについて

FoursquareAPIが無料枠アカウントでは、商用目的では使えないという旨の記載があった;;

なんとかならないかと思い、直接Foursquareさんに問い合わせたところ、無料枠アカウントでも運用やソフトウェアの資金調達のための広告等はOKとの返事をもらいました。

これなら、もし運用費稼ぎたくなっても安心して使えますね!

引用

you can use the API's up to the current maximum rate limit for free and would not require a commercial license if you're just using advertising to fund your app/software.

Homebrewを再インストール

El CapitanにアップデートしたらMacパーミッションの周りが変わったみたいでhomebrewが使えなくなりました。

手動でパーミッション変えたり、解決策はあるようでしたが、めんどくさいのでHomebrew自体を再インストールすることにしました。

まずはアンインストール

$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/uninstall)"

そのあとインストール

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

これで再インストール完了です。

CentOS7.1にてApacheとPythonでCGI

CentOS7.1にApacheを入れた状態でPythonCGIとして動かしたかったのでその時の手順をメモしておきます。 

IDCFクラウドの一番貧弱なサーバを借りてやっております。

Apacheファイアウォールなどの設定はできていて、index.htmlは見れる状態からスタートです。

apacheの設定ファイルを編集します。

$ sudo vim /etc/httpd/conf/httpd.conf

長々と設定が書かれていますが、以下の箇所を見つけます。

<Directory "/var/www/cgi-bin">
    AllowOverride None
    Options None
    Require all granted
</Directory>

次のように修正します。オプションにCGIで実行可能、実行するファイルの拡張子は.py .cgiとします。(.cgiは今回は使いません)

<Directory "/var/www/cgi-bin">
    AllowOverride None
    Options ExecCGI
    Require all granted
    AddHandler cgi-script .cgi .py
</Directory>

設定ファイルの編集はこれで終わりです。CGIスクリプトを作成します。

CGIスクリプトの置き場所に移動します。

$ cd /var/www/cgi-bin/

実行ファイルを作成します。

sudo vim test.py

---

#!/bin/python3.5

print("Content-Type: text/plain")
print("")
print("Hello World")

!bin/python3.5のところはpython3.5を入れているのでこうなっています。デフォルトのpython2.7でよければ#!bash/pythonでいけるとおもいます。 CGIスクリプトの出力方法については別途検索してください。ヘッダーとボディの間に1行改行のためのprintが入っています。

権限を付与します。

sudo chmod 755  test.py

ブラウザから

http://IPアドレス/cgi-bin/test.py

にアクセスすれば「Hello World」と出ます。

SwiftのAttributesをまとめた。

Swiftには定義や型に対して情報を補足するAttributesというものがあります。 Objective-CのNS_AVAILABLE_IOS(8_0)みたいなやつです。

Attributesのフォーマットは引数なしと引数ありの2通りです。

@attributename
@attributename(arguments)

@availability

利用できるプラットフォーム、OSなどを示します。

第1引数はプラットフォーム名で

  • iOS, iOSApplicationExtension, OSX, *

の4つのうちのどれかを指定します。*はワイルドカードで全てのプラットフォームを表します。

第2引数以降はいろいろな組み合わせがあります。

  • unavailable

利用不可能であることを示します。この属性がついたものを利用しようとするとコンパイラがエラーを吐きます。

@availability(iOS, unavailable)
func unavailableMethod() {
}

f:id:tomoyaonishi:20150320180035p:plain

  • introduced="version number"

指定されたバージョンから利用可能であることを示します。

@availability(iOS, introduced=6.0)
func shouldAutorotate() -> Bool
  • deprecated="version number"

指定されたバージョン以降で非推奨であることを示します。

@availability(iOS, introduced=3.0, deprecated=8.0)
var searchDisplayController: UISearchDisplayController? { get }
  • obsoleted ="version number"

指定されたバージョンから使われなくなり、そのプラットフォームから取り除かれていることを示します。対象のプラットフォーム、バージョンのときこの属性がついたものを利用しようとするとコンパイラがエラーを吐きます。

f:id:tomoyaonishi:20150320175728p:plain

  • message

deprecatd, obsoletedと一緒に用いて、コンパイラがワーニングやエラーを出すときにこのメッセージを表示します。

  • renamed

unavailableと一緒に用いて、新しい名称にリネームされたことを示します。

@availability(*, unavailable, renamed="AfterClass")
class BeforeClass {

}

class AfterClass {

}

f:id:tomoyaonishi:20150322134652p:plain

@NSCopying

Objective-Cの@property(copy)と同じです。型はNSCopyingプロトコルに適応していなければいけません。

@objc

Objective-Cからも呼び出せるようにします。

@objc class CustomObject {
    
}

以下のように引数を指定すればObjective-Cからは()内の定義で呼び出せます。

@objc(ObjCObject)
class CustomObject {
    
    var editing: Bool {
        @objc(isEditing) get {
            return true
        }
        set {
        }
    }
    
}

@autoclosure

引数なしかつ評価値を返す式を自動でクロージャにラップします。簡単な遅延評価を行いたいときに便利です。XCTAssert系で使われていますね。


その他は割愛します。

@NSApplicationMain

@UIApplicationMain

@noreturn

@NSManaged

@IBAction

@IBOutlet

@IBDesignable

@IBInspectable


Objective-C版はこちら tomoyaonishi.hatenablog.jp


ドキュメント developer.apple.com

Swiftでxibで作成したカスタムビューのインスタンスを簡単に返す

Objective-Cではxibで作成したカスタムビューのインスタンスを以下のように生成して利用していました。

しかし、Swiftではinitのなかでselfに代入することはできないようです。(もし出来るならやり方教えてください。) なので以下のような書き方でxibからロードしたインスタンスを返すことはできないようです。

let view = CustomView()

f:id:tomoyaonishi:20150320161312p:plain

回避策としてジェネリクスを使ってどんなカスタムビューのインスタンスでも返すことができる関数を作ってみました。

func InstantiateCustomView<T: UIView>(classToCreate: AnyClass) -> T {
    let view = UINib(nibName: NSStringFromClass(classToCreate), bundle: nil).instantiateWithOwner(nil, options: nil)[0] as T
    
    return view
}

使い方は簡単です。

class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
        let view: CustomView = InstantiateCustomView(CustomView)
        self.view.addSubview(view)
    }

}

返り値の型Tが確定しないといけないので、 let view: CustomViewのように型を定義して受け取ります。(スマートじゃない。。)

CustomViewは以下のように定義しています。 

@objc(CustomView)
class CustomView: UIView {
    
}

@objcはCustomViewクラスのクラス名をObjC名前空間に"CustomView"という名前で書きだすという意味です。Swiftではクラス名は"モジュール名.クラス名"となってしまい、NSStringFromClassの返り値をそのままnibNameに渡せません。@objcとつけることでNSStringFromClassで取得できるクラス名がモジュール名なしの形になります。

ちなみにInstantiateCustomView関数は<T: UIView>としているのでTはUIViewのサブクラス以外受け付けません。

もうちょっとスマートにしたいです。。。

iOS8でコードでのAutoLayoutのやり方が地味に変わっていた件

あけましておめでとうございます。

仕事でAutoLayoutでUIを作っていてなんとなく-[UIView addConstraint], -[UIView addConstraints], -[UIView removeConstraint], -[UIView removeConstraints]の定義を見たところ、deprecatedになっていました。正式なdeprecatedではなく

// This method will be deprecated in a future release and should be avoided. 

とコメントに書いてありました。今まではNSLayoutConstraintで制約を作って対象のUIViewのaddConstraint, addConstraintsを呼んでいたわけですが、それが非推奨になっています。

-[UIView addConstraint]の代わりにNSLayoutConstraintのactiveプロパティを使えと書いてあります。-[UIView addConsraints]の代わりには+[NSLayoutConsraint activateConstraints]を使えと書いてあります。後者のクラスメソッドはおそらく引数に渡されたNSLayoutConsraintのactiveプロパティをすべてtrueにセットする便利メソッドだと思います。

NSLayoutConstraintのactiveプロパティをtrueにするとその制約が有効になるようです。今までは対象のviewに対してaddConstraint、removeConstraintで制約を追加、削除していました。activeプロパティは対象のviewに追加する必要がなく、有効にするか、しないかで制約を制御できるようになったようです。

具体的には以下のようにコードを変更します。

NSLayoutConstraint.constraintsWithVisualFormatで複数の制約を作り、それらの制約を有効にする(activeプロパティをtrue)ためNSLayoutConstraint.activateConstraintsに渡します。(制約のactiveプロパティをtrueにすればいいのでKVCでtrueにしても多分同じように動くはずです。)

作った制約をsuperviewに追加するのか、自分自身に追加するのか気にしなくて良くなったので、多少便利になりましたね。

この変更はSizeClassのためでしょうか。Regular, Compact、縦、横画面に合わせてそれぞれ用意しておいた制約をactivateするだけでレイアウトが変えられるので便利な気がします。

正式なdeprecatedではないので、しばらくは大丈夫かと思いますが早めに乗り換えておくほうがよいかと思います。

AutoLayoutでスワイプできるUITableViewCellを実装する

AutoLayoutを使ってセル上を左にスワイプすると、セルの右側がオープンするUITableViewCellを実装してみます。セルの削除のときによく出てくるあれを自分で実装する感じです。 AutoLayoutやstoryboardにある程度知識がある方を前提としていますので、適宜不足している情報は補って実装してみてください><


準備編

  • まずは、通常通りにstoryboardでUITableViewを実装します。
  • 次に、スワイプした時にわかるようにセルの背景色を変えておきます。

f:id:tomoyaonishi:20141012212839p:plain

これで準備完了です。スワイプできるセルを実装していきます。

TableViewを貼り付けているViewControllerは以下のようになっています。普通です。

import UIKit

class ViewController: UIViewController, UITableViewDataSource {

    
    func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        
        return 10
    }
    
    
    func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
        
        return tableView.dequeueReusableCellWithIdentifier("Cell", forIndexPath: indexPath) as UITableViewCell
    }
    
    
}

実装編(storyboard)

  • セルの上にスワイプ用のビューを1枚重ねます。画像のようにセルのcontent view全面に張り付くようにAutoLayoutを設定します。

f:id:tomoyaonishi:20141013205953p:plain

このビューの名前をswipe viewとします。

f:id:tomoyaonishi:20141013210032p:plain

  • swipe viewに設定したAutoLayoutのうち、右側からのConstraintをカスタムセルクラスにIBOutletで接続します。

f:id:tomoyaonishi:20141013210304p:plain

ユーザがセルをスワイプしたとき、このConstraintの値を操作することでセルの右側を開いたり、閉じたりするというわけです。

  • swipe viewもIBOutletで接続しておきます。
@IBOutlet weak var swipeView: UIView!

実装編(コード)

  • ユーザのスワイプを認識するためにカスタムセルに対して、UIPanGestureRecognizerを追加します。
    var panGestureRecognizer: UIPanGestureRecognizer!
    
    
    override func awakeFromNib() {
        super.awakeFromNib()
        self.panGestureRecognizer = UIPanGestureRecognizer(target: self, action: "didPan:")
        self.panGestureRecognizer.delegate = self
        self.swipeView.addGestureRecognizer(self.panGestureRecognizer)
    }

これでユーザがセル上をスワイプした時に、didPan:メソッドが呼ばれるようになります。

  • didPanメソッド内では、ジェスチャーのstateに合わせてそれぞれ処理を行います。

実装は以下のようになるかと思います。

    func didPan(sender: UIPanGestureRecognizer) {
        switch sender.state {
        case .Began:
            let translation = CGPoint(x: -self.swipeViewMarginRight.constant, y: 0.0)
            self.panGestureRecognizer.setTranslation(translation, inView: self.swipeView)
        case .Changed:
            let translation = self.panGestureRecognizer.translationInView(self.swipeView)
            self.swipeViewMarginRight.constant = -translation.x
        case .Cancelled:
            fallthrough
        case .Ended:
            break
        default:
            break
        }
    }

UIPanGestureRecognizerは対象のビュー上をスワイプした量を保持しています。translationInViewメソッドで取得できます。このtranslationのxの値を見ることでユーザが横方向にどれだけスワイプしたのかが分かります。例えば、ユーザが左に100ptスワイプしたときには、translation.xは-100になります。この-100の値をswipe viewの右側からのConstraintにセットすることで、swipe viewはsuperviewの右端から100pt離れるようになります。このようにしてセルの開閉を実装していきます。

.Changedの処理はユーザがビュー上をスワイプするごとに呼ばれます。よって、ここで移動量を取得し、それをConstraintにセットします。.Beganの処理はUIPanGestureRecognizerの保持しているtranslationの値の初期化です。文章で説明がしづらいので割愛しますが、この処理がある場合とない場合で実際に動かしてみるとわかると思います。

  • ひとまずスワイプできるセルの完成です。

実行してみると各セルが右、左にスワイプできることが確認できるかと思います。

f:id:tomoyaonishi:20141013214745p:plain

しかし!!ここで大問題が発生します。なんとスワイプはできてもTableViewのスクロールが出来ないのです。このコードが糞なわけではなく、GestureRecognizerの仕様がそうしています。実はUIGestureRecognizerはデフォルトでは2つ以上同時に認識してくれません。UITableViewにはスクロール認識用のUIPanGestureRecognizerが動いています。そしてセルには自分で追加したUIPanGestureRecognizerがあります。階層的に最初に動作するジェスチャーは自分で追加したジェスチャーですので、こちらの処理だけが動いて、TableViewのジェスチャーが動作しなくなっているというわけです。

  • 2つのジェスチャーが同時に動作するようにする やり方は実に簡単です。UIGestureRecognizerDelegateの
optional func gestureRecognizer(gestureRecognizer: UIGestureRecognizer, shouldRecognizeSimultaneouslyWithGestureRecognizer otherGestureRecognizer: UIGestureRecognizer) -> Bool

このデリゲートメソッドでreturn trueを返すだけです。最初の引数のジェスチャーは自分でセルに追加したジェスチャーです。2つ目の引数がTableViewのジェスチャーです。2つ目のジェスチャーはTableViewのジェスチャーとは限らないので、TableViewのジェスチャーかどうかをチェックして、そうであればtrueを返す処理にすべきです。

func gestureRecognizer(gestureRecognizer: UIGestureRecognizer, shouldRecognizeSimultaneouslyWithGestureRecognizer otherGestureRecognizer: UIGestureRecognizer) -> Bool {
        if gestureRecognizer == self.panGestureRecognizer && otherGestureRecognizer == TableViewのジェスチャー {
        
            return true
        }
        
        return false
    }
  • 実行します。

TableViewのスクロールもできて、セルのスワイプもできると思います。しかし、まだ動作が完璧ではありません。TableView上を少しでも横にスワイプするとセルがオープンしてしまい、使い勝手が悪いです。TableViewを斜めにスワイプするとセルがオープンしつつTableViewもスクロールしてしまうという微妙な実装になっています。できればTableViewのスクロールなのか、セルのスワイプなのかを判定してから、どちらかの動作しかしないようにしたいです。

  • TableVIewのスクロールなのかセルのスワイプなのかを判定する

ここは泥臭い処理になってしまうのですが、セルのジェスチャーの最初の数回のtranslationを監視して、スワイプの角度が一定以上であればTableViewのスクロールとみなしてセルのスワイプの処理をしない、逆にスワイプの角度が一定以下であればセルのスワイプとみなし、TableViewのスクロールをしないように切り替えることになります。ちょっとコードが複雑になっていますが、こんな感じになるでしょうか。(もっとスマートにできる方法知ってる方は教えて下さい!)

    var tableView: UITableView {
        
        return self.superview?.superview as UITableView
    }

    var trackingCount = 0
    var trackingTranslation = CGPointZero
    var allowsSwipe = false
    
    
    func didPan(sender: UIPanGestureRecognizer) {
        switch sender.state {
        case .Began:
            let translation = CGPoint(x: -self.swipeViewMarginRight.constant, y: 0.0)
            self.panGestureRecognizer.setTranslation(translation, inView: self.swipeView)
        case .Changed:
            let translation = self.panGestureRecognizer.translationInView(self.swipeView)
            
            // 最初の数回のtranslationを別途保持してスワイプの角度を計算し、
            // TableViewのスクロールなのかセルのスワイプなのかを判断する
            self.trackingCount++
            self.trackingTranslation.x += translation.x
            self.trackingTranslation.y += translation.y
            if trackingCount == 3 {
                self.allowsSwipe = self.allowsSwipeWithTranslation(self.trackingTranslation)
            }
            
            if self.allowsSwipe {
                self.tableView.scrollEnabled = false
                let translation = self.panGestureRecognizer.translationInView(self.swipeView)
                self.swipeViewMarginRight.constant = -translation.x
            }
        case .Cancelled:
            fallthrough
        case .Ended:
            self.trackingCount = 0
            self.allowsSwipe = false
            self.trackingTranslation = CGPointZero
            self.tableView.scrollEnabled = true
        default:
            break
        }
    }
    
    
    func allowsSwipeWithTranslation(translation: CGPoint) -> Bool {
        // スワイプの角度を計算して判断する
        let slope: CGFloat = abs(translation.y) / abs(translation.x)
        let radian: CGFloat = atan(slope)
        let angle = radian * 180 / CGFloat(M_PI)
        
        if angle >= 0 && angle <= 30 {
            
            return true
        }
        
        return false
    }

.Changedで最初の3回までself.allowsSwipeがfalseなのでセルのスワイプ動作は起こらず、3回目のif文の中で3回分の移動量でスワイプの角度を計算します。xの移動量とyの移動量が取れるので簡単にわかります。そしてその角度が一定以下であればself.allowsSwipeにtrueを入れるようにしてセルのスワイプを動作させます。そのときTableViewはスクロールしないようにします。 逆に3回目のif文でTableViewのスクロールだと判断した場合には、self.allowsSwipeにはfalseが入り、セルのスワイプ処理は動作しません。

.Endedでは、一連の処理で使用した変数の初期化を行います。


まとめ

今回はスワイプできるセルをAutoLayoutで実装しました。骨組み的なところしか載せていないので、細かい処理は記述していません。セルを開くときにアニメーションさせたり、右側だけでなく左側も開けるようにしたり、開くことができる幅の上限を処理したりと完璧なスワイプを実装するにはまだまだ多く実装することがあります。

最後に気づいた方もいるかもしれませんが、今回の実装だとAutoLayout的にswipe viewのwidthが小さくあります。swipe viewが圧縮されるとでもいいますか。左側のConstraintはそのままですから、全体が横にスライドするわけじゃありません。なのでsiwpe viewにUILabelなどを載せているとスワイプする度にUILabelの中身が幅に合わせてリサイズされて再描画されます。そのままスライドしているように見せるには、右側のConstraintの値にマイナスを掛けた値を左側のConstraintにセットします。そうすれば幅は固定のままswipe view全体が左に移動しているように見えます。

以上です。

ソースコード

TomoyaOnishi/SwipableCell · GitHub

UITableViewCellの高さを自動で計算する: UITableViewAutomaticDimension

UITableViewCellのUITableViewAutomaticDimensionを使えば、セルのそれぞれの高さを自動で計算させることができます。

    optional func tableView(tableView: UITableView, heightForRowAtIndexPath indexPath: NSIndexPath) -> CGFloat

こいつとはおさらばです。

以下実装方法です。


まず通常のUITableViewの実装の方法でStoryboardを作っていきます。 カスタムセルに対してUILabelを1つ置きます。ここで以下の画像のようにセル全体にLabelが広がるようにAutoLayoutを設定します。なお、カスタムセルではなくBasicStyleのセルであればここでは何もしなくてもよいです。

f:id:tomoyaonishi:20140927160105p:plain

次にカスタムセル、BasicStyleのセルであったとしても以下のようにLabelのlineプロパティを0にして複数行入るように変更します。

f:id:tomoyaonishi:20140927160113p:plain

後はViewController側で以下のようなソースコードを書きます。

class ViewController: UIViewController, UITableViewDataSource {

    @IBOutlet weak var tableView: UITableView!
    
    
    let phrases: [String] =
    [
        "やっほー",
        "すげええええええええええええええええええええええええええええええええええええええええええええええええええええええええええ",
        "TableViewCellが自動でセルの高さを計算しています!!!!!!!!!!!!!",
        "\n\n\n\n\nホントです。",
    ]

    
    // MARK: Life cycle
    
    
    override func viewDidLoad() {
        super.viewDidLoad()
        self.tableView.estimatedRowHeight = 100.0
        self.tableView.rowHeight = UITableViewAutomaticDimension
    }
    
    
    override func viewDidAppear(animated: Bool) {
        super.viewDidAppear(animated)
        self.tableView.reloadData()
    }

    
    // MARK: UITableViewDataSource
    
    
    func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
        
        return self.phrases.count
    }
    
    
    func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCellWithIdentifier("Cell") as MyTableViewCell
        cell.label.text = self.phrases[indexPath.row]
        
        return cell
    }
    
}

これで実行するとセルの高さが自動で計算されてTableViewが表示されます。

f:id:tomoyaonishi:20140927161107p:plain

サブビューが2つ以上ある場合でもAutoLayoutをうまく貼れば自動で計算されます。 iOS8, Xcode6で試しました。

Xcode6でベクター画像を利用する。

Xcode6で密かにベクター画像が使えるようになっています。 これを使えば@1x, @2x, @3x画像を用意する煩わしさから解放されます! 使い方は非常に簡単です。

  • PDF画像を@1xのサイズで書きだす。
  • AssetCatalogをクリックする
  • New Image Setで画像セットを追加する
  • 画像のようにAttributesのTypesをVectorsに変更する

f:id:tomoyaonishi:20140921160517p:plain

  • 作成したPDF画像を置く。

こうすれば後は今までと同じように画像を扱えます。 注意しなければいけないことは完全なベクター画像の対応というわけではなく、ビルド時に@1x, @2xなどの各PNG画像が書き出されるようです。ソースコード上で拡大や縮小ができるわけではないようです。

デザイナーの負担もエンジニアの負担もすごく軽くなりますね。

WWDC 2014 Session Videos - Apple Developer

Swift: NSUserDefaultsに配列が保存できない

Swiftでプライベートで開発中のアプリでこんな出来事に遭遇しました。

        let array = ["1", "2", "3", "4"]
        NSUserDefaults.standardUserDefaults().setObject(array, forKey: "key")
        NSUserDefaults.standardUserDefaults().synchronize()
  
        let array = NSUserDefaults.standardUserDefaults().arrayForKey("key") as? [String]
        println(array) // nil

NSUserDefaultsに配列が保存できないという罠にハマりました。 原因究明まで結構時間がかかりましたが、結論としては保存する配列を as NSArrayとすることです。 コードでは以下のようになります。

        let array = ["1", "2", "3", "4"] as NSArray // NSArrayにキャストする!
        NSUserDefaults.standardUserDefaults().setObject(array, forKey: "key")
        NSUserDefaults.standardUserDefaults().synchronize()
  
        let array = NSUserDefaults.standardUserDefaults().arrayForKey("key") as? [String]
        println(array) // Optional ["1", "2", "3", "4"] 

なぜこうなるのか理解できていません。Xcode6 beta6です。Swiftの配列はNSCodingを実装していないから?ネットで検索するとSwiftの配列も普通に保存できると書いてある記事もある。 でも確実に自分の環境ではNSArrayにキャストしないと保存できない。これは確実です。 もし、NSCodingを実装していないからだというなら、SwiftからiOS開発する人にはちょっと厳しすぎる仕様ですね。むしろSwiftになったせいでObjective-Cの開発でも意識しないようなFoundationのもっと深い知識が各所で要求されるようになった気もしています。特にCoreFoundation系のAPIを使うときによく感じます。自分がまだ理解不足なだけだと思うのですが、CoreFoundation系を使っているとたまに変換したい型までもっていけないことがありますw(暗黙の型変換がないせいで)

この件に関してはバグかもしれないし、実際どうなのかはよくわかりません。

SLRequestを用いたTwitterのin_reply_toツイートがうまくいかない

Twitterのリプライでin_reply_toを実装していて少しハマりました。 in_reply_to_status_idをパラメータに入れているのに、会話形式で表示されないという問題に遭遇しました。

SLRequestに渡すパラメータのNSDictionaryの中にin_reply_to_status_idをキーにNSNumber型でリプライ先のツイートIDを指定していたのですが、これをリプライ先のツイートIDはid_strを取得するようにしてNSString型でセットしてみると会話形式で表示されるようになりました。数値か文字列かよくわかりません。

{
    "in_reply_to_status_id" = 505962876931043328; // NSString型にしておく
    status = "@Tomoya_Onishi \U306f\U306f\U306f\U306f";
}

SwiftからObjective-Cのenumを扱う時の注意事項2

注意事項というかObjective-CenumSwiftはどう解釈するかのメモ

ObjC側でのenum

typedef enum : NSUInteger {
    MyEnumValueA,
    MyEnumValueB,
    MyEnumValueC,
} MyEnumValue;

があったとする。この定数をSwift側からさわろうとするとほとんどの場合でエラーになります。

SwiftはNS_ENUMあるいはNS_OPTIONSで定義されたCスタイルのenumのみを自動でSwiftでのenumに変換します。

NS_ENUM, NS_OPTIONSでenumを定義するように変更する。

NS_ENUM (NSUInteger, MyEnumValue) {
    MyEnumValueA,
    MyEnumValueB,
    MyEnumValueC,
};

そうするとSwift側で

enum MyEnumValue: Int {
    case A
    case B
    case C
}

という形で自動で読み込んでくれます。後はSwiftでのenumと同じ挙動になります。 ビット演算でのenumにはNS_OPTIONSを使ってください。

参考 Using Swift with Cocoa and Objective-C: Interacting with C APIs

SwiftからObjective-Cのenumを扱う時の注意事項

Swiftを使って開発していても、OSSなどはObjective-Cで書かれたものを使うことはよくあります。 SwiftからObjective-Cのクラスなどを使うにはヘッダーファイルを用意するだけですが、Objective-C側に書かれたenumの扱いには注意が必要です。

結論から言うと、Objective-C側のenumの定義には

NS_ENUM
NS_OPTIONS

のマクロを使って定義するようにしてください。

typedef enum 

での定義ではSwift側で扱えません。

ビット演算でのオプションの定義などはNS_OPTIONSマクロを使わないと、 swift側で | & などのビット演算子での処理ができません。(エラーになってしまいます。)

もしObjective-Cの定数をSwiftで使っていてエラーが出るときは、enumの定義の仕方を調べてみましょう!

マクロの使い方についてはこちらをどうぞ!

メソッド、クラス、変数、定数宣言時に使えそうなものまとめ - tomoyaonishiのブログ

Swift: AutoLayoutでUIVisualEffectviewをアニメーションさせてみた

iOS8からUIVisualEffectViewというものが追加されました。このビューは様々なエフェクトを自動で表示することができます。Appleの公式すりガラス処理を実現することができます。 今回は、Swiftを使って、このクラスの使い方とAutoLayoutによるアニメーションをまとめます。


スライドにもまとめています。

UIVisualEffectView

様々なエフェクトを自動で表示することができるビューです。Appleのすりガラス処理もしてくれます。具体的にどんなエフェクトにするかを決めるのはUIVisualEffectという別のクラスです。インスタンス生成時にこのクラスを渡します。

UIVisualEffect

エフェクトの種類を指定するクラスです。利用するのはそのサブクラスでUIBlurEffect, UIVibrancyEffectの2つが現在のところ用意されています。UIBlurEffectがすりガラス処理です。 UIBlurEffectにはスタイルが3つあります。非常に明るいブラー、明るいブラー、暗いブラーの3つです。

enum UIBlurEffectStyle : Int {
     case ExtraLight
     case Light
     case Dark
}

UIVisualEffectViewの生成方法

実際の生成コードは以下のようになります。

let effect = UIBlurEffect(style: UIBlurEffectStyle.Light)
let effectView = UIVisualEffectView(effect: effect)
// set frame
view.addSubview(effectView)

これだけのコードでApple公式のすりガラス処理が入るビューを利用することができます。UIImage+ImageEffectのように画像ではなく、動的に描画されるのでビューを動かしても問題ありません。また、動作も早いです。

AutoLayoutでアニメーション

今回はさらに、このビューをAutoLayoutを使ってアニメーションさせてみます。 frameでのアニメーションは一般的なので問題無いと思いますが、AutoLayoutでのアニメーションはどのようにやるのかわかりますか?

AutoLayoutではframe, boundsは基本的には触りません。むしろ勝手にいじるとAutoLayoutの整合性が保てなくなりクラッシュすることもあります。

では、どうするか。AutoLayoutの実態であるNSLayoutConstraintクラス(AutoLayoutではこれを制約という)を操作します。 NSLayoutConstraintクラスにconstantというプロパティがありますが、このプロパティはその名の通り、距離を表します。例えば、画面の左端から10ptあけてビューを表示するという制約(NSLayoutConstraint)があったとき、constantは10です。ここでconstantに100を入れると、画面左端から100ptの場所に移動します。frameは意識しなくてよいです。例えば、幅は100ptで固定するという制約があった場合、そのconstantに200を入れると幅が自動で200ptになります。ここでもframe, boundsを直接操作する必要はありません。 このようにAutoLayoutでは、制約のconstantを変更することでレイアウトを動的に変えることができます。もちろん、制約の再生成でもよいですが。

では、具体的にアニメーションのコードを見てみましょう。一部省略しています。 まずはUIVisualEffectViewを生成し、コード上でAutoLayoutを適用します。

// viewDidLayoutSubviewsかviewDidAppear内で
// View
let effect = UIBlurEffect(style: UIBlurEffectStyle.Light)
let effectView: UIVisualEffectView = UIVisualEffectView(effect: effect) effectView.clipsToBounds = false
// falseにすると AutoResizingMaskをAutoLayoutの制約に自動変換しないようになる
effectView.setTranslatesAutoresizingMaskIntoConstraints(false)
view.addSubview(effectView)

// AutoLayout
// NSDictionaryOfVariableBindings関数はどこにいったのかよくわからないので自分で辞書を生成
let views = ["effectView" : effectView]
let metrics = ["marginZero" : 0, "marginTop" : 100]

// 水平方向の制約を追加:superviewに対してぴったり張り付く
let horizontalConstraints: AnyObject[] =
NSLayoutConstraint.constraintsWithVisualFormat("|-marginZero-[effectView]-marginZero-|",
                                                options: NSLayoutFormatOptions(0),
                                                metrics: metrics,
                                                views: views)
view.addConstraints(horizontalConstraints)

// 垂直方向の制約を追加:superviewに対して上は100ptあける、下はぴったり張り付く
let verticalConstraints: AnyObject[] =
NSLayoutConstraint.constraintsWithVisualFormat("V:|-marginTop-[effectView]-marginZero-|",
                                                options: NSLayoutFormatOptions(0),
                                                metrics: metrics,
                                                views: views)
view.addConstraints(verticalConstraints) 

// アニメーションのために上からの制約を保持
let constraint : AnyObject = verticalConstraints[0]
marginTopConstraint = constraint as? NSLayoutConstraint

これでUIVisualEffectViewは画面に対して、上から100あけて、左、下、右は画面にピッタリくっつくように表示されます。AutoLayoutなので横向き、iPad、どんなサイズの画面でも同じように表示されます。frameもboundsもいじっていません。

次に、アニメーション部分です。Storyboard上では、ブラーの効果がわかりやすくするため画面いっぱい広がるように適当な画像を表示しておき、ボタンを1つおいてIBActionで接続しておきます。そのボタンを押すたびにUIVisualEffectViewがアニメーションします。

var flag : Bool = false
@IBAction func didTapButton(sender: UIButton) {
    if let constraint = marginTopConstraint {
        UIView.animateWithDuration(1.0,
            delay: 0.0,
            usingSpringWithDamping: 0.5,
            initialSpringVelocity: 0.1,
            options: UIViewAnimationOptions(0),
            animations: {
          // frameのアニメーションと同じ考えだとアニメーションできない 
          // constantを変更するだけでは足りない 
         constraint.constant = self.flag ? 150 : 500
          // 画面の再描画を呼び出す必要あり 
         self.view.layoutIfNeeded()
            },
         completion: nil)
         flag = !flag 
    }
}

これを実行すればびよんびよんとアニメーションするはずです。 基本的にはAutoLayoutはStoryboard上で設定するはずです。その場合は、IBOutletと同じようにNSLayoutConstraintを接続すれば変数が作れます。

個人的にはframeによるレイアウトはiOS7のころから終わっていると思っています。Xcode5にも16:9, 4:3などのレイアウト設定がありました。Androidはとっくの昔に絶対座標での指定は非推奨になっています。Xcode6のことはあまり詳しく書けませんが、さらに多種多様な画面サイズを試すことができるようになっているので基本的にはAutoLayoutでやりましょうというスタンスがよいと思っています。