но я сейчас про такую форму обертки

через синглтон

когда это плохо и почему?

иногда там {"result": ... , "response": ...} а иногда {"result": ... , "balance": ...} ?

иногда там {"result": ... , "response": ...} а иногда {"result": ... , "balance": ...} ?

ага) говорю же на сервере туфту отдают) клюю переодически, как поменяют удалю этот чек

должно быть кругом result... {response

и будет без response balance :)

гы) нашел баг) пок апереписывал как должно быть

я пока не вижу - где там синглтон?

PApiClientGeneral – синглтон?

да не, не должен быть

там инициализватор с url же

ой

вот, генерал то просто родительский

papi client =)

:)

но ок, допустим

ты его сделал, он работает

вероятно умеет авторизоваться в API и хранить сессию / токен

а теперь прикинь, ты решил что в твоём приложении клиент должен уметь разлогиниться

и залогиниться под другим акком

нет токенов)

но да, такое в других проектах делал

вот тут ты попадаешь - придётся писать код, который твой неубиваемый синглтон будет чистить от стейта

или убивать

в статье https://www.objc.io/issues/13-architecture/singletons/

именно такой случай и описан

нуу, почему? я в классе, который делает логаут

чищу

а не в синглоте

от синглтона я ток получаю: успешно разлогинился или нет

а мог бы не чистить

это лишний код

лишний код - источник лишних багов

а как?

А еще можешь сказать, что лежит в POST:parameters:progress:success:failure:

сессию же нужно удалить

статья, почитай её

А еще можешь сказать, что лежит в POST:parameters:progress:success:failure:

я этот не юзаю)

как в хттп хидеры положить что нибудь?

хз) гуглить надо)

Вот основная пост функция, которая делает запрос от всех методов

а это тогда что?

о, он спрогрессом, фтыкнул

POST:parameters:progress:success:failure: разве нет?

это метот либы

POST:parameters:progress:success:failure: разве нет?

[manager.requestSerializer setValue: self.LOL forHTTPHeaderField: @"myHeader"];

и там дальше 100500 таких коротких вызовов методов

ок. как закешировать результат запроса?

[manager.requestSerializer setCachePolicy:NSURLRequestReloadIgnoringLocalCacheData];

[manager.requestSerializer setValue: self.LOL forHTTPHeaderField: @"myHeader"];

йо, это что, глобально?

при инициализации)

а ретраев там нет принципиально?

или как там рейт-лимитинг встраивать?

походу тут все ставится

синглтон - это, AFHTTPSessionManager

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

я так понял?)

потому что они задаются при создании

хотя не)

при создании ток URL

все остальное мона менять

[manager.requestSerializer setCachePolicy:NSURLRequestReloadIgnoringLocalCacheData];

а если нужно кешировать только картинки?

SDWebImage это делает по умолчанию. Это если не хочешь сам писать

секундочку. при чем здесь SDWebImage?

для меня там проблема в том, что выкорчёвывать эту штуку из проекта будет долго и больно при надобности, замокать её толком не получится для тестов, менять её поведение в части обработки HTTP запросов кажется тоже тяжеловато. НО! Если ты в данном проекте не планируешь менять эту библиотеку на другую, уверен что не придётся делать те же ретраи, уверен в коде своего papi client'а настолько чтобы не писать unit test'ов - оставь так и не парься

секундочку. при чем здесь SDWebImage?

Картинки кеширует после загрузки он

ты предлагаешь писать 10 разных сетевых стеков для разных ситуаций?

ну или не писать а использовать.

ну АФНетворкинг не кеширует картинок полноценно

насколько я знаю, нужно юзать что-то доп, что бы они сохранялись

мы весь вечер рассказывали про dependency injection который позволяет писать хороший поддерживаемый код. Если у тебя в данном месте код написан один раз и особо потом меняться не будет (т.е. не требует поддержки) - то и DI там тебе особо пользы не принесёт

http://blog.originate.com/blog/2014/02/20/afimagecache-vs-nsurlcache/

мы весь вечер рассказывали про dependency injection который позволяет писать хороший поддерживаемый код. Если у тебя в данном месте код написан один раз и особо потом меняться не будет (т.е. не требует поддержки) - то и DI там тебе особо пользы не принесёт

ну глобально менятся точно не будет.

по крайней мере то, что касается запросов сетевых

а меняется все вокруг логики постоянно. то экраны, то их положение, то функции экранов и все в таком стиле

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