投稿

Objective-Cで保存したアーカイブデータをSwiftで読み込む

アプリをObjective-CからSwiftに書き換える際、少し悩むことに、Objective-Cで保存したアーカイブデータ(ユーザーのデバイスに保存されている)をSwiftで読み込むにはどうすればいいのかということがあります。 ここでは、NSKeyedUnarchiverやNSKeyedArchiverクラスを用いて利用するアーカイブデータがデバイスに保存されている場合に限定して、アプリをSwiftに書き換える時の手順などをまとめます。 ファイルの場所の指定 データの保存と読み込みではファイルの場所を指定します。ファイルの場所の指定はObjective-CとSwiftでほとんど同じ感覚でいけます。 var fileName = "" let paths: [String] = NSSearchPathForDirectoriesInDomains(.DocumentDirectory, .UserDomainMask, true) if 0 < paths.count { fileName = paths[0] fileName.appendContentsOf("/targetObject.dat") //print(fileName) } if 0 < paths.countは一応入れといた。 ちなみにstringByAppendingPathComponentというNSStringクラスのメソッドは使えなくなったようです。追加するものの前に自動的に/を加えるメソッドです。URLクラスに同じ機能のメソッドがありそっちを使えと表示が出ます。使えなくなったのが意図的だとすればStringとして扱うかURLとして扱うか中途半端ということでしょうか。 アプリにアーカイブ機能を付けるためにソースを書く部分 主に3つあります。 1 : データを保存するところ 2 : データを読み込むところ 3 : データ自体の定義 データの保存/読み込み データの保存/読み込みの仕方は A : オブジェクトをファイルに直接アーカイブする B : NSDataを介してオブジェクトをファイルにアーカイブする と2つあります。保存時と読み込み時でやり方が「対」になっていると余計...

Swiftのオプショナルのオプショナルて何??

イメージ
オプショナルのオプショナルはあります。 正式な呼び方がなんなのかはわからないけど確かにあります。ちょっと長くなるけど調べたときのいきさつ形式で書きます。 エラーハンドリングについて調べていたときに以下のコンパイルエラーに遭遇しました。 Value of optional type 'Int?' not unwrapped; did you mean to use 'try!' or chain with '?'? オプショナルの値のInt?はアンラップされません、やろうとしていることはtry!か、?を使った連鎖で出来ませんか? このエラーは以下のようなプログラムの最後にある try? で出ました。実行はPlaygroundです。 enum MyError: ErrorType { case myError } func someThrowingFunction(a: Int) throws -> Int { if 1 < a { throw MyError.myError } return a } func someFunction() { let a: Int = try? someThrowingFunction(5) //ここでエラー発生 } このエラーメッセージは、「try? というのは戻り値を格納する値の型をオプショナル型にする必要があるのでして下さい」という趣旨のメッセージです。ここでは最後のaの宣言を Int? にすればよいです(または型を書かずにコンパイラに推論させればよい)。 まあこれでこの件は解決なんですが、ただ、メッセージの最後の chain with '?' (?を使った連鎖)が気になりました。chainは連ねるという意味ですから??のように重ねること?なぜこの状況でchainが出てくるのか?といろいろ考えているうちに、もしかして ?? というものがあるのでは?と思い、以下のプログラムを試してみました。メソッドの戻り値を Int? にしてみました。 //戻りをInt?に変更 func someThrowingFunctionOPT(a: Int) throws -> Int? { if 1 < a...

従来のソフトのままでiPad Proの画面に対応する方法

イメージ
以下の記事はちょっとまだ公式のソースを確認できていないので自己責任でお願いします。 iPhoneが3.5インチサイズから4.0インチサイズに移行したときは4.0用の起動画面を用意することで4.0に対応していることを示すやり方でした。用意しなければ真ん中に3.5インチサイズの画面が出て、黒い帯で上下の空いた領域を埋める仕様でした。iPhone6や6sのときも対応/非対応の区別は起動画面を用意するかしないかでした。 今回iPad Proが新規解像度2732 x 2048で出てきましたが、対応/非対応のポイントはやはり起動画面のようです。 ただ今回はファイルを用意するのではなく、Launch Screen File(storyboard風のやつ)が設定してあることが「iPad Proに対応している(2732 x 2048も想定して描画処理を書いてある)」ことを示すようです。図のSourceのほうではなくてFileのほうです。iPad Pro対応しないとき(iPadのレギュラーサイズの画面を引き伸ばしたいとき)は「なにも設定しない」にしてください。こうすることで内部でiPadレギュラーサイズとして描画したものをiPad Proの画面の大きさに引き延ばすような処理になります。 ちょっとまだ公式のソースを確認できていないので自己責任でお願いします。実機はまだ発売されていないので確認したのはシミュレータのみです。Xcodeは7.1です。 未来ぽい感じがして好きだったんですが一旦OFFにしておきますかね。

Swift 2.0でStringはどうなったか - 特殊文字などの扱い

イメージ
Objective-CのNSStringの仕様は自然ではなかったので、Swiftには期待しています。 Swift2.0でStringの仕様がだいぶ変わったということで検証してみます。 昔は何が困ったか 今回のStringの仕様の検証は、昔の仕様で困っていた部分が動機になっているので、まずそれを書きます。NSStringでは文字を基本的に16ビットで扱っていますが、文字の中には16ビットで扱えないものがあり、そういうものは32ビットなど他の長さで使用します。そのごちゃごちゃはUnicodeの仕様上仕方ないのですが、NSStringではその32ビット文字を2文字としてカウントするなどUnicodeのごちゃごちゃをうまくさばききれていなくて扱いが雑な部分がありました。 欲しいものは、内部で何ビットだろうとどういうどういうデータ状態であろうと、人間が一文字と認識するものは一文字として扱うというポリシーに従ったAPIです。 Swiftが発表になったときにUnicodeとの親和性もアピールしていたので期待しています。 The Swift Programming Languageを読む まずはいつものThe Swift Programming Languageで基本をおさらい。 ・Stringはvalue typeである(reference typeではない)。 ・Stringの文字列に含まれている個々の文字へのアクセスにはStringのcharactersプロパティからアクセス出来る。 ・SwiftのStringは内部ではUnicode scalarをベースにしている。Unicode scalarとは文字や記号に対応する21ビットの数。U+0000からU+D7FFとU+E000からU+10FFFFがある。U+D800からU+DFFFは含まない。U+が何かというのは大変ややこしいので割愛。 ・人間が文字と認識する形式がExtended Grapheme Cluster。SwiftのCharacterは一つのExtended Grapheme Clusterに対応。 一つのExtended Grapheme Clusterは一つ以上のUnicode scalarで構成される 。 ・Stringの文字数カウントはcharactersプロパティのcountプロ...

Swiftブログの要点まとめ 2015

イメージ
appleの公式Swiftブログ(英文) の各記事の要点を日本語でまとめます。 英語のトレーニングを兼ねて... Swift is Open Source 2015年12月3日 Swiftはオープンソースになりました。 関連項目は Swift.org Swiftに関わる人のためのサイト github.com/apple ソースコードの置き場 Swiftパッケージマネージャーというコードを共有したりビルドするためのツール Swiftネイティブコアライブラリというスタンダードライブラリの上のレベルのもの LinuxだけでなくAppleのプラットフォームにも対応 Literals in Playgrounds 2015年10月7日 Playgroundでファイル、色、画像の扱いが可能になりました。 Swift 2 Apps in the App Store 2015年9月21日 Swift 2で作成したアプリが提出可能になりました。 Xcode 7はSwift 2を含みます。Swift 1.2から変更するにはEdit > Convert > To Latest Swift Syntaxを使用して下さい。 OS X El CapitanでXcodeを使うならXcode7を要求します。Xcode 6を使い続けるならOS X Yosemiteのままにして下さい。Xcode 7とYosemiteの組み合わせはOK。 Swift-er SDK 2015年8月12日 Xcode 6.3でObjective-Cに新しい機能のnullability annotationsが付きました。SwiftのOptionalに相当します。 Strings in Swift 2 2015年7月23日 Swift 2ではStringの仕様が変わります。 今までStringはCharacterのコレクションとして扱ってきましたがSwift 2ではそうではありません。Swift 2ではStringはcharactersというプロパティを持ち、そのcharactersプロパティがコレクション(文字の集まり)の性質を請け負います。 変更の理由は、StringはArrayやSet,Dictionaryといったコレクションとは極め...

Xcode7の時点でCertificate(証明書)とProvisioning Profileの作成は(ほぼ?)全自動に

イメージ
Certificate(証明書)とProvisioning Profileを全部削除した状態で、Xcode7でデバッグ(手元デバイスでの動作チェック)とストアへの申請を行い、どの程度自動作成機能が使える状態になっているか確認する。頻繁にチェックしているわけではないので実はXcode6のときにすでに出来ていたと言われる可能性もあるが、とりあえずやってみる。 1、developer.apple.comのCertificates,Identifiers & ProfilesページでCertificateとProvisioning Profileを全部削除する。App IDとDeviceは使用するものが設定してある。App IDはそれぞれのアプリ個別のもののみがある。 2、Xcode7の環境設定の中のAccountsのView Details...ボタンをクリック。出てきた一覧表に上下2つのエリアがありますが、上のSigning IdentitiesはCertificateに対応しているようです。Provisioning Profileがあれば(ローカル環境に残ったもの?)削除する。Signing IdentitiesのiOS DevelopmentとiOS DistributionにはCreateボタンがあるが作成はせずにスルー。 3、Xcode7でプロジェクトを開く。Bundle Identifierは設定してある。当然、No provisioning profiles foundの黄色警告が出る(ターゲット設定のGeneralタブのIdentitiy)。修正するためのFix Issueボタンも表示される。この時点でシミュレータでは実行可能。 実デバイスで実行しようとするとNo Provisioning profiles foundの赤色アラームが発生。実デバイスでの実行は不可。 4、ここでお待ちかねのターゲット設定のGeneralタブのIdentitiyのFix Issueボタンを押す(裏で何をやっているかわからないから好きではないという意見もあるかも)。すると iOS DevelopmentのCertificateが作成 され(Createボタンが消える)、App IDにも Xcode iOS Wildcard App IDという...

iOS9対応でやったこと

[NSLocale preferredLanguages] [NSLocale preferredLanguages]で返ってくる言語設定が iOS8まで ja iOS9から ja-US のようになったので対応。 isEqualToString:@"ja" から hasPrefix:@"ja" へ変更すればOKと思いましたが ジャマイカ... が脳裏をよぎり isEqualToString:@"ja"とhasPrefix:@"ja-"のORにしておきました。 NSManagedObjectContext [[NSManagedObjectContext alloc] init]が9.0でdeprecatedになったので [[NSManagedObjectContext alloc] initWithConcurrencyType:] に変更しようと思ったがConcurrencyTypeの設定が難しすぎて一旦保留。 Requires full screen iPadアプリで「全方向対応でない場合はRequires full screenをONにするように」というワーニングが出たのでONにする(そのアプリは縦のみ対応)。 このパラメータはSlide OverやSplit Viewで画面の一部の表示をされたくない時にもONにするものらしい。 (追記 : 以下のバグはXcode7.1.1では修正されていました) ちなみにiOS9.0 Xcode7.0の段階でSlide OverやSplit Viewを有効にするとなぞのバグ(?)があって、 フルスクリーン状態で(Slide OverやSplit View状態ではない)デバイスを回転させて、UIDeviceOrientationDidChangeNotificationを受けた時に self.view.bounds.size.width self.view.bounds.size.height が変更前の状態で取得されてしまって使えなくなるという現象があった。その値を元に全体の要素を配置しているので、縦にすると横の配置になり、横にすると縦の配置になるという現象。 [[UIApplicati...