Что делают эти команды в коде?

swift4

#1

Что делают эти две команды во вью дидлоуде? Ведь протоколы подписаны и реализованы, пикервью соединен с вьюконтроллером через аутлет, зачем еще что-то?


#2

под этими командами используются методы делегатов, и при определении класса ты наследуешь от UIPickerViewDelegate, DataSource, грубо говоря, с помощью этих команд, ты указываешь, для какого именно объекта будут предопределены методы)
Эт же основы)


#3

я прошел все основы, но ни разу такого не видел. И все равно непонятно, что я наследую - UIPickerViewDelegate and UIPickerViewDataSource? Но это же вроде как протоколы и они уже подписаны в определении класса?


#4

Ты их предопределяешь)
Ты не разу не работал UITableViewController? Там без делегатов никуда, в случаи когда ты создаешь viewController, а tableView аутлетом)


#5

В каком смысле я их предопределяю? Насколько известно из тех же основ, чтобы использовать протокол надо сделать две операции - подписаться на протокол (в определении класса) и реализовать методы/свойства протокола. В этом коде эти два условия соблюдены. Зачем тогда еще одна операция и что за она? Имеется в виду вот эта:

pickerView.dataSourse = self

Потом, насчет TableViewController и делегатов, есть опыт работы и с теми, и с другими. Но что значит “создаю ViewController”? Я же в данном конкретном случае использую готовый TableViewController с готовым TableView внутри него. Что ты имел в виду?


#6

Вобще-то требуется 3 действия.
2 - которые вы написали и 3-е действие, это указать, так сказать слушателя, класс для делегата.
Без указания ссылки на класс слушателя, первые 2 действия ничего не сделают.


#7

Можно наследоваться от ViewController, внутри создать объект UITableView, тогда вам будет просто жизненно необходимо указать tableView.dataSource = self
Если вы сразу наследуетесь от TableView, этого делать не нужно, либо наоборот будет необходимо указать tableView.dataSource = nil, если данные например идут с rx
Такая же логика для tableView.delegate = self для первого случая, иначе определение методов протокола ничего не даст)


#8

слушатель - это метод делегата, который будет реагировать на какое-то событие в основном объекте? И если это так, то нужно ли самому прописывать какое-то сообщение, или они там уже встроенные?

И еще, извиняюсь заранее если это будет глупый вопрос, но где об этой третьей операции можно более подробно посмотреть? В основах я ее не видел (или может пропустил), а если гуглить, то как называется эта тема?


#9

“Слушатель” это образно говоря. Тема “работа с делегатами”.
Указание ссылки на основной объект, который будет реагировать на методы делегата, можно так же устанавливать через IB.


#10

Давайте с вами вместе попробуем решить этот вопрос.
Я так понимаю, что с теорией про делегаты вы знакомы?
Тогда пройдём по вашим пунктам:

  1. Подписаться на протокол.
    У нас есть таблица, у неё для удобства ее использования есть два протокола.
    Для простоты понимания будем считать что один отвечает за ее содержимое - UITableViewDataSource, а второй за ее поведение - UITableViewDelegate.
    Вот вы подписались на протоколы
  2. Реализовать методы и свойства
    Так как xCode умный, он на эти подскажет какие методы нужно реализовать
    Это мы сделали.

Но вот тут и заключается вся суть. На данный момент к нас есть отдельная tableView, и допустим наш контроллер который реализовал два протокола.
И как tableView должна понять что ей нужно обратиться именно к нашему контроллеру для реализации функций из протокола?

Для этого внутри UITableView есть два свойства:
delegate : UITableViewDelegate?
dataSource: UITableViewDataSource?

И что нам с этим делать?
Нам нужно указать кто именно реализовал функции этих двух протоколов для нашей таблицы

И вот строчкой
tableView.delegate = self

Ми и говорим что для этой таблицы функции ее делегата реализовал этот self

Как-то так.


#11

Ок, спасибо, что помогаете разбираться. С вашего позволения задам пару уточняющих вопросов.

  1. Макет таблВьюКонтролера ведь уже связан с файлом кода ТаблВьюконтролер. Т.е. получается, что этого недостаточно и нужно устанавливать дополнительную связь, так?

  2. Как прочитать саму эту запись - pickerView.delegate = self
    Есть таблвьюКонтроллер, у него есть свойство pickerView, у этого свойства в свою очередь есть свойство delegat и этому свойству мы присваиваем self. Что в этом случае есть self? Т.е. получается, что свойству таблвьюконтролера присваивается сам таблвьюконтролер. Как это осмыслить?


#12

Если вы используете UITableViewController, то делегат и датасорс для его таблицы определены по умолчанию.

