@JRazor Пишу скрипты на питоне, думаю swift вам должен понравиться, но O-C все равно лучше выучить. Лично мне нравится открытость Андроида, но по собственным ощущениям больше удовольствия получаю от разработки под iOS. Но зато на Андроиде можно написать приложение и немедленно раздать друзьям/коллегам. Если есть возможность, я бы прошел по одному интенсивному курсу под каждую платформу, чтобы понять, что больше нравится.
@Marktven я написал про удаление самого vk как раз к тому, что тут не поймешь. Сегодня никаких проблем, а завтра приложение выпиливают.
Свой ответ я написал не зная про то, какое у вас приложение конкретно. Если яблоку не нравится просто прослушивание песен, то тут неясно как с этим справиться.
@andreys75 ну конечно, если название класса заканчивается названием класса из стандартной библиотеки, то обычно от вас жду наследника этого класса. UITableView в данном случае
@andreys75 1. Не нарушайте naming convention тогда :) Нет, не дергает, тогда тоже самое, только без делегатных методов, вью контроллера и прочего.
2. Не очень страшно, лучше только сделать ссылки слабыми, иначе элементы массива будут жить, пока живут view карт
@andreys75 да, VC знает о tableView при помощи аутлета, при этом, назначаем его делегатом, пишем внутри VC: `tableView.delegate = self и tableView.dataSource = self `. Теперь, когда tableView решит отрендерить ячейки, он дернет делегатный метод создания ячеек(tableView:cellForRowAtIndexPath:), там мы создадим ячейку и положим туда картинку, к картинке добавим обработчик касания, таргетом назначим self, т.е. наш VC. Там надо бы еще проставить тэги(imageView.tag), чтобы понять по какой картинке кликнули. Причем это все происходит в нашем VC и нигде больше.
tableView неплохой вариант, зависит от того, что хотите реализовать. Еще можно посмотреть в сторону UICollectionView, на мой взгляд, он ближе к тому, что хотите реализовать, но с ним будут отдельные проблемы.
@njc Не могу назвать себя про в мультитрединге, в пункте 5 не нравится именно то, что находимся в потоке, где по идее крутятся таски нашей сессии и вызвав делегатный метод класса API, а следом и обработку - мы все это отправим туда же, что вообще говоря может ничем не грозить, а может и грозить. Я бы предпочел выбраться из того потока и хотя бы начать в главном потоке всю логику в классе API. Отдельным моментом скажу, что парсить в главном потоке уж точно не стоит, потому придется все дорогое выкидывать в дургие потоки уже в API.
Честно говоря, я не до конца понимаю, на каком уровне подробности надо объяснять, и с чем вы уже познакомились, потому напишу максимально подробно.
В пункте 5 я по сути описал один из шагов реализации кастомного делегата. Про пункт 5 я специально написал, что надо будет прочесть про патерн делегат в iOS: куча туториалов по запросу "how to create custom delegate in ios" в гугле. Это один из основных патернов, его лучше понимать. В Objective-C интерфейс называется протоколом, это список методов. Есть VC, он реализует некий интерфейс. В частности там будет метод, который будет вызываться, когда таск будет заканчиваться. VC назначаем делегатом тому, кто будет обрабатывать эти запросы. Собственно тот, кто создал таск, узнает о том, что таск закончился в completion блоке, после чего вызовет метод окончания таска у своего делегата(VC в нашем случае). Я вроде расписал, но лучше туториалы посмотреть, чтобы было поянтнее. Но судя по тому, как вы расписали - вы это понимаете :)
Теперь про саму архитектуру.
Так, я себе представлял, что класс API просто генерит урлы и ничего более, и связка только между VC и handler. Как вы расписали - тоже хорошо. Одно но, в вашем п.5, если поставить брейкпоинт в completion блок, то мы увидим, что находимся в потоке, который связан в очередью тасков сессии(это по идее значит что обработка ответа, парсинг и пр. полетит в тот же поток, но лучше проверить), как оттуда выбраться: stackoverflow.com/questions/5662360/gcd-to-perform...
Да, потому что это блок, блоки - это замыкания в Objective-C.
Я два раза переписал ответ и лучше теперь понял вопрос :)
Предлагаю такую связку: ViewController(vc) <-> THETALEHttpHandler(handler) все работает на патерне делегат(придется написать protocol для этого)
1. VС создает handler и назначает его делегатом себя. Во время создания отдаем туда все куки, все параметры сессии и прочее.
2. Handler создает сессию в отдельном методе - она одна ведь, а тасков будет много, там юзаем все параметры.
3. VC вызывает метод handler'a для запроса(в первый раз в качестве урла подставляем урл для логина), а другие параметры нам больше не нужны, они лежат в сессии. Сессия создает в этом методе таск и начинаем выполнять.
4. Попали в completion-блок c тем или иным результатом, надо сообщить об этом VC.
5. Вызываем делегатный метод handler'а у VC в главном потоке, в параметрах отдали данные и надо бы урл, по которому стучались.(Тут лучше прочесть один из небольших мануальчиков по тому, как сделать кастомного делегата и свой протокол)
6. В делегатном методе разделяем все по запросам. выделили там логин, выполняем всю логику, VC отдает следующий запрос handler'у, внутри handler'а создаем новый таск, выполняем, результат отправляем в VC через делегатный метод и т.д.
Да, вы мне ответили, ответ меня не очень устроил, чтобы не разводить дискуссию в комментарии, решил создать новый вопрос.
Работаю с мобильными приложениями, не знаю отличается ли ГА для них и для сайтов, но вот конкретно повторил трюк со сдвигом влево, заходим в Behaivor - Events - Top Events. Там адское кол-во эвентов(оно и понятно, там число надо делить на кол-во свойств, которые при нашем трюке являются самими эвентами). Надо сказать, что при старте приложения я логирую большое кол-во параметров, из-за чего "категория" AppStart забивает другие категории и занимает 86% всех эвентов. Вроде понятно как смазывается вся картина. Аналогичное можем наблюдать в Behaivor - Events - Screens, смотрим конкретный экран, а там опять все числа в несколько раз больше реальных. В итоге везде где бы мы не считали кол-во эвентов мы будем получать нужное число * кол-во параметров этого эвента, и все это из-за этого сдвига.
Понятно, что если мы хотим просто посчитать кол-во нажатий на кнопочку, то все хорошо, если хочется посчитать время - тоже, но в момент, когда мы хотим залогировать текстовый параметр, набор возможных значений которого конечен, но достаточно велик, то непонятно что делать.
Чтобы пример был понятен и про сайт, представим, что у нас есть сайт, например ya.ru/, но где можно выбирать только из вариантов, которые подсказывают. В момент, когда пользователь выбирает подсказку, мы хотим залогировать это в ГА.
Прошу прощения, что опять так объемно, но надеюсь, что в этот раз написал менее скомкано и более понятно.
Ну тут зависит от того как удобней получать информацию. Я бы советовал книжки, можно взять более фундаментальную, а можно cookbook - там на пальцах расскажут "как сделать вот так вот". Минус вторых - можно забить прорабатывать, а просто начать клепать "по аналогии", из этого ничего хорошего не выйдет и без понимания рано или поздно начнутся большие проблемы.
@morozovdenis Идеологически как раз не слишком, уведомление нужно для того, чтобы сообщить всему приложению о чем-то глобальном. С расширяемостью согласен, но тут как раз в том и суть, что компоненты логически связаны между собой. Единственная причина, почему тут еще можно поспорить это то, что нам надо дернуть только 1 метод. Если бы нам надо было сообщать о большем кол-ве событий на крайне правом контроллере, то уведомления превратились бы в жуткого монстра.
А вообще чувствую, что тут просто нужен класс-синглтон, который будет работать с объектами, которые мы добавляем. У которого наверняка можно будет получить все данные для вьюхи с лэйблом.
@Extremesarova так надо кастовать в класс, у которого есть это поле. Откуда оно вообще появилось? А так мы уже слишком сильно отдалились от начального вопроса. Без кода непонятно что там происходит.
