I
и еще кое что. если появится какие то баги с подписками их тоже надо опубликовать чтоб тестить?
Size: a a a
2020 April 15
U
Iwa
и еще кое что. если появится какие то баги с подписками их тоже надо опубликовать чтоб тестить?
Баги опубликовать?
I
нет. если появится какие на прежнем чтобы фиксить и тестить новый билд
U
Iwa
нет. если появится какие на прежнем чтобы фиксить и тестить новый билд
Слова знакомые, смысл понять не могу.
Но тестировать биллинг можно и на отладочной сборке.
Но тестировать биллинг можно и на отладочной сборке.
СП
Всем привет, знающие леди и джентльмены. Подскажите по некоторым общим вопросам. Есть задача наш сервис (аутентификация пользователя / подтверждение его действия) поставлять для сторонних разработчиков (нацелено на организации типа банков).
Первый основной флоу - регистрация пользователя в системе. Регистрация включает в себя генерацию пары ключей, шифрование данных, несколько хттпс реквестов, парсинг пушей с фаербейса, сохранение данных пользовательской учётки (типа юзернейм и юзерсид для секьюрческих целей) в бд.
Следующий флоу - авторизация. Включает в себя парсинг пуша, получение сохранённых на этапе регистрации данных из бд, цепочку хттпс реквестов, всякое там шифрование-расшифрование с RSA, итог - предоставление разрабу колбеков с TOTP (одноразовый пароль для сверки с таковым на сайте, который истекает в реальном времени и меняется на другой) и возможности послать ответ на запрос авторизации (accept, decline).
Здесь основной архитектурный вопрос - как это всё лучше скомпоновать?
На данный момент в общих чертах идея такая: поставляется либа с
1. Регистратором, в который подкидывается начальная инфа для реги и инициируется собственно рега.
2. Авторизатором, который, собственно, нужно инициализировать где-то и который по пушу будет запускать флоу авторизации.
Сделать их хочу синглтонами, чтобы меньше париться потому что не знаю, как иначе.
Первый основной флоу - регистрация пользователя в системе. Регистрация включает в себя генерацию пары ключей, шифрование данных, несколько хттпс реквестов, парсинг пушей с фаербейса, сохранение данных пользовательской учётки (типа юзернейм и юзерсид для секьюрческих целей) в бд.
Следующий флоу - авторизация. Включает в себя парсинг пуша, получение сохранённых на этапе регистрации данных из бд, цепочку хттпс реквестов, всякое там шифрование-расшифрование с RSA, итог - предоставление разрабу колбеков с TOTP (одноразовый пароль для сверки с таковым на сайте, который истекает в реальном времени и меняется на другой) и возможности послать ответ на запрос авторизации (accept, decline).
Здесь основной архитектурный вопрос - как это всё лучше скомпоновать?
На данный момент в общих чертах идея такая: поставляется либа с
1. Регистратором, в который подкидывается начальная инфа для реги и инициируется собственно рега.
2. Авторизатором, который, собственно, нужно инициализировать где-то и который по пушу будет запускать флоу авторизации.
Сделать их хочу синглтонами, чтобы меньше париться потому что не знаю, как иначе.
Сложна...
Вам нужен нормальный тимлидер + консультанты. Околобанковские приложения по советам из чатика не пишутся. Одна ошибка в архитектуре или воркфлоу и у клиентов потырят деньги.
RSA к примеру несекюрными считаются, забудьте про него и стройте крипоту на норм шифрах из проверенных либ где не будет детских ошибк и так далее
Вам нужен нормальный тимлидер + консультанты. Околобанковские приложения по советам из чатика не пишутся. Одна ошибка в архитектуре или воркфлоу и у клиентов потырят деньги.
RSA к примеру несекюрными считаются, забудьте про него и стройте крипоту на норм шифрах из проверенных либ где не будет детских ошибк и так далее
I
Слова знакомые, смысл понять не могу.
Но тестировать биллинг можно и на отладочной сборке.
Но тестировать биллинг можно и на отладочной сборке.
ща вопрос: мне нужно тестировать биллинг подписки. доке написано что опубликовать в альфа тестирования. Но 2-3 дня прошло. Приложение ну опубликуется. Вопрос как можно тестить биллинг подписки в дебаг режиме или
U
Iwa
ща вопрос: мне нужно тестировать биллинг подписки. доке написано что опубликовать в альфа тестирования. Но 2-3 дня прошло. Приложение ну опубликуется. Вопрос как можно тестить биллинг подписки в дебаг режиме или
Да залей ты его во внутренний тест и проверь
I
хорошо спасибо
ДР
Всем доброго вечера! Кто нибудь делал Recycler view с пагинацией и Staggedgridlayoutmanager?Если делали, можете скинуть пример?
EC
Iwa
ща вопрос: мне нужно тестировать биллинг подписки. доке написано что опубликовать в альфа тестирования. Но 2-3 дня прошло. Приложение ну опубликуется. Вопрос как можно тестить биллинг подписки в дебаг режиме или
Публикуете приложение в Play, можно во внутреннее тестирование. Сейчас первоначальная публикация занимает около недели. Создаете в Play продукты. Добавляете свой Play аккаунт, используемый на девайсе, в список License testers. После этого можно тестировать. Можно на эмуляторе с установленным Play.
I
Evgeny Cherkasov
Публикуете приложение в Play, можно во внутреннее тестирование. Сейчас первоначальная публикация занимает около недели. Создаете в Play продукты. Добавляете свой Play аккаунт, используемый на девайсе, в список License testers. После этого можно тестировать. Можно на эмуляторе с установленным Play.
Спасибо
V
Есть у кого то пример mvi на корутинах с акторами?
2020 April 16
T
Всем привет, подскажите пожалуйста есть ли разница если зависимости объявлять в дополнительном gradle файле в ext или создать object class kotlin и в нем прописать? Это просто кому как удобно? или есть какой то профит явный
Y
Всем привет, подскажите пожалуйста есть ли разница если зависимости объявлять в дополнительном gradle файле в ext или создать object class kotlin и в нем прописать? Это просто кому как удобно? или есть какой то профит явный
Ежели kts то объект конечно.
А так - отдельный файл.
А так - отдельный файл.
Y
Всем здоровья. Созрел вопрос. Есть либа, внутри которой есть зависимости от гуглосервисов, фейсбук сервисов. Есть прила в которой должны отсутствовать гуглосервисы, но вместо них будут их хуавей-аналоги. Как кошернее:
1. Разделить либу на 3 отдельных узкоспециализированных (в каждой по 1 зависимости). Возможно потребуется еще одна либа, с общим для всех кодом.
2. Что-то намутить с gradle, flavor сборкой.
3. Что-то еще.
Склоняюсь к 1 варианту, но на всякий спрошу.
1. Разделить либу на 3 отдельных узкоспециализированных (в каждой по 1 зависимости). Возможно потребуется еще одна либа, с общим для всех кодом.
2. Что-то намутить с gradle, flavor сборкой.
3. Что-то еще.
Склоняюсь к 1 варианту, но на всякий спрошу.
TY
Выдели общий код в отдельный модуль и раздели либу на две части
МE
Привет архитектурщикам. Можно ли сейчас в проект не тянуть RX? Например, ради задачи реализации "живого поиска с подсказками", когда на сервер запросы уходят с таймаутом
AV
Можно, есть куча других инструментов
корутины, flow, лив даты
корутины, flow, лив даты
r
можно ли заменить хождение в репозиторий юзкейсами?
т.е такую сущность как репозиторий полностью заменить юзкейсами?
т.е такую сущность как репозиторий полностью заменить юзкейсами?
I
можно ли заменить хождение в репозиторий юзкейсами?
т.е такую сущность как репозиторий полностью заменить юзкейсами?
т.е такую сущность как репозиторий полностью заменить юзкейсами?
А юзкейсы откуда данные брать будут?