Интересно и достаточно детально написано. Спасибо.
Возник вопрос: а как при передаче ключей от А к В обходится ситуация, когда А уже выключен (не отвечает на запросы)? Например, пользователь отложил телефон, телефон залочен, и пользователь входить в чат с ПК.
Мы решаем похожую проблему и пока не нашли элегантного решения. Мы шифруем приватный ключ мастер фразой и храним на сервере. Тогда пользователь входящий с ПК должен ввести мастер фразу для расшифровки ключа. Но это неудобно с точки зрения UX т.к. большенство пользователей не заморачиваются запоминанием мастер фразы.
Спасибо за такой развернутый материал! Очень полезно было почитать. А что в вашем документе «Пример расчёта estimates/стоимости» означают столбцы Авторизация и Подтверждение личности?
А это под любыми версиями iOS работает? Мы пользовали cocoapods версию для вебсокетов как раз потому, что Apple только недавно добавила поддержку сокетов в свой SDK.
Всем привет! Давно ждал обзора RIBs на хабре. Мы (один из крупнейших банков в Австралии) уже успешно построили более 5 корпоративных приложений на RIBs и отзывы от разработчиков (разных категорий) исключительно положительные. Да, в самом начале есть потеря времени на вхождение в процесс и усвоение основ этой архитектуры. Но это время в разы меньше по сравнению с тем же VIPER-ом и тп. Конечно если лениво вникать, то можно продолжаться строить Massive View Controllers ну или запилить свой велосипед (очень, кстати, понимаю, когда хочется выразить весь свой опыт в своей мега архитектуре). Ребята из Убер реально вложились в проект, думая о различных аспектах современной мобильной разработки в команде. Респект им!
Кто хочет попробовать эту архитектуру, но сталкивается с вопросами, мы создали сообщество в слэке: uber-ribs-invite-automation.herokuapp.com Там всегда рады помочь и разобраться со спорными вопросами.
А также есть пример использования для основных задач в большинстве мобильных приложений: github.com/dev4jam/ToDo
Хотелось бы увидеть удобную реализацию решения на базе этого ядра такой популярной проблемы как обновление токена авторизации к апи и повторение запросов, которые привели к обновлению. Т.е. допустим токен авторизации протухает каждые 3 часа. Соответсвенно, следующий запрос вернет ошибку авторизации (что-то типа session token expired). Обычно, в такой ситуации, все следующие запросы становятся в очередь до момента обновления токена.
Какие-то уж очень очевидные вещи описаны под таким громким заголовком. ИМХО тонкости успешной реализации — это что-то типа того, что описано в блоге у Layer
Идея хорошая, но слишком абстрагированная от реальной жизни =) Тут можно бесплатно глянуть на наш вариант ;) Но тоже особо пока без движухи… надо серьезно вкладываться в маркетинг и продвижение — это факт!
Интересный подход... Стало очень похоже на Uber RIBs: https://github.com/uber/RIBs
Возник вопрос: а как при передаче ключей от А к В обходится ситуация, когда А уже выключен (не отвечает на запросы)? Например, пользователь отложил телефон, телефон залочен, и пользователь входить в чат с ПК.
Мы решаем похожую проблему и пока не нашли элегантного решения. Мы шифруем приватный ключ мастер фразой и храним на сервере. Тогда пользователь входящий с ПК должен ввести мастер фразу для расшифровки ключа. Но это неудобно с точки зрения UX т.к. большенство пользователей не заморачиваются запоминанием мастер фразы.
Кто хочет попробовать эту архитектуру, но сталкивается с вопросами, мы создали сообщество в слэке: uber-ribs-invite-automation.herokuapp.com Там всегда рады помочь и разобраться со спорными вопросами.
А также есть пример использования для основных задач в большинстве мобильных приложений: github.com/dev4jam/ToDo
А можно в LGSharing добавить инстаграм еще?
То начинает ругаться на инструкции «Invalid operand for instruction».
Что я делаю не так?