Алексей Мельников

Надо знать, как писать UI под андроид, из каких компонентов состоит UI, рекомендации по визуальному дизайну .

Перечень ограничений, которые android накладывает на приложение (какие разрешения просить, например, какие операции выполняются асинхронно). Какой паттерн для отделения бизнес логики от UI выбрать.

у каждого пользователя есть своя страница,

- Где и как хранить данные (тут нужен бекенд - это не связано с андроидом).
- Как приложение будет получать данные? (протокол работы приложения с фронтэндом)
- Каким образом обеспечивать авторизацию, защиту от подслушивания и перехвата. Модель атак на приложение.
- Соответствие приложения европейскому (GPDR) и российскому законодательствам о персональных данных

можно писать сообщения в ЛС либо в общий чат,

- каким образом работают оповещения на Android
- соответствие российскому законодательству об организаторах распространения информации

присутствует карта города, на которой

- Выбрать поставщика картографической информации (google, yandex, bing), ознакомиться с лицензией

отмечены какие-либо места с фотографиями,

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

также есть некая база с определёнными фотографиями/текстом, доступные всем.

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

ДА
Нет ниче более глупого и беспощадного чем прстыня пропсов на пару сотен строк
может не совсем академинчо но connect не сделает ваш компонент сильно уменнее, просто не выносите туда логику, этого достаточно

1. Если Вы можете понять код, просто объясните им проблему, укажите на ошибки и научите: это проще и дешевле, чем искать новых и "притираться" долгое время.
2. Пусть пишут текстом: для чего создан каждый объект и каждый из его методов.
3. Если не поможет - пусть изначально рисуют блок-схему.

Это сложный вопрос, на который нет однозначного ответа. Лично я для себя нашел следующие выходы: не связываться вообще с языками, в которых очень низкий порог входа (Javascript, PHP). Пытаться спорить и воспитывать коллег (это тяжело и дает плоды только на очень длинной дистанции). Менять работу.

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

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

Мы стараемся не запускать эту проблему посредством code review, пытаясь распределить нагрузку по ревью между наиболее опытными участниками. Если в коде есть проблемы - тикет возвращается на доработку с замечаниями. Даже если банально не мержится с главной веткой. Попробуйте наладить этот процесс.

Также мы всё собираемся настроить Continuous Integration. Jenkins может прогонять по коду проверку на соблюдение стандартов и покрытие тестами, а затем показывать результаты в красивом виде. Если чей-то коммит показывает более чем N ошибок в расчёте на единицу объёма кода - можно возвращать на исправление.

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

Ещё пара идей.

• можно отправить разработчиков на какой-нибудь онлайн-курс по чистому коду, хотя я таких даже не знаю, но наверняка должны быть
  
• или устраивать "хакатоны чистого кода", на коих команда разбивается на пары-тройки, каждая из коих пишет какую-нибудь маленькую, но полезную, а главное чистую и оттестированную штуковину, причём тема - по собственному выбору. Потраченное время - оплачиваемое, разумеется. Это уже зависит от руководства фирмы, согласится ли оно на такие развлечения.
  

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

Ну и важно, чтобы у самих разработчиков была установка на хороший код, профессиональная гордость. У фрилансеров её, бывает, нет, а есть отношение "тяп-ляп, лишь бы работало и лишь бы часы оплатили, а там хоть потоп". Учитывая, что их заказчики занимаются code review нечасто, развитие такого отношения закономерно. Но всё-таки хочется писать красивые программы. Такое желание обязано быть.

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

В xml каждой кнопки либо в styles добавь
android:textAllCaps="false"

По заявлению Android хранить в Shared Preferences с private mode безопасно. Небезопасно это на рутованных устройствах, ибо там к файлу Shared Preferences можно получить доступ (без рута андройд не пускает в папку приложения).

Так что если что-то серьезное - то лучше шифровать. Как шифровать? Я бы сам хотел увидеть ответ профессионала.

У себя я сделал так: генерирую сессионны ключ AES, беру информацию, шифрую ее на сессионном ключе, результат сохраняю в приватный файл. Далее сессионный ключ шифрую на постоянном ключе RSA и сохраняю результат в файл. Сам же ключ RSA храниться в KeyStore. Почему нужен сессионный ключ? Потому что RSA может шифровать только небольшое кол-во инфы (245 байт вроде на ключе в 2048 бит).

Получается что инфа зашифрована сессионным ключом, который в свою очередь зашифрован ключе который храниться в KeyStore. Сам же KeyStore, как я понял, является аппаратным хранилищем (по крайней мере в современных устройствах) и доверять ему можно. Доступ к сохраненному ключу доступен только инстансу вашего приложения, да и то не сам ключ, а только возможность им оперировать. То есть просто так спереть инфу, без модификации вашего приложения, не получиться.

Но сейчас думаю, не сморозил ли я фигню, ибо тот же сессионный AES ключ можно было бы сохранить в KeyStore. Ну и RSA кажется лишним - это же шифрование с открытом ключем. Думал сначала хранить часть ключа на устройстве, часть на сервере с доступом по пинкоду и удалением после пару неправильных вводов, но потом решил что это лишнее...

В конце концов даже разработчики гос приложений тупо пихают конфинденциальную инфу в приватные файлы и не паряться с шифрованием, и ничего, сертификацию ФСБ проходят.