Комментарии 12
Про пароли было бы интересно почитать)
А можно поинтересоваться зачем нужно изобретание велосипеда именно в виде приложения с именно такой функциональность. когда уже сто лет как существует KeePassXC? Если только в целях изучения Compose, то понятно, но для хранения паролей... Не понятно вообще.
Дело в том, что когда я выбирал тему приложения, то я руководствовался несколькими параметрами:
Жизненная ситуация: мои пасы были слиты одной компанией N (я пользовался их сервисом безопасного облачного хранения - имен называть не буду по известным причинам)
Хотел максимально маленькое приложение (в минимальном приближении, но не бесполезное с точки зрения функционала), чтобы сильно не зарываться на первых парах (т.к. все таки "обкатываю" Compose)
Я люблю интуитивные, понятные, эстетически приятные интерфейсы (коим KeePassXC в моем представлении не удовлетворяет - опять же это только мое субъективное восприятие)
А еще я в перспективе, хочу добавить возможность напрямую подрубать, условно, флешку в девайс. чтобы хранилищем выступало не устройство, а внешний носитель. Тогда безопасность будет уровня "тетрадка в сейфе", т.к. приложение будет выступать лишь удобным интерфейсом взаимодействия с хранилищем. Как-то так. Надеюсь ответил на ваши вопросы о причинах выбора данной темы приложения)
На скриншоте, в Google Play:
"Ваше неприс" "Тупное место для паролей".
По существу, наверное, всё-таки, хранить на телефоне не айс идея, во вторых, а чем сервер не угодил, вообще не понятно, все же уже есть в kotlin, бери и делай хоть rest, хоть gRPC, хоть GraphQL, вообще, просто с Google авторизуйся - профит. Третий момент - от количества навернутых друг на друга алгоритмов шифрования, исходный ключ сложнее не становится, основная теорема. Сложность ключа все равно равна сложности самого сложного алгоритма, привет, ассиметричное шифрование. Ещё привет, пароли хранить на сервера можно, но вот делать 2FA для менеджера паролей - надо, и мастер пароль не единственное решение, есть QR, OTP, hardware tokens, fingerprints.
Хранение на устройстве - не самая идеальная история, согласен, но она определенно проще контролируется с точки зрения безопасности, нежели хранение личных данных на стороннем сервере. Если мы гоняем данные, пусть и по защищенному каналу в облако, то проблема здесь в том, что данные хранятся в облаке и агрегрируются данные там не только мои, но и миллионов других пользователей. С точки зрения банального экономического "интереса взломщика" такой узел, на котором много данных (которые потом отлично продаются), становится куда более интересным для атаки, нежели мой личный телефон.
Да и безопасность телефона определенно будет выше, со стороны внешнего взлома при условии: приложения с непроверенных источников не ставить, по не нужным сайтам не ходить, файлы непонятные не качать и т.д. и т.п.. Шифрование в моем случае, это своего рода второй фактор безопасности к первому естественному (этим устройством пользуюсь только я и пользуюсь с соблюдением банальных правиль личной безопасности).
На самом деле, из абсолютно надежных средств хранения можно выделить, разве что: "блокнот и ручка в сейфе". Здесь даже личная голова будет далеко не идеальным средством, т.к. она имеет свойство "забывать".
Я не пытаюсь сказать, в однозначном порядке, что мол "нет, не пользуйтесь облачниками, это ужасно и плохо". Нет, они хороши по своему. Просто, когда ты параноишь, но при этом бесишься от того, что постоянно нужно вводить ручками пароль с бумаги или пользоваться существующими решениями с интерфейсом времен 2000х, то со временем появляется устойчивое желание найти что-то удовлетворяющее всем твоим требованиям. А когда не находишь, то берешь и делаешь что-то подобное сам =)
P.S.: В моем случае главным мотиватором, чтобы отказаться от внешнего хранилища было как раз таки то, что мои данные с этого облачного менеджера слизали.
В моем случае, комп сказал, что ему очень сложно. Когда ты изменил размер текста в xml это заняло 5 секунд на перерисовку. С compose я видел изменения через 5 минут.
Если речь идет про перерисовку на превьюшке в студии, то там есть еще некоторые проблемы с тулзами для разработки, но это дело поправляемое. Например, если дебажить на физическом устройстве, то все довольно шустро отрабатывает (тут просто нужно капать в причину, почему вы столкнулись с такой проблемой).
Если речь про перформанс в сборке, то тут, на самом деле, многое зависит от того, как использовать рекомпозицию. В Compose есть свои особенности связанные с условиями при которых происходит перерисовка. И если пользоваться этим инструментом неправильно, то вместо, скажем, рекомпозиции отдельной кнопки, будет происходить перестроение всей иерархии. Тогда да, тогда перформанс просядет ощутимо (особенно заметно будет на списках или вложенных компонентах интерфейса).
Но тут на самом деле даже причина не в инструменте, а в том как его используешь. Просадить перфоманс можно и наверстав LinearLayout'ов вложенных, условно)
Ну, вы описали только UI часть - самую тривиальную для compose часть . А самая не тривиальная - это где и как реализован дата слой и как он передается в compose функции. А также если надо как делаются врапперы всякие над классами android sdk если они нужны итд.
Ui часть в compose действительно просто. А вот во всем остальном можно завязнуть, особенно если проект большой.
Также стоит упомянуть библиотеку accompanist, как хелпер для всяких вещей , там appbar, bottombar итд.
Также важно осветить вопрос навигации
Про навигацию - рекомендую Decompose от Аркадия Иванова
Задача данной статьи была скорее обзорной, в дальнейшем планирую выпустить серию статей относительно отдельных направлений применения, в том числе, будет статья про то, как Clean (и разделение на слои) дружится с Compose.
Про accomponist вы верно заметили, позволяет избавиться от реализации большинства велосипедов.
Про навигацию вас услышал, обязательно на данную тему подготовлю статью. В планах рассказать как я подружил Compose Navigation и собственную реализацию роутера для межмодульного взаимодействия.
Как я приложение на Compose писал