今日はSwift日和２ [プログラミング]
PDFを表示するアプリを作るんですが、前回は雛形を見るところまででした。よく分からなかったので、サンプルコードを漁る事にしました。
ここで
https://developer.apple.com/library/ios/navigation/#
PDFの表示の奴はこれしかなかったので、落として開いてみました。
https://developer.apple.com/library/ios/samplecode/ZoomingPDFViewer/Introduction/Intro.html#//apple_ref/doc/uid/DTS40010281
あ〜これはiOSのかもしれないけど、Objective-Cの物ですねぇ。まずはSwiftのソースを見た方が良いような気がするので、これは追い追い使う事にしましょう。
これが良さそうかなぁ。
https://developer.apple.com/library/ios/samplecode/UICatalog/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007710
zipファイルの中に、Objective-CとSwiftのソースが入っていて、どちらも同じ挙動になっている模様。なので、今まで開発してきた人は、Obj-Cのソースを参照できるような感じになっているのだろう。Xcodeってプロジェクトを複数開けるんだったっけ？
とにかく、始めてのガッツリSwiftのソースに突っ込んでみたい。
このプロジェクト自体はサンプルもいいところで、メニューがたくさんあってそれを選んで見ていける。UICatalogという文字通りの、色々な表現の仕方のカタログみたいになっている。
対応するソースは始めに示されるページのメニューと、Swiftソースの名前が同じになっていてそのままで非常に分かりやすい。本当に初心者向けですね。このソースを選んで良かったなぁ。ただ、見た目は.xibファイルとか.nibファイルじゃなくて、ソースにベタ書きみたいです。まぁそっちの方が移植するのには楽だろうけど、にっくきAndroidに簡単に移植できるようにするはずもないわけで。
そういや、GUIをソースで書くのってJavaっぽいなぁ。というか、Visual StudioとXcodeの方が特殊なだけか。見た目はコーディングしなくて良いってのでVBとかはお気軽に使われるようになったわけだけど、なんつーかGUIの表現方法が一巡してきている気がしますね。HTML5とかでマークアップしてGUIの表現をするのもそうだけど、更にAjaxとDOMとかでGUIを動的に書き換えるってのも、Webアプリが増えた理由なのかなと思ったり。
トップページから分岐していくメニューの先は分かったんだけど、一番始めに示されるページはどこなのかな。Swiftソースだと思うんだけど、すぐに見つからない。あ、GUIをソースで書いてるんじゃないわｗ。てへっ
ええと、Main.storyboard ってのがGUIを表現していました。これがnibファイル系統の物と同じと考えていいのかなぁ。自分で作っていないから分からないけど。画面の遷移表も兼ねているみたいで、その挙動をSwiftのソースで紐付けて表現ってのはObj-Cと同じ事だと思う。ん〜妙にズームアップしているので、もう少し中身を小さくして俯瞰で見たい。
Visual Studioとかだと、GUIからウィザードにしたがって（ウィザードって言い方も古いので今はないのかも知れないが…）、ソースの雛形が形成されたけど、Xcodeとかは自分でやらなあかんかった気がする。少なくともつなぐoutletとかは先に書いておかないとダメだったんだっけ？
にしてもストーリーボードってのはもうちょっと表示を小さくできないかなぁ。おいらのMacbook Pro画面がそんなに大きくないので厳しい。これはThunderboltでマルチディスプレイにしろと言う事か。まぁ少なくともこういう物を書きながら作業するなら、一枚のディスプレイよりか複数あった方がいいに決まっている。Mini DisplayPortからHDMIかDVIに変換するのっていくらぐらいするんだっけ。どちらかに出来ればアダプタかませてつなげるんだけどな。あ、1000円位から買えるのね～。
買っちゃおうかなぁ。配送料無料だし。他のだと接触不良とか出てるんだよね。これも使ってるうちに出てくるんだろうけど、一応安すぎないところは買う。実際に買うかどうかは分からんけど。
う〜ん、色々な意味でなかなか過去のおぼろげな記憶が生かせてない。一番上から順にソースを見ていく。ActivityIndicatorViewController.swiftですが、ただ待ち状態のグルグル表示がふたつあるだけの物。
そんなに長くないけど、予約語とかライブラリに関するオブジェクト名とかは全然分からん。
@IBOutlet weak var grayStyleActivityIndicatorView: UIActivityIndicatorView!
ってのは書いてある通りoutletなんだろうけど、weakって何だ？ 弱い？
それとクラス名に?を付けて、クラスインスタンスな変数を作るのは、The Swift Languageの始めで読んだんだけど、!を付けたのは見た事がない。んむ〜見てすぐに分からないノーテーションって困る。
「?」も「!」もOptionalsの関係だけど、Optionalsってのがnilの場合は、まともな値が入ってないよってことらしい。ただ宣言した時は中にnilを入れておいて、代入して初期化した後はnilじゃなくなるってだけなのかなぁ。でも、代入したオブジェクトの型を気にして不正な場合はnilにするとかはないのかな。所詮Objective-Cのラッパーだから、そこまでやってくれてそうもないけど、そこまで調べてない。
ええと「!」ね。宣言の時に!を後ろに付けておくと、代入して初期化してないのに使おうとするとランタイムエラーになるらしい。基本outletは動作してから値を突っ込まれるから、コーディング時には確定していないだろう。なのでコンパイル時にもチェックできないので、動作する時にチェックしましょうって話でしょう。runtime errorってのがどう発動するのかはよく分からないけど、変な値でたまたま動いちゃったりする事は無くなるわけだ。
あとは、weakですかね。これはObjective-Cのコードにもあった気がします。Obj-Cの本を読むとweakってのはARC用に取り入れられた物らしい。The Swift Languageにもやたらweak referenceとかいう言葉が出てくる。@propertyの値の設定方法のオプションですた。ってプロパティが何だとかから説明するのもなんだから飛ばすけど、Javaとかの他のOO言語を使っている人には同じもとの分かるはず。
結局、ARCってのがメモリの生成や削除に関する仕組みで、Obj-Cでメモリの扱いが面倒だから取り入れられたものです（ガベージコレクションは一度やったけどやめたっぽい）。weakってのは弱い参照をしているから、他のところで開放されても構わないってことだよね、retainじゃないって話だから。参照先で中身が開放されても、nilが入って処理される。そして、参照先のオブジェクトが自分のオブジェクトのretainで握っちゃってて、開放できないって事態も防げる。あるとかないとかは、その時によって柔軟に判断されるわけだ。ARC面倒だな。でもiOSだとオーベーヘッドが大きいからやめたんでしょ？ AndroidとかだとGC使えるから、そこのところはObj-CもSwiftも面倒なのは変わらない。
とりあえず、outletはweakで!なオブジェクトとして生成するって事は分かった。まぁそういうのはお作法的にマネするしかないんだけどね。ヘタにいじるとまともに動かないからさ。
overrideってのは元々ある継承した上のクラスの関数を再定義するのは、普通にOO言語的に考えると分かる。superってのは上のクラスの事で、それも同じだよね。
その後は、UIKitのクラスの問題だけかな。これは腰を据えてドキュメントを漁らないといけないだけなので、そんなに問題じゃない。気になるところをピンポイントで調べていけばいい。まぁ始めはほぼ全部ググることになるのだけれど、そのうち大体見当が付いてくるから始めだけ気にすればいい。
んで、気になるところなんだけど、.Grayってのは何なんだって話。
こんな時は⌘＋クリックで宣言位置に飛べる。
色を指定しているのは分かっていたけれども、記法としての= .Grayってのがよく分からん。これはenum独特の記法なのか。それとも型推論で重複する型は省略して書けるのであろうか。
http://codezine.jp/article/detail/7886
代入する時は、型推論で「型.メンバー」みたいな形を採らなくても「.メンバー」で済むらしい。いきなりこういう事されても御上品な書き方しかできない人にとっては正確にソースが読めないかも。まぁ慣れなんでしょうけど、書くのは楽でも読むのはちょっと気持ち悪い。a = a + 1をa += 1と書くような物と思えばおかしいとも思えないが、年取ると新しい物を受け入れるのが難しくなるもんだ。
あとは⌘＋クリックで各自のクラスの宣言を読んで、ソースが分かりにくかったらググってドキュメントを漁ってください。あぁ、これで何とかなりそう。開発するにもお金がかからず楽になったもんだね。まぁ稼ぐ気持ちがあったら本を買っちゃって読んだ方が速いんでしょうけど。日本人には英語が読めたとしても少なからずや負担だし、きちんと書かれている本さえあれば、それを買ってお金で解決するのも悪い選択肢ではない。
でも、趣味でやるくらいなら自力で一次情報を当たって、自力かググって解決するのが時間はかかるけど実力もつく良い方法だとは思う。今の時代で、色々な物をいちからスクラッチして書くなんて有り得ないからね。ライブラリしかり、ソースだって自分の使いやすいように改造すれば誰かの書いた物を流用すればいい。妙なプライドと車輪の再発明を考えれば、それが愚かしい事ぐらい誰にでも分かるもんですよね。
こんどは、サンプルObjective-CのPDFビューアをSwiftで実装してみる。上手くいくかなぁ。そして、予定は未定。やるかどうかは分からないデス。
ここで
https://developer.apple.com/library/ios/navigation/#
PDFの表示の奴はこれしかなかったので、落として開いてみました。
https://developer.apple.com/library/ios/samplecode/ZoomingPDFViewer/Introduction/Intro.html#//apple_ref/doc/uid/DTS40010281
あ〜これはiOSのかもしれないけど、Objective-Cの物ですねぇ。まずはSwiftのソースを見た方が良いような気がするので、これは追い追い使う事にしましょう。
これが良さそうかなぁ。
https://developer.apple.com/library/ios/samplecode/UICatalog/Introduction/Intro.html#//apple_ref/doc/uid/DTS40007710
zipファイルの中に、Objective-CとSwiftのソースが入っていて、どちらも同じ挙動になっている模様。なので、今まで開発してきた人は、Obj-Cのソースを参照できるような感じになっているのだろう。Xcodeってプロジェクトを複数開けるんだったっけ？
とにかく、始めてのガッツリSwiftのソースに突っ込んでみたい。
このプロジェクト自体はサンプルもいいところで、メニューがたくさんあってそれを選んで見ていける。UICatalogという文字通りの、色々な表現の仕方のカタログみたいになっている。
対応するソースは始めに示されるページのメニューと、Swiftソースの名前が同じになっていてそのままで非常に分かりやすい。本当に初心者向けですね。このソースを選んで良かったなぁ。ただ、見た目は.xibファイルとか.nibファイルじゃなくて、ソースにベタ書きみたいです。まぁそっちの方が移植するのには楽だろうけど、にっくきAndroidに簡単に移植できるようにするはずもないわけで。
そういや、GUIをソースで書くのってJavaっぽいなぁ。というか、Visual StudioとXcodeの方が特殊なだけか。見た目はコーディングしなくて良いってのでVBとかはお気軽に使われるようになったわけだけど、なんつーかGUIの表現方法が一巡してきている気がしますね。HTML5とかでマークアップしてGUIの表現をするのもそうだけど、更にAjaxとDOMとかでGUIを動的に書き換えるってのも、Webアプリが増えた理由なのかなと思ったり。
トップページから分岐していくメニューの先は分かったんだけど、一番始めに示されるページはどこなのかな。Swiftソースだと思うんだけど、すぐに見つからない。あ、GUIをソースで書いてるんじゃないわｗ。てへっ
ええと、Main.storyboard ってのがGUIを表現していました。これがnibファイル系統の物と同じと考えていいのかなぁ。自分で作っていないから分からないけど。画面の遷移表も兼ねているみたいで、その挙動をSwiftのソースで紐付けて表現ってのはObj-Cと同じ事だと思う。ん〜妙にズームアップしているので、もう少し中身を小さくして俯瞰で見たい。
Visual Studioとかだと、GUIからウィザードにしたがって（ウィザードって言い方も古いので今はないのかも知れないが…）、ソースの雛形が形成されたけど、Xcodeとかは自分でやらなあかんかった気がする。少なくともつなぐoutletとかは先に書いておかないとダメだったんだっけ？
にしてもストーリーボードってのはもうちょっと表示を小さくできないかなぁ。おいらのMacbook Pro画面がそんなに大きくないので厳しい。これはThunderboltでマルチディスプレイにしろと言う事か。まぁ少なくともこういう物を書きながら作業するなら、一枚のディスプレイよりか複数あった方がいいに決まっている。Mini DisplayPortからHDMIかDVIに変換するのっていくらぐらいするんだっけ。どちらかに出来ればアダプタかませてつなげるんだけどな。あ、1000円位から買えるのね～。
買っちゃおうかなぁ。配送料無料だし。他のだと接触不良とか出てるんだよね。これも使ってるうちに出てくるんだろうけど、一応安すぎないところは買う。実際に買うかどうかは分からんけど。
う〜ん、色々な意味でなかなか過去のおぼろげな記憶が生かせてない。一番上から順にソースを見ていく。ActivityIndicatorViewController.swiftですが、ただ待ち状態のグルグル表示がふたつあるだけの物。
import UIKit
class ActivityIndicatorViewController: UITableViewController {
// MARK: Properties
@IBOutlet weak var grayStyleActivityIndicatorView: UIActivityIndicatorView!
@IBOutlet weak var tintedActivityIndicatorView: UIActivityIndicatorView!
// MARK: View Life Cycle
override func viewDidLoad() {
super.viewDidLoad()
configureGrayActivityIndicatorView()
configureTintedActivityIndicatorView()
// When activity is done, use UIActivityIndicatorView.stopAnimating().
}
// MARK: Configuration
func configureGrayActivityIndicatorView() {
grayStyleActivityIndicatorView.activityIndicatorViewStyle = .Gray
grayStyleActivityIndicatorView.startAnimating()
grayStyleActivityIndicatorView.hidesWhenStopped = true
}
func configureTintedActivityIndicatorView() {
tintedActivityIndicatorView.activityIndicatorViewStyle = .Gray
tintedActivityIndicatorView.color = UIColor.applicationPurpleColor()
tintedActivityIndicatorView.startAnimating()
}
}
そんなに長くないけど、予約語とかライブラリに関するオブジェクト名とかは全然分からん。
@IBOutlet weak var grayStyleActivityIndicatorView: UIActivityIndicatorView!
ってのは書いてある通りoutletなんだろうけど、weakって何だ？ 弱い？
それとクラス名に?を付けて、クラスインスタンスな変数を作るのは、The Swift Languageの始めで読んだんだけど、!を付けたのは見た事がない。んむ〜見てすぐに分からないノーテーションって困る。
「?」も「!」もOptionalsの関係だけど、Optionalsってのがnilの場合は、まともな値が入ってないよってことらしい。ただ宣言した時は中にnilを入れておいて、代入して初期化した後はnilじゃなくなるってだけなのかなぁ。でも、代入したオブジェクトの型を気にして不正な場合はnilにするとかはないのかな。所詮Objective-Cのラッパーだから、そこまでやってくれてそうもないけど、そこまで調べてない。
ええと「!」ね。宣言の時に!を後ろに付けておくと、代入して初期化してないのに使おうとするとランタイムエラーになるらしい。基本outletは動作してから値を突っ込まれるから、コーディング時には確定していないだろう。なのでコンパイル時にもチェックできないので、動作する時にチェックしましょうって話でしょう。runtime errorってのがどう発動するのかはよく分からないけど、変な値でたまたま動いちゃったりする事は無くなるわけだ。
あとは、weakですかね。これはObjective-Cのコードにもあった気がします。Obj-Cの本を読むとweakってのはARC用に取り入れられた物らしい。The Swift Languageにもやたらweak referenceとかいう言葉が出てくる。@propertyの値の設定方法のオプションですた。ってプロパティが何だとかから説明するのもなんだから飛ばすけど、Javaとかの他のOO言語を使っている人には同じもとの分かるはず。
結局、ARCってのがメモリの生成や削除に関する仕組みで、Obj-Cでメモリの扱いが面倒だから取り入れられたものです（ガベージコレクションは一度やったけどやめたっぽい）。weakってのは弱い参照をしているから、他のところで開放されても構わないってことだよね、retainじゃないって話だから。参照先で中身が開放されても、nilが入って処理される。そして、参照先のオブジェクトが自分のオブジェクトのretainで握っちゃってて、開放できないって事態も防げる。あるとかないとかは、その時によって柔軟に判断されるわけだ。ARC面倒だな。でもiOSだとオーベーヘッドが大きいからやめたんでしょ？ AndroidとかだとGC使えるから、そこのところはObj-CもSwiftも面倒なのは変わらない。
とりあえず、outletはweakで!なオブジェクトとして生成するって事は分かった。まぁそういうのはお作法的にマネするしかないんだけどね。ヘタにいじるとまともに動かないからさ。
overrideってのは元々ある継承した上のクラスの関数を再定義するのは、普通にOO言語的に考えると分かる。superってのは上のクラスの事で、それも同じだよね。
その後は、UIKitのクラスの問題だけかな。これは腰を据えてドキュメントを漁らないといけないだけなので、そんなに問題じゃない。気になるところをピンポイントで調べていけばいい。まぁ始めはほぼ全部ググることになるのだけれど、そのうち大体見当が付いてくるから始めだけ気にすればいい。
んで、気になるところなんだけど、.Grayってのは何なんだって話。
grayStyleActivityIndicatorView.activityIndicatorViewStyle = .Gray
こんな時は⌘＋クリックで宣言位置に飛べる。
enum UIActivityIndicatorViewStyle : Int {
case WhiteLarge
case White
case Gray
}
色を指定しているのは分かっていたけれども、記法としての= .Grayってのがよく分からん。これはenum独特の記法なのか。それとも型推論で重複する型は省略して書けるのであろうか。
http://codezine.jp/article/detail/7886
代入する時は、型推論で「型.メンバー」みたいな形を採らなくても「.メンバー」で済むらしい。いきなりこういう事されても御上品な書き方しかできない人にとっては正確にソースが読めないかも。まぁ慣れなんでしょうけど、書くのは楽でも読むのはちょっと気持ち悪い。a = a + 1をa += 1と書くような物と思えばおかしいとも思えないが、年取ると新しい物を受け入れるのが難しくなるもんだ。
あとは⌘＋クリックで各自のクラスの宣言を読んで、ソースが分かりにくかったらググってドキュメントを漁ってください。あぁ、これで何とかなりそう。開発するにもお金がかからず楽になったもんだね。まぁ稼ぐ気持ちがあったら本を買っちゃって読んだ方が速いんでしょうけど。日本人には英語が読めたとしても少なからずや負担だし、きちんと書かれている本さえあれば、それを買ってお金で解決するのも悪い選択肢ではない。
でも、趣味でやるくらいなら自力で一次情報を当たって、自力かググって解決するのが時間はかかるけど実力もつく良い方法だとは思う。今の時代で、色々な物をいちからスクラッチして書くなんて有り得ないからね。ライブラリしかり、ソースだって自分の使いやすいように改造すれば誰かの書いた物を流用すればいい。妙なプライドと車輪の再発明を考えれば、それが愚かしい事ぐらい誰にでも分かるもんですよね。
こんどは、サンプルObjective-CのPDFビューアをSwiftで実装してみる。上手くいくかなぁ。そして、予定は未定。やるかどうかは分からないデス。
タグ：SWIFT
コメント 0