@artshelom

Код ревью неофициального приложение для тостера?

Доброго времени суток.

Решил сделать доброе дело всем, кто сидит и читает вопросы на данном прекрасном сайте с телефона.
Мое первое приложение для телефона cloud.mail.ru/public/73zn/CAs2L1zjA
Так что если код где-то не нравится ругайте, чтобы я больше не писал "говно" код. Есть много моментов которые нужно дописывать, хотел сделать оповещение на подписанные вопросы и главное авторизацию, с которой у меня много проблем.

На данной стадии интересно нужно ли вообще людям данное приложение, и какие ошибки у меня есть??
Ссылка на майл хранилище с github, чего-то разобраться не могу((

screenshots
33974e23b5504737a423baa55a8f446f.jpg5ce47d3c7fff4f7ba9ee0c5ec7515ad9.jpg99367bad95944b90b7d338de586795bc.jpgf30dd695a2334cae8657cfc6b29d99cc.jpg978c6889144c4e46aeda3446a5fb70aa.jpg
  • Вопрос задан
  • 333 просмотра
Решения вопроса 1
@red-barbarian
1. ревью (инспекция кода) не бывает без ругательств. Есть закон от небожителей "качество кода измеряется количеством ругательств которые извергает читающий". Т.е. обратно пропорционально. А значит никогда не равно 0. )))
Поэтому, не верить когда говорят что все хорошо и идеально. Значит не вникли.
Не верить, когда говорят что все г..но. Или что-то г-но. Прислушиваться, но не верить. Это так философское отступление)
2. Исследовать рынок нужно до написания. До начала. Или после. Нельзя делать это во время первого выпуска. Иначе, можно потерять интерес к написанию. К самому выпуску продукта. Исследование не факт, что покажут реальные результаты. А продукт будет не выпущен. После выпуска можно узнать как улучшить продукт или чем дополнить. Повторюсь, не делать это во время подготовки первого выпуска.
3. Уже писали ГитХаб. Постараться сделать работу людей удобнее. В том числе тех кто проверяет Ваш код. Поверьте это того стоит.
4. Философский вопрос открывать или не открывать код. Если хотите научиться писать открывайте.

По коду. Поверхностно. пример QuestionFragment
Есть библиотеки которые улучшают код. например ButterKnife. они простые, но код понятнее (короче).
Ссылки на url лежат в методе getHttp очень не удобно. Думаю лучше разделить текстовые ссылки в одно место, построение и выполнение запроса в другое (общий случай) . получение данных в третье. Постараться придерживаться принципа единственной ответственности. Что бы сделать код проще.
Фрагмент содержит как отрисовку, так и бизнес логику (логику работы приложения). Так загромождается код. Получается огромные запутанные классы. Посмотрите шаблон MVP. Им можно упростить код. Даже сильно.
Насколько я понял, при переворачивании экрана идет считка заново данных. Это не хорошо. Даже если кешируется запрос. Используйте например MVP + Dagger2
(еще одна модная, вернее, уже традиционная библиотека)

Можно смотреть
Loader (загрузка данных)
RxJava (работа например с ретрофитом, потоками-нитями, и проч проч. очень полезная)
SOLID (принципы. для того чтобы сделать код гибче и понятнее)

Пытаться разбивать программу на независимые компоненты которые можно переиспользовать.

Не воспринимать мои слова как абсолютную истину. Большого опыта написания андроид-апп нет. Но если есть желание выслушивать критику напишите мне в например в vk.
Вообще, удачи Вам с проектом.)
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 1
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
Не открывай код, используй OAuth из ключницы для логина в приложение.
Дело делаешь, действительно, доброе, но лучше - покажи только небольшую часть кода и потом, продай свой продукт.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы