Swift part12

2018/10/29(月) 22:08:16.87

!extend::vvvvv

WWDC2014で発表されたAppleの新言語Swiftについて語りましょう

関連スレ

プログラミング言語Swift　Part4
http://egg.2ch.net/test/read.cgi/mac/1484763495/

[SDK]iPhoneアプリ開発初心者質問箱49[touch][iPad]
https://egg.5ch.net/test/read.cgi/mac/1538778915/

Xcode part14
http://egg.2ch.net/test/read.cgi/mac/1476190499/

Swiftアンチスレ part1
http://mevius.2ch.net/test/read.cgi/tech/1458491343/

前スレ
Swift part11
https://mevius.5ch.net/test/read.cgi/tech/1498640309/

スレ立て時は1行目に「!extend::vvvvv」

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2019/05/28(火) 21:03:01.13

>>126
ありがとうございます！
理解できました！

それってローカルスコープって言うものと関係があるのでしょうか？

ローカルスコープ内で宣言された定数がそのループ内で下まで行って、
それで宣言されたのは消えるけど、ブロックは残る。
でまたループの最初で新たに宣言されて、同じ名前のブロックだけど、1個目のブロックとは違う2個目のブロックが作られるってことですね！

ありがとうございます！

2019/05/28(火) 21:06:57.09

親切にありがとうございます。

プログラム面白いです！

2019/05/28(火) 21:26:26.57

>>127
スコープの話はその通り。
ブロックに関しては、その入れ物である定数が破棄された時点で同時に破棄されてる。
画面は書き換えられてないから、絵としては残ってるけど。

2019/05/28(火) 21:29:38.21

知識と実験結果が繋がるとワクワクするよね。

2019/05/28(火) 22:06:12.86

>>122のコードだと、スコープ内だから定数blockも、そこに格納されてるブロックも「そのまま」残ってる。
で、先ず一回めのplace()でブロックがcolumn 2, row2に置かれる。
そして、その同じブロックがまたplace()で使われて、同じ位置に置き直されてる。

だから一旦消える。

2019/05/29(水) 01:28:22.62

>>129
>>131
ありがとうございます！
このブロックが消える残るの違い、分かりそうな分かってなさそうなです...

じっくり考えます！

2019/06/04(火) 04:57:26.99

楽しみですね。来ましたね。

2019/06/05(水) 09:09:04.10

SwiftUIってどうなのよ

2019/06/05(水) 09:37:29.67

癖になっちゃうみたいよ

2019/06/05(水) 11:12:50.80

手持ちのiOS向けコードをmacOS向けにビルドしてみてる。
拍子抜けするほど簡単。
iOSはスレッドの選択に寛容なのだと分かった^_^
iOSで引っ掛からなかったミスをmacOS向けだとキッチリ指摘される。
お陰でiOS向けの動作も改善できた(^^;;

2019/06/05(水) 21:52:24.16

神だ！

https://www.hackingwithswift.com/quick-start/swiftui

92 (ﾜｯﾁｮｲ 5384-nFRp) · 2019/06/07(金) 13:11:36.86

わりと簡単な2画面使うアプリのソース無料でかどこかに落ちてないですかね。
一通り言語の勉強は終わったので、マニュアルの課題よりちょっと上の画像扱うアプリのソースとか見てみたい

2019/06/07(金) 13:26:18.96

>>138
チュートリアルとしてはこれとか。
https://www.hackingwithswift.com/100/16
サンプルソースコードへのリンクも記事の中に有るよ。
ただし、よくあるstoryboardのセグエを使うやり方じゃ無いけど。

92 (ﾜｯﾁｮｲ 5384-nFRp) · 2019/06/08(土) 10:12:49.60

>>139
Thanks 観てみるよ

2019/06/08(土) 13:59:27.79

SwiftUIはDateFormatterのロケールに未対応だね

2019/06/18(火) 02:19:23.63

すみません、教えてください。
今とあるWebサイトに載っている
プログラムの意味を一つずつ調べていまして、

let okHandler: () -> Void = { handler in
if let textField = alertController.textFields?.first {
completionHandler(textField.text)
} else {
completionHandler("")
}
}

の構文がどうなっているのか、全然分かりません。
{ handler in　・・・　からは、
引数も戻り値も無いクロージャーと思っていますが、
正しいでしょうか？
あと、
let okHandler: () -> Void = { handler in
って、
let okHandler = { handler in
ではだめでしょうか？

2019/06/18(火) 07:44:59.45

>>142
分解して理解する
let 変数名: 型 = 値

【型】
クロージャ型の場合さらに分解して
(引数型宣言) -> 戻り値型

「引数無し」は「空のタプルを1つ」と同等として扱われる
また、Void型は空のタプル型のエイリアス
Void = ()

以下は全て同じ型「() -> ()」になる
let okHandler: () -> Void = {}
let a: (Void) -> Void = okHandler
let b: () -> () = okHandler
let c: (()) -> (()) = okHandler
let d: ((())) -> ((())) = okHandler

【値】
クロージャの場合
{引数定義 in 本体}
今回の方の場合、handlerは空のタプル型の引数となる

クロージャ型を省略するとhandlerの型が不明になりコンパイル出来ない
handlerの型を明示するか「引数定義 in」を省略すれば可能
let okHandler = { (handler:Void) in }
let okHandler = { }

2019/06/18(火) 09:19:46.79

引数をとらないクロージャー() -> Voidとしているのに{ handler in ....}というは通らないのでは。
クロージャー内でもhandlerは使われていないし。

2019/06/18(火) 10:13:56.93

すまん、Swift4からは引数型宣言とタプル型の区別が厳密化した影響で通らなくなってるな
https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md

>>143を訂正
>「引数無し」は「空のタプルを1つ」と同等として扱われる
これはSwift3までで、Swift4以降は間違い

空のタプルを1つなら以下になる
let okHandler: (()) -> Void = { handler in }
let a: (Void) -> Void = okHandler
let b: (()) -> () = okHandler
let c: (()) -> (()) = okHandler
let d: ((())) -> ((())) = okHandler
let okHandler2 = { (handler:()) in }

引数無しなら引数は書けない
let okHandler3 = { }

さらにSwift4→Swift5でも型の文字列化が変更されているようで
print(type(of: { (handler:()) in } ))
が
　　Swift4では () -> ()
　　Swift5では (()) -> ()
と表示される

2019/06/18(火) 10:37:29.39

>{ handler in　・・・　からは、
>引数も戻り値も無いクロージャーと思っていますが、
>正しいでしょうか？

正しい。但し、クロージャー内の’handler in’は現在は通らない。

>let okHandler: () -> Void = { handler in
>って、
>let okHandler = { handler in
>ではだめでしょうか？

そもそも、
let okHandler: () -> Void = { handler in
では現在は通らない。

let okHandler: () -> Void = { () in
let okHandler: () -> Void = {
let okHandler = {
let okHandler = { () in
これらは通る。

という事ですね。

**デフォルトの名無しさん** (JP 0H7f-LWbF) · 2019/06/18(火) 18:47:59.54

>>142 です。
>>143、>>144
ありがとうございます！ほんと凄いです。
お伝えしていませんでしたが、swift3でした。
失礼しました。
油断したらまた何だったっけ？ってなりそうですが、
「タプル」「空のタプル」で検索したりして、
かなり分かりました。

let okHandler = {
でいいような・・・。

ところで、分かってきて、また疑問が湧いてきました。

// 引数と戻り値のないクロージャ
let closure = { () -> Void in print("クロージャテスト") }
closure()

let closure: () -> Void = { print("クロージャテスト") }
closure()

って、同じ意味だと思いますが、
なぜ、
let closure: () -> Void = { print("クロージャテスト") }
の形（今回質問させていただきましたクロージャー型={}の形）
なのか分かりますでしょうか？
好みの問題でしょうか？

let closure: () -> Void;
closure = { print("クロージャテスト") }
closure()
なら、なんとなく分かりますが。

2019/06/18(火) 19:12:11.36

変数、定数の宣言は、型が推定できるか、または明示されていることが絶対条件ですので、値を指定しない限り型を明示する必要があります。
ですので、基本的には

let 定数名: 型
var 変数名: 型

となる訳です。
この場合、値は後で代入する事になります。

定数名 = 値
変数名 = 値

この二段階を一度に行う事が可能で、

let 定数名: 型　= 値
var 変数名: 型 = 値

という書式になります。
この時、していされた「値」によって、定数（変数）の型を推定する事ができるので、型宣言を省略可能になります。

let 定数名 = 値
var 変数名: = 値

どの書き方をするかは基本的に自由です。
読み易さやメンテナンスのし易さ、その他の事情に応じて自分で判断します。

2019/06/18(火) 19:14:33.84

修正
誤）var 変数名: = 値
正）var 変数名 = 値

2019/06/18(火) 19:22:36.30

ざっくり書きますが、
クロージャー型宣言部分での引数、戻り値の記述、クロージャー（値）部分でのそれも、基本的には両方とも「書く」のです。

が、どちらかで書かれていれば他方は推定可能なので省略でき、更に両方で書かれていない場合は「引数も戻り値も無いのだな」と推定可能なので書式として通る

そんな感じです。

2019/06/18(火) 19:32:52.12

ちなみに

let 定数名: 型　= 値
var 変数名: 型 = 値

この書き方には、型を「確実に」指定出来るというメリットが有ります。

値が「1.0」である時、この値を割り当てられた変数の型は
float でしょうか、それともdouble でしょうか。
どの型であるかでプログラムに不都合が起きる場合、推定に任せるわけにはいきません。
この様な場合には上記の型を明示する書式が採用されます。

2019/06/18(火) 20:04:30.62

>>147
戻り値まで指定しているその２例だと好みの問題かな

戻り値を指定しない場合は
最後のステートメント次第で型が変わる可能性がある

func print2(_ s:String) -> Int {
print(s)
return 10
}
let closure1:() -> Void = { print2("クロージャテスト") }
let closure2 = { print2("クロージャテスト") }

closure1は () -> Void
closure2は () -> Int

---

個人的にはトレーリングクロージャで使えるクロージャ側で指定する方が好み
func arr2<T>(_ f:()->T) -> [T] { return [f(),f()] }
let a = arr2 { () -> UInt8 in 10*2 }
print(type(of: a ), a) // Array<UInt8> [20, 20]

2019/06/19(水) 01:46:47.34

>>147 です。
>>151、>>152
ありがとうございました！
正直、大変失礼ながら、
こんなにちゃんと教えていただけるとは思っていなかったです。
大変感謝しております。

なるほど、なるほどの連続で、
「個人的にはトレーリングクロージャで使えるクロージャ側で指定する方が好み」
のところが全然分かりませんでしたが。w

また進化して戻ってきます！

2019/06/19(水) 18:16:34.43

Swift Playgroundsどぅょ

**デフォルトの名無しさん** (JP 0H8d-F2Fz) · 2019/06/20(木) 10:32:09.63

Swiftを始めてみたいんだけどMacが必要らしくてMac miniかMacbookを買おうと思ってる（高い）
こどおじだからMac miniでいいかな？

実際に開発してる者の意見を聞きたい（開発上の利便性とか速度とか）

2019/06/20(木) 10:49:25.55

プロジェクトの規模による。
始めてみる程度ならMacBook Airでも問題無い。
サブディスプレイの有無で作業効率がかなり違うので、出来れば用意したほうが良いと思う。
実機テストにも使えるし、サブディスプレイにもなるのでiPadはお勧め。
iPadは、サブディスプレイ接続しなくても資料の表示にはかなり役立つ。
MacとiPadは相互にコピペ出来るし、その他の連携も良い。

**デフォルトの名無しさん** (JP 0H8d-F2Fz) · 2019/06/20(木) 11:49:37.55

>>156
ありがとう！

2019/06/20(木) 16:23:44.57

プログラミングの学習を始める時は機材もそうだけど教材も重要。
実際に打ち込んで結果を確認しての繰り返しなんで、「次に何をやるか」のネタが尽きない事が大事。
英語にアレルギーが無ければ、↓のサイトがお勧め。
https://www.hackingwithswift.com/100/

Swiftの基礎から、そこそこ自分で組める見通しが立つ程度まで100日間のコースが組まれてる。
最新の環境に更新されているし、ソースコードを含めて全て無料。
100日間、ネタが尽きない。

2019/06/20(木) 20:21:20.75

>>158
面白そうだけど、英語が苦手で・・・

日本語でおススメサイトないですか？

2019/06/20(木) 20:39:38.74

日本語だと、なるべく新しい本を買うのがお勧めかな...
ネットの情報は新旧錯綜してるし、当のAppleも日本語のガイドや入門コースは更新が送れてる(^^;;
Appleの入門コース、内容は凄く良いんだけどね。無料だし。

2019/06/20(木) 20:42:51.91

Xcode10、Swift4以上で。

2019/06/20(木) 21:42:28.43

>>159
読めないにしても
YouTubeの設定の字幕表示＋自動翻訳（英語→日本語）と
ブラウザでのページ翻訳くらいは使えるようになった方が良いと思うよ

2019/06/20(木) 21:48:41.43

技術系の本は出てくる用語が限られてるし、下手くそな文章は別にして、大抵よく整ってるから意外と読めちゃうよね。

2019/06/20(木) 21:57:05.54

英語できないとかプログラムこの先やっていく上で致命的すぎるだろ

2019/06/20(木) 22:08:45.14

まあ、まずは取っ掛かる事だわな。
続けてりゃ、後から色々ついてくるもんだし。

2019/06/20(木) 22:41:08.00

ある程度知ってるものについて英語の文献を読むのならまだしも、知らないものについてゼロから学習するのは辛いものがあるからな

2019/06/21(金) 11:59:27.29

>>154
クソおもろいで！

2019/06/21(金) 19:19:55.86

>>164
>>166 今はオンライン辞書や翻訳もあるから、それほど恐れることはないとも言えるが、
少なくとも中学英語の副読本の物語をすらすら読める程度じゃないと辛いだろうな、

2019/06/21(金) 19:30:28.62

macOSやiOSには辞書が標準でインストールされてるし、わからない単語はその場で確認出来るしね。
全くの初学なら基本的な型や制御文、UI部品の幾つかについては日本語のテキストで学んで用語をある程度頭に入れたら、英語のテキストに取り組むと良いかもね。

いかんせん、日本語の書籍のサンプルコードは断片的でつまらないし、応用も効きにくいんだよなぁ...

ほんと、Appleの入門コース日本語版は早くアップデートすべきだと思うよ。

2019/06/22(土) 21:25:36.03

iOSアプリのMacへの移植､アップル重役が大幅改善を予告
やはり人間がデザインを調整する必要あり
https://japanese.engadget.com/2019/06/20/ios-mac/

2019/06/22(土) 21:31:00.60

そりゃそうだろ。

2019/06/22(土) 22:01:15.23

とりあえず「わかっている」ようなので安心したw

2019/06/22(土) 22:19:44.53

「iOSアプリをmacOSで使える様になる」「統合される」なんて言う連中が未だに居るからね。
「iPadでmacOSアプリ使える様にしろ」とかさ。
あり得ないっつーの。

2019/06/22(土) 23:04:03.22

>>173
Windowsで出来ているんだから、Appleでもできるだろ。

2019/06/22(土) 23:06:31.47

>>174
あれはやらかしちまったって言うんだよ。

2019/06/23(日) 02:32:49.79

Macアプリ開発への呼び水だろうな。簡単にMacアプリ作れるじゃんと思わせといてちゃんとしたアプリを作ろうと思うとどっぷりAppKitに浸かっていく流れ。

2019/06/23(日) 08:59:37.11

だってMacアプリ少なすぎて
おまえらがiOSアプリしか作らないのがあかん

2019/06/23(日) 09:34:34.59

少なすぎるって事は無いだろ。
catalystの狙いはmacOSアプリを増やすというより、両環境向けのアプリを増やす事で連携を高める事だろ。

2019/06/23(日) 10:40:39.16

だってmacOSよりiOS乗ってる機械の方が圧倒的に多いしな

2019/06/23(日) 11:57:38.42

iOS機器はネット端末のイメージが強いから、アプリもネットサービスを利用する感覚でダウンロードされやすい。
開発者にとってはそこが魅力。

2019/06/23(日) 18:27:39.50

概念としては何度も提唱されていたMVC(モデル-ビュー-コントロール)って
プログラム実体とUIと接続部に最初から分けて実装すれば変更と移植が楽になる。
ってのを実際にやったのがジョブズが90年代にやってたNeXTで
MacOSXはそれをAppleに持って来たもの。

で、システム、アプリの基本的なつくりがそうなっているので
モバイル用にモジュール入れ替えてUIをモバイル用にした
『MacOSXの別バージョンがiOS』(だったりtvOSだったりetc)

だからプログラム実体とUIとコントロールは独立しているはずなので
「その機種用のUIに置き換えれば楽に移植できるし、システム的にそういうつくりのはずだよね？」ってのが基本。
前提が「(従来は全書き換え作り直しだけど)」って前書き入り。

Appleの前提は「違う環境じゃ違うUIや構成になるから変えなきゃね」で基礎システムできた上の主張やビジョンだけど
MSのWindows10はなんかそのあたり理解しないで「(うちは基礎システム環境ごとに全書き換えだから)全ての環境で同じものが動くようにします！」だから
さすがにありゃ「バカじゃねぇの？」としか…

2019/06/23(日) 18:52:14.66

つうか、色々なサイズ重量の機種に載せるOSにデスクトップ用とタブレット用とを抱き合わせ、しかもタブレット環境の筈なのにデスクトップUIのアプリ走らせ...
支離滅裂でしょ。
当然、持ち運び不能な機種で余計なタブレットモードは有るわ、タブレットモードとは別枠で複数のUIは有るわ、タブレットでマウス必須のアプリが走るわ
当然、タブレットに最適化したアプリは増えんわ
デスクトップ用のアプリは変な風にタブレットの影響受けるわ（ここはAppleもやらかしとる）

んで、OSがそんなワケワカメなもんだから、虻蜂取らずな2in1なんてハードは出てくる（まあ、出さざるを得ないわな）わ...

ソフト屋の筈なのに、UIの作り込みやUXガン無視ってなんなん？

お陰でiPadをPCと混同する様な要望やら、OSを統合しろやら、ユーザーの要望を聞かないのは横暴だの、とんだとばっちりを食わされてる訳で。

大丈夫だとは思いつつ、いつかAppleがポリシーを曲げやしないかとハラハラするこの数年だわ。

2019/06/23(日) 21:05:04.97

ブログにでも書いてろよ

2019/06/23(日) 21:19:13.22

俺Appleはハード屋だと思ってた。

2019/06/23(日) 21:22:04.14

ハード屋の方がソフトウェアの事が解ってる、またはソフト作りにポリシー持って仕事してるという皮肉

**181** (ｻｻｸｯﾃﾛﾙ Sp8d-LuMA) · 2019/06/23(日) 21:24:41.48

俺が>>181だが同じような長文投下した>>182は俺の話引き継いで
マイクロソフトとWindows10の話をしてるんだと思うぞw

2019/06/23(日) 21:38:57.96

>>186
よく読んだらその通りだったわ

2019/06/23(日) 21:45:36.40

ゴメンわかりづらくて。

しかも、主に言いたかったのは最後の二文だったりするし。

2019/06/23(日) 23:25:31.97

>>181
> 概念としては何度も提唱されていたMVC(モデル-ビュー-コントロール)って
> プログラム実体とUIと接続部に最初から分けて実装すれば変更と移植が楽になる。
> ってのを実際にやったのがジョブズが90年代にやってたNeXTで

細かいことですが、MVCのCは「コントロール」ではなく「コントローラー」です^^;

あと、MVCは概念だけでなくNeXTよりずっと以前、1970年代終わり頃のSmalltalkで既に実装が試されています。
つまり、アラン・ケイたちが1970年代を通じて開発したダイナブックの暫定OSですね。
念のため、ケイたちのSmalltalkは暫定ダイナブックのOSとしては販売されませんでしたが
開発環境の「Smalltalk-80」としてLisaや旧Macより前に製品化されそこに古典的MVCも組み込まれています。

▼ジョブズが観た当時のアラン・ケイたちの暫定ダイナブックOS（Smalltalk-76）
https://commons.wikimedia.org/wiki/File:Smalltalk-76.blowup.png

ちなみにこのSmalltalk環境のGUIを1979年に観たジョブズがGUIという表層だけ真似てLisa/旧Macを作り
その後Appleを追い出されてから、ネットワークとOOPを追加して改めて真似て作ったのがNeXTです。

▼PARC訪問とNeXTの成り立ちに関連するジョブズの証言
https://vimeo.com/31813340#t=55m (55分あたりから)

▼↑の部分を書き起こしたもの
http://web.archive.org/web/20121016134054/http://americanhistory.si.edu/collections/comphist/sj1.html#soft

2019/06/23(日) 23:37:06.45

Swiftのスレなんだが
土日のレスがまとめてスレチにしか見えん

2019/06/24(月) 06:40:57.89

プログラマーとしてのポリシーに関わる問題だから、あながちスレチとも言えない。

2019/06/24(月) 20:04:23.71

読み物として面白いから良いよ、過疎ってるし

2019/07/04(木) 19:09:00.78

プロトコル指向を理解しとる？

2019/07/14(日) 19:54:56.64

混乱しています。教えて下さい。

UnsafeMutableRawPointerに対してmemcpy上書きした場合に
copyonwriteされないという理解で良いでしょうか。

あちこちググりまくりましたが、SwiftにおけるunmanagedとUnsafeの使い分けが理解できていません。

2019/07/16(火) 11:55:20.33

>>194
Unmanagedの先はAnyObject (型情報や参照カウンタ等を持っている)
UnsafePointerはただのポインタ値でその先が何かを関知しない

もちろんmemcpyにCopyOnWriteなんて処理は入っていない

SwiftのArrayやDictionaryがCopyOnWriteするのは
各メソッドがそうするように実装されてるから

2019/07/16(火) 14:56:47.81

コメントありがとうございます。
UnmanagedはあくまでAnyObjectを指すという考え方がわかりやすいです。
ポインタ操作ではCopyOnWriteされないのでホッとしました。

2019/08/10(土) 04:08:33.39

ぐわしっ

2019/09/09(月) 23:33:17.83

Swiftと言うかxcodeなんですが、どなたかお解りになる方はお教え下さい。
複数の画面を移動して、ほぼ同じ処理、音を出すアプリを作っています。

画面Aはボタンから
@IBAction func HameMinor(_ sender: Any) {
let soundUrl = Bundle.main.url(forResource: "HameMinor", withExtension: "mp3")
var soundId: SystemSoundID = 0
AudioServicesCreateSystemSoundID(soundUrl! as CFURL, &soundId)
AudioServicesPlaySystemSoundWithCompletion(soundId) {
}
}

で音は出ますが、画面Bも同じく
@IBAction func HameHarm(_ sender: Any) {
let soundUrl = Bundle.main.url(forResource: "HameHarm", withExtension: "mp3")
var soundId: SystemSoundID = 0
AudioServicesCreateSystemSoundID(soundUrl! as CFURL, &soundId)
AudioServicesPlaySystemSoundWithCompletion(soundId) {
}
}

としても音が鳴りません。どうしたら良いでしょうか？

2019/09/09(月) 23:59:20.45

HameHarm.mp3に問題が有るか、ここに挙げてある以外のコードに問題が有るかのどちらか

2019/09/10(火) 00:18:37.62

>>199
ありがとうございます。
他にも沢山のmp3ファイルがあって、複数試しているのですが、別画面だけダメなんです。
何か別画面への定義とかあるんでしょうかね…?

2019/09/10(火) 00:33:32.10

同一のコードだけを並べて見せられても前記の答えしか出てこないよ。
同じものは何度見直しても同じだし、検証して確かに問題無いと言える筈の箇所は幾ら疑っても問題解決には繋がらない。
他の部分、他の理由に当たるべき。

2019/09/10(火) 01:05:05.33

>>201
ありがとうございます。
そうですよね、「定義が無い」エラーを消して動かして原因を探っていましたが、判りません。
ググってもそれらしいのは出てきません。頑張って探してみます。
画面移行のボタンは正常に動くのになんでだろ…

2019/09/10(火) 01:25:07.10

>>202
soundUrlを検証
おそらくおかしな値になってると思う

2019/09/10(火) 01:32:16.65

storyboardとibactionが連結されてないだけじゃね？

2019/09/10(火) 01:40:19.72

>>203
Bundle.main.urlの部分でしょうか？　コピペで音源名だけ変えました。

>>204
あ、それどうやってやりますか？　定義や連結だと薄々思っています。

いずれ、ありがとうございます。希望が持てます！

2019/09/10(火) 05:57:50.68

copy phaseに含まれいないとか。

2019/09/10(火) 08:01:00.36

>>202
何が定義されてないというエラー？
そのエラーメッセージを先ずはきちんと読んで。

2019/09/10(火) 08:58:17.45

>>204
俺もこれだと思う

2019/09/10(火) 09:55:21.91

pageviewcontroller でpagecurlにすると意図したように動くのにscrollにすると意図したように動かないなんで

**198** (ﾜｯﾁｮｲ dd5f-GOrT) · 2019/09/10(火) 14:49:57.08

多分原因と思われるところに行き着きました。
ボタンをコードに紐付ける時に、Nameとか入力するダイアログが出ます。
その「Object」欄がメインページからだと「View Controller」がデフォなのに、
別ページのボタンからでは「Exit」固定なんですよ。
Connections Inspectorでも確認できます。
コレを「View Controller」にするにはどうした良いのでしょうか？

**198** (ﾜｯﾁｮｲ dd5f-GOrT) · 2019/09/10(火) 15:45:48.46

自己解決しました。正に連結の問題でした。
お考え下さった皆さん、そしてアドバイスを下さった方々に感謝します。
ありがとうございました m(_ _)m

2019/09/12(木) 20:08:05.70

swiftは使いやすくなってるんだろうなぁと思って触り始めたんだけど
objCを資産として残したせいでむしろ闇鍋糞言語化してない？

2019/09/12(木) 20:48:17.13

Kotlin もよろしく

2019/09/14(土) 18:30:00.50

SwiftもコトリンもReact Nativeに負けたよ

2019/09/16(月) 02:30:28.49

xcodeスレも欲しいのはボクだけかな？

2019/09/16(月) 04:42:23.58

>>215
Xcode part15
http://egg.5ch.net/test/read.cgi/mac/1552999170/

2019/09/16(月) 23:49:16.34

>>216
あぁ、スミマセン、何処見てたんだろ？（汗

2019/09/17(火) 00:05:20.64

>>217
いえいえ。お互い様です。

2019/09/18(水) 15:10:02.78

>>212
今のSwiftでObjCに足引っ張られてる所ってどこだよ

2019/09/18(水) 20:02:00.88

>>219
objCに何かしら不満点があったから新言語導入したはずなのに
objCの方言みたいなスタートしたせいで仕様がコロコロ変わりすぎ
同じようなクラスが乱立するしネットは使えなくなってる文献の山で汚染されるしAppleが自分で作ったサンプルさえ放置されてたりするし
ちょっとした調べものが大冒険になる

2019/09/18(水) 20:09:03.96

>>220
ネットに最新の答えがないケースが多いよな
時間かけて答え探して結局力ずくで自己解決するしかないという

2019/09/18(水) 21:00:10.55

そんな状況なのか、増税前だけどmac買うの控えるわ

2019/09/18(水) 21:15:08.02

>>222
ボロクソ言ったけど極めてしまえば悪い言語ではないんだろうなと思うよ
学ぶための道筋がグチャグチャすぎて片手間でちょっとやるわだと苦行すぎるだけで

2019/09/18(水) 21:45:33.57

>>223
androidばかり触ってるからswiftもやろうかなぁと
swiftは全く勉強してないから、半年程度はもがく覚悟はあるんだけどねw

2019/09/18(水) 22:50:45.65

常にほぼ最新の環境。しかも無料で学べる。
お勧め。

https://www.hackingwithswift.com/100

2019/09/19(木) 00:07:22.90

「無駄にたくさんゲーム作って生きる」 “RucKyGAMES” という生き方 10の新機軸
http://www.ttcbn.net/no_second_life/archives/21048
国連から表彰されても引退なの？個人アプリ開発の世界は残酷だ。
-リオ・リーバスさんインタビュー
http://appmarketinglabo.net/leorivas-interview/
「約3年で1,180万円を稼いだ、いま広告収入は月100万くらい」地味だけど寿命は長い
「電卓アプリ」実際に効果があった5つの施策。
http://appmarketinglabo.net/calculator-1100man/
「アプリを月16本ペースで年間200本つくった」Goodiaが
2014年を振り返り「初月売上が高かったゲームアプリ」のベスト3を語る。
https://appmarketinglabo.net/goodia2014/
アプリ開発者がビジネスで成果を得るためのガイドライン
https://www.atmarkit.co.jp/ait/articles/1403/20/news035.html
個人アプリ開発で一文無しから1000万円稼げるようになった成功事例
https://growthhackjournal.com/how-tasnim-ahmed-went-from-jobless-to-making-100k-with-apps/
成功したいなら、アプリ開発者は企業向けアプリを開発すべき
http://readwrite.jp/archives/3618
「アプリは何がヒットするかわからない、とにかく出す」メタップスCEO佐藤さんが語る世界で成功するアプリ。
http://appmarketinglabo.net/metaps-appmarket/
「アプリを月16本ペースで年間200本つくった」Goodiaが
2014年を振り返り「初月売上が高かったゲームアプリ」のベスト3を語る。
https://appmarketinglabo.net/goodia2014/