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 там тебе особо пользы не принесёт

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

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

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

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

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

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

а спагетти код - это длинные методы?

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

синлтон – зло, передавай черз инициализатор

Поэтому Apple его использует в новом коде, да и не только Apple.

а спагетти код - это длинные методы?

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

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

Ну то есть это отсутствие CR, а не необходимость DI. Если человек так пишет, ему практики не помогут

Вопрос был общий, про "Вот и интересно, когда это приходит на помощь"

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

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

Поэтому Apple его использует в новом коде, да и не только Apple.

это в пользу синглтонов аргумент или против, я не понял :)

Это в пользу того что нет универсальных решений и singleton не является злом всегда.

Это в пользу того что нет универсальных решений и singleton не является злом всегда.

расскажи ситуацию, когда синглтон – не зло.

Я тебе привел пример что его до сих пор использует компания, благодаря которой ты в принципе имеешь работу.

Что такое синглтон?

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

Я тебе привел пример что его до сих пор использует компания, благодаря которой ты в принципе имеешь работу.

не понял, при чем здесь это?

когда у тебя есть некий god-object

который 100% всегда один на время жизни приложения

который точно никогда никогда не придётся удалять

В Realm есть метод default, тоже по сути singleton. Они там тоже не шарят?

хотя проблемы с многопоточностью остаются

тут не шарят-нешарят

когда у тебя есть некий god-object

А потом делаем (MyAppAwesomeDelgate*)[[UIApplication application] delegate]?

не вижу зла в сингелтоне если использовать прально

тут баланс удобства использования против опасности

В Realm есть метод default, тоже по сути singleton. Они там тоже не шарят?

они делают так, что бы их либой было легко пользоваться

Ну лол

ок, я вижу зло в синглтоне - невыгружаемый из памяти объект, шарящий своё состояние между всеми тредами (и позволяющий его менять обычно), который непонятно кто и когда и как использует?

что может пойти не так?

к которому есть доступ у всех 100500 библиотек которые подключены в твой код

но удобен, сцуко

а если он никаких состояний не хранит?

ERROR: S client not available

к которому есть доступ у всех 100500 библиотек которые подключены в твой код

Эээ, как у посторонней библиотеке есть доступ к твоему singleton?

к UIApplication есть

Откуда ей вообще знать про твои классы.

вопрос был "ты видишь зло в синглтонах ?"

никто не уточнял чей именно синглтон

UIApplication не твой объект

и что?

у реалма тоже не мой синглтон

это не говорит о том, что 3rd party библиотеки не могут его использовать

То что ты ерунду написал. У third party нет доступа к твоим объектам

yup нет

и что?

а если он никаких состояний не хранит?

пример?

То что этот аргумент мимо

ещё раз - я не говорил "почему МОЙ синглтон - плохо"

я говорил "я вижу зло в синглтоне"

да даже в своём синглтоне я зло вижу

чего уж там

представь - команда 5 человек

Ты сразу пиши каких человек

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

команда звёзд может писать на чистом ассемблере с использованием GOTO for all i care

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

потому что большая часть процесса программирования - борьба с чёртовой сложностью

Ты за всех зря говоришь

ты прав

обобщаю, увлёкся

То у тебя singleton плохой, а у других почему то работает. То еще что то

это мой опыт

другого не имею

возможно мне в жизни фатально не везло

То у тебя singleton плохой, а у других почему то работает. То еще что то

а при чем здесь работает и зло? зло тоже работает