Или под словом "определить" ты имел в виду "установить"?

Именно

бля...

ща, дай подумать

погоди. Правильно ли я понимаю: если ты тапаешь (селект?) вторую ячейку изначального тэйблвью, то ниже нее ты вставляешь 3 синих (бэкграунд) ячейки, а ... предположим если тапаешь 3-ю ячейку, то вставляешь ниже 2 зеленых? а ты не хочешь в зависимости от модели (кокой-то признак) бэкграунд твоего вью (ячейки)?

"устанавливать" - слово пропустил

короче, не вставляй ячейки, вставляй элементы массива в датасоурс, и прерисовывай вью

короче, не вставляй ячейки, вставляй элементы массива в датасоурс, и прерисовывай вью

хммм

Думаю да. Этот эффект называется - Accordion, или Accordion-menu, или Expandable|Collapsable ТэйблВью Ну понятно, да - растягиваем баян вниз. Вот пошаговый туториал: https://www.appcoda.com/expandable-table-view/

плист, дикшионари - это частность, это спин-офф туториала, суть, на которой ты должен сфокусироваться - на самом визуальном эффекте, и на изменении модели.

плист, дикшионари - это частность, это спин-офф туториала, суть, на которой ты должен сфокусироваться - на самом визуальном эффекте, и на изменении модели.

Биг спс))

бля, это что-то на уровне зелёного слоника, а может быть даже выше https://www.youtube.com/watch?v=3MyecXEKBlo

рим математика у него нравится

и математика зайчика

есть этот чат

слушайте ребят, вообще бекенд делать на один url это норм практика? И указывать в теле POST тип запрос (ну там registration, authorization)?

не, я к тому, что вообще все запросы писать на один url

и допустим данные о клиенте и информацию о заказе

это не называется рест

слушайте ребят, вообще бекенд делать на один url это норм практика? И указывать в теле POST тип запрос (ну там registration, authorization)?

да, по-всякому делают. ктото считает, что светить ендпоинты в урле это нехорошо

прост у меня бекендер сейчас пишет так, до этого в дргугой проекте писал как раз по REST

прост у меня бекендер сейчас пишет так, до этого в дргугой проекте писал как раз по REST

это тоже рест. рест это идеология, реализовать ее можно по-разному

я спрашиваю потому, что до этого я работал так, что url несет смысловую нагрузку и как раз таки все написано на REST, а сейчас в другом проекте чувак пишет все на один URL и что именно делает запрос определяется полем в теле (вмеcто application/json или application/text или еще чего-то - auth / reg / user) ну и тп И добно ли поддерживать такой код (другой человек поймет, че он там делал и нормально сможет продолжить), где все запросы на один url, может я чего-то не понимаю и это тоже какой-то стандарт...

хотелось бы услышать разные мнения на этот счет, потому что сейчас я на него нагнал и мб я реал чего-то не понимаю, у меня за плечами всего год swift разработки и пол-года я делал что-то через http

ну понятно, другой подход, но кроме того что "ты так раньше не делал" еще какието проблемы есть? удобство поддержания кода (клиентского ты имеешь ввиду?) зависит от тебя, ты же его пишешь? это не то что стандарт, это типа описание от IBM что такое REST API, там написано про GET/POST/DELETE/PUT но ему сто лет в обед. сейча я думаю это больше связано со стеком вашего бекенда, как там роутер работает итд.

так он на Свифте пишет этот бэкэенд?

неет

он пишет на php

так он на Свифте пишет этот бэкэенд?

ваще угар был бы

и на меня это не влияет, но я не хочу быдлокода с его стороны

а ты нас спрашиваешь будет ли удобно другому пхписту удобно поддерживать его легаси-код?

не, если сменится чувак и это окажется быдлокоом, то не хочется, чтобы этот новый чувак долго разбирался или все переписывал

вопрос это норм или не норм, вот и все

вопрос это норм или не норм, вот и все

это норм

ебота это

имхо, это не тот чат. Это тебе на форум по аниме. :)

как в swift можно писать все в контроллерах и там будет по несколько сотен кода

на одном ендпоинте держать всю логику

у меня тоже есть проект с бекендом на пхп, там тоже только пост

и работать с ней по ейлоаду жейсона

у меня тоже есть проект с бекендом на пхп, там тоже только пост

да я так понимаю, что у чувака только одна ручка - типа api.govno.com/application

куда спамятся жсоны с разными параметрами / хидерами

))

слушайте ребят, вообще бекенд делать на один url это норм практика? И указывать в теле POST тип запрос (ну там registration, authorization)?

За такое надо ссаными тряпками

куда спамятся жсоны с разными параметрами / хидерами

+

Но вообще зависит от задачи бэкэнда

ну то есть охуенно вообще

у тебя одна ручка бэкенда и авторизирует тебя, и объекты из базы удаляет

топ архтитектура

задача с идеями мы увеличим функционал, сейчас запросов 20 там будет точно

у тебя одна ручка бэкенда и авторизирует тебя, и объекты из базы удаляет

да, в пост дате 2 параметра: method и parameters, потом мультипарт может идти, но мультипарт лучше по ресту-же выносить в отдельные запросы

я боюсь короче предположить, че там за хуйня в пхп на бэкенде

задача с идеями мы увеличим функционал, сейчас запросов 20 там будет точно

20 запросов в одну ручку?

один контроллер наверное

Вы ебнитесь

Разбивайте

в нем пару десятков ифов

"нормас, все в одном месте зато"

спасибо большое за ответы!!

"нормас, все в одном месте зато"

Ага, в мэйн точка мэмэ

в нем пару десятков ифов

ты про хешмапы чтото слышал?

задача с идеями мы увеличим функционал, сейчас запросов 20 там будет точно

я же правильно понял то, о чем ты говоришь?

ты про хешмапы чтото слышал?

я слышал, пхпшник - врядли

я же правильно понял то, о чем ты говоришь?

да, все в одном месте

ебать

я слышал, пхпшник - врядли

а что свифт программист чемто отличается от пхпшника в лучшую сторону?

а что свифт программист чемто отличается от пхпшника в лучшую сторону?

тем, что слышал о хеш мапах

определяется по типу данных (вместо application/json - logout / user/ auth / order) ну и так далее

ШАХ И МАТ

определяется по типу данных (вместо application/json - logout / user/ auth / order) ну и так далее

Бля

Бля бля бля

Бля бля бля

определяется по типу данных (вместо application/json - logout / user/ auth / order) ну и так далее

это вот уже гон полный

Сук

Где окно

Я выйду

Без обид

Но тряпками

выходи конечно, какие обиды

Нассать на них не забудьте