Запись может прочитать так:
Делегатом для пикерВью будет наш вьюКонтроллер. Так как self это именно он в вашем случае.


#13

но ведь pickerView есть свойство ViewController’а. А как возможно свойству объекта присвоить сам объект? Чисто логически это выглядит как-то нереально.


#14

Такие вопросы еще раз говорят о том, что вы не знаете основ.
Это прям самые первые темы, работа с переменными.


#15

self всегда имеется в виду сам файл вот этот ваш свифтовый. В данном случае этот контроллер ViewController. Контроллеры обычно чтобы какую-нибудь фигню контролировать. В автобусе они обилечивают. В Свифте контролируют всякую фигню типа что нарисовали в сториборде и просто в коде написали. Там у Вас на картинке во второй строчке Вы написали что ваш контроллер будет контролировать стандартные штуковины типа UIViewController, UIPickerViewDelegate, UIPickerViewDataSource… Вообще что угодно можно написать и добавить туда. Что угодно контролировать.

Погнали дальше. Там на картинке в 4 строчке pickerView … Это ссылка на picker View в сториборде. Это не свойство какое-то. Это picker View в сториборде.

когда вы пишите
pickerView.delegate = self

вы говорите у вашего pickerView что вы наваяли в сториборде делегатом будет self – то есть вот этот файл ViewController (во второй строчке на картинке). Ну. Тут бинго. Вы же написали в той же строчке что будет делегатом этот файл (в второй строчке UIPickerViewDelegate). UIPickerViewDelegate – это вообще делегат теоретический.
А вы, четко, как джентельмен, указали что он будет делегатом конкретно для pickerView из сториборда (в общем случае и необязательн сториборд):
pickerView.delegate = self

Кстати. Как пример из моей проги https://itunes.apple.com/ru/app/id1447889425
будете смеяться, но там всего один контроллер / Свифт файл и выглядит (по секрету) начало так:
class UniversalTableViewController: UITableViewController, UITabBarControllerDelegate,
UITextFieldDelegate, UIPopoverPresentationControllerDelegate {
то есть я написал что он будет эти фигни контролировать. ну там в коде потом есть конечно = self


#16

pickerView это ваш picker в сториборде. Вы их можете наваять хоть 10 и обозвать как хотите, типа pickerView1 или мамадорогая777. А вот чтобы указать какой Свифт файл (их может быть хоть 50) будет эти pickerы контролировать и нужно писать pickerView1.delegate = self
а мамадорогая777 быть может другой Свифт файл контролировать или этот.

тут проблема в чем. Чтобы ваш файл мог контролировать ваш pickerView из сториборда, чисто формально нужно в заголовке прописать слово UIPickerViewDelegate (Xcode тогда подтянет нужные ресурсы чтобы этот объект обрабатывать).


#17

тут можно как считать: когда вы написали UIPickerViewDelegate and UIPickerViewDataSource во второй строчке вашего кода, Вы попросту написали Xcodу подтянуть нужные библиотеки, которые вам понадобятся для контроля и обработки объекта UIPicker.

далее идёт конкретика, в четвертой строчке вы протянули из сториборда объект UIPicker и обозвали его словом pickerView.

Вот. Покамись ваш файл всё равно не знает что он какой вот конкретный UIPicker будет обрабатывать? Их по идее же много может быть? Тут я согласен, по контексту бы мог бы и догадаться. Ну по правилам, нужно конкретно указывать что к чему делегатом и источником,
поэтому и пишем:
pickerView.delegate = self (ваш ViewController - делегат, то есть обрабатывать всяческие события вашего pickerView)
pickerView.dataSourse = self (ваш ViewController - источник данных вашего pickerView).

вот. Вы правы тыр-пыр.delegate = self не всегда видно в каком-то конкретном файле. Например, в шаблоне Master - Detail команду
splitViewController.delegate = self
засунули вообще сразу в файл AppDelegate.

Вы правы. Не всегда пишутся эти " = self ", если не нужно контролировать или данные менять.


#18

я попрошу и вас разобраться в теме, а только потом подсказывать!


#19

Можно взглянуть на Ваши готовые приложения в App Store? :star_struck:

Автор темы задал вполне резонный вопрос, если вдуматься глубоко. Компилятор, если так в идеале смотреть, мог бы по контексту понимать, что нужно. :stuck_out_tongue:


#20

Дэн вам всё правильно и ёмко сказал ))

это не так ) UIPickerViewDelegate и UIPickerViewDataSource - это протоколы! И чтобы их поддержать, класс должен явно реализовать обязательные методы этих протоколов. В этих методах как раз обработка данных для реализации пикера.

self - это вроде как родительский класс, а не файл )