у рамблера есть хороший пример с кодом на вайпере, воот

я всегда в синглтоне держу набор методов с запросами к серверу. и когда что-то надо получить - довольно удобно просто обратиться и получить колеком нужные данные. Такой подход плох чем-то?

я всегда в синглтоне держу набор методов с запросами к серверу. и когда что-то надо получить - довольно удобно просто обратиться и получить колеком нужные данные. Такой подход плох чем-то?

tight coupling

сильная связность

а в чем связность? Там по сути просто набор методов и блоки на ответ success или failure

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

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

ой

переменными в вызовах

в скобочках

в gang of four порицаются синглтоны

возможно! если ты на вход подаешь только сущность и на выходе сущность, то в принципе ок

а, ну и вот еще

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

вооот

ну и еще там немного много принципы solid нарушаются

параметры все передают просто словарем. выглядит прибл так +(instatype)sharedInstance; - (void)getUserByParameters:(NSDictionary *)parameters success:(myBlockSucCallback)successCallback failure:(myBlockFailCallback)failureCallback; Их норм юзать в синглтоне?

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

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

перед каждым вызовом?)

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

обычно так и делается. Через инъекцию зависимостей. Через какой-нибудь там Swinject или Typhoon.

перед каждым вызовом?)

++ Вот тоже постоянно этим заморачиваюсь

я всегда в синглтоне держу набор методов с запросами к серверу. и когда что-то надо получить - довольно удобно просто обратиться и получить колеком нужные данные. Такой подход плох чем-то?

господа, это ведь не синглтон

этож фабрика, нет?

ну инициализируется он так: #pragma mark - Initialization + (PApiClient *)sharedClient { static PApiClient *_sharedClient = nil; static dispatch_once_t oncePredicate; dispatch_once(&oncePredicate, ^{ _sharedClient = [[self alloc] initWithBaseURL:[NSURL URLWithString:kBaseURLString]]; }); return _sharedClient; }

ну да, синглтон

этож фабрика, нет?

та не

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

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

зато быстро!)

А как правильно-то

но этот синглтон всего лишь возвращает то, что сервер присылает, в виде словаря и все) больше никаких действий не выполняет

А то столько умных слов, принципов, моделей, фабрик

но этот синглтон всего лишь возвращает то, что сервер присылает, в виде словаря и все) больше никаких действий не выполняет

так сам то синглтон, не о том же

а так подход правильный

А то столько умных слов, принципов, моделей, фабрик

ну слова обычные. А правильно писать по стандартам. От которых себе в ноги не выстрелишь

ааа, чай забыл

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

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

вот собственно отдельный уровень абстракции будет нормас

ну слова обычные. А правильно писать по стандартам. От которых себе в ноги не выстрелишь

А где можно почитать про стандарты нормально? И желательно с исходниками приложений полностью по стандартам

Шаблоны проектирования на русском: https://nixsolutions.github.io/design-patterns/

или книга от банды четырех

Паттерны проектирования

самих стандартов не существует

есть только гайды и стайл-гайды

на проектирование

НЕ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕСА

А где можно почитать про стандарты нормально? И желательно с исходниками приложений полностью по стандартам

по тегам SOLID, clean code. https://github.com/strongself/The-Book-of-VIPER

Боб Мартин "Чистый код"

архитектура viper хорошо реализует solid . Там еще пример проекта есть

Боб Мартин "Чистый код"

вот, тожэ плюсую

а если есть куча времени - можно пойти по хардкору и проникнуться стандартами JEE

после которых либо сходишь сума, либо начинаешь думать наперед

еще советую почитать про анти-паттерн massive controller

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

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

На своем серваке можно дополнительно проверять receipt покупок

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

Если, конечно, у тебя покупки не привязаны как-то к профилю пользователя на твоем сервере

по тегам SOLID, clean code. https://github.com/strongself/The-Book-of-VIPER

Спасибо, посмотрю

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

Однотипные операции и бизнес-логика инкапсулируются в обычный(е) класс(ы). Хелперские функции типа "тянуть из сети", всякие преобразования-кастинги, вытяжки из локальной БД, это всё private func. Сделать классу public interface из 1-2-3 методов и юзать их по мере надобности в нужных VC. VC - только для управления view. Ну то есть для бизнес-логики выстроить собственный API. А на его базе фигачить УЙ (VC + view). Я так...думаю.

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

как идентифицируется юзер при восстановлении покупок? у меня идент вариант: либо он про юзер либо не про, в зависимости от этого мы ему даем внутри приложения либо показываем рекламу либо нет.

Если, конечно, у тебя покупки не привязаны как-то к профилю пользователя на твоем сервере

Данные и про и не про отдаются одинаковые

как идентифицируется юзер при восстановлении покупок? у меня идент вариант: либо он про юзер либо не про, в зависимости от этого мы ему даем внутри приложения либо показываем рекламу либо нет.

Ну, при совершении покупок тебе прилетают успешные транзакции. По id ты смотришь, что именно купили

«тебе прилетают» - мне это приложению?

При восстановлении точно так же прилетают транзакции, смотришь, что это было, открываешь доступ

да

А как сервак эплов определяет что мне отправлять? как идентфицирует7

На нем покупки привязаны к Apple ID

https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/DeliverProduct.html#//apple_ref/doc/uid/TP40008267-CH5-SW3

Есть метод - (void)paymentQueue:(SKPaymentQueue *)queue updatedTransactions:(NSArray *)transactions

Вот туда они и прилетают после обработки серверами Apple

case SKPaymentTransactionStatePurchased: [self completeTransaction:transaction]; break; case SKPaymentTransactionStateRestored: [self restoreTransaction:transaction]; break; а вот и обработка новой и восстановленной транзакции (по сути в completeTransaction и в restoreTransaction может быть один и тот же код, открывающий юзеру какие-то плюшки)

https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/DeliverProduct.html#//apple_ref/doc/uid/TP40008267-CH5-SW3

Спасибы буду курить бамбук)))

Ребят подскажите туториал нормальный по snapKit. У них на сайте очень кратко. У меня возникает ошибка: Я в superview добавляю два subview: headerview и footerview. Однако как я понимаю , make.top.equalTo(headerView.snp_bottom) не подцепляет нижнию границу headerview и расширяется на весь экран. Поэтому я не могу поймать target-ы кнопок

от headerView

Как бы footerView перекрывает headerView

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

снепкит

нуу нууу

мм