Сергей

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

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

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

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

Не воспринимать мои слова как абсолютную истину. Большого опыта написания андроид-апп нет. Но если есть желание выслушивать критику напишите мне в например в vk.
Вообще, удачи Вам с проектом.)

1. отдыхать. Т.е. высыпаться, гулять на свежем воздухе, делать простую работу полностью и с увлечением. (на словах очень просто, на деле сложно)
2. планировать свою учебу и чтение. Т.е. определить сколько время читаем или учимся. когда будет отдых. и т.д.
3. вероятно главный принцип эффективной учебы/чтения это пересмотр. почитали некую часть, отвернулись, вспомнили основные моменты. обдумали. Представили что кому-то объясняем эту тему. Ум должен увлекаться, прилипать к теме.
4. Планировать свои дела. Ум не должен быть нагружен работой по определению, что делать через минуту, как делать, где. и тд. постоянные такие вопросы просто его выматывают. И на нормальную умственную работу уже нет ментальных сил. Лучше уделить пол часа и запланировать на весь день. Даже если что-то пойдет не по плану.
5. Знать цель. Т.е. сознавать мотивацию. Для чего читаем, что хотим и т.д. Концентрацию в Индии примерно описывали так " представь что ты несешь чашу полную воды. Через площадь на которой толпа людей участвует в празднике. Крики шум и т.п. За тобой идет человек с топором. Если ты прольешь хотя бы каплю, то человек сразу отрубит тебе голову." Если приблизить к нашей жизни, то Зачем читать? Что будет если вникнуть в тему? Что будет если не изучить тему? Что будет если постоянно отвлекаться на соцсети и проч. Через неделю, год, десять лет.
еще советы: посмотреть Максима Дорофеева. Проблема современного человека не в том, что ему не хватает внимания, концентрации, энергии и проч. Проблема в том что он тратит внимание впустую. поверхностно. не вникая. Можно сказать он переконцентрирован, измотан концентрацией на совсем не нужных вещах.
Из медитации, посоветую випассану.

почитать про паттерны mvc, а лучше mvp.
прочитать про solid принципы. особенно про последний dip.
прочитать про tdd, особенно полезно посмотреть на примере как оно работает.
писать тестируемый код. переписывать это нормально для начала. иначе как понять, что архитектура не приемлема или неудачна. стараться разбивать программу на независимые компоненты. в итоге переписывать станет меньше.
из книг можно Мартин Р.С., Мартин М. - Принципы, паттерны и методики гибкой разработки на языке C# - 2011
из видео например https://www.youtube.com/watch?v=lDdJYid8NpE&t=432s
из статей https://habrahabr.ru/post/276593/

Проблема в изучении не в том, что бы найти хорошее изложение в видео или в книге. Проблема найти хорошего преподавателя который будет заниматься вычиткой ваших текстов. делать ревью.
Научиться писать не сложно, это можно легко сделать и самостоятельно. Выработать хороший стиль, ясный и выразительный как на уровне названия переменных, так и структуры всей программы, намного сложнее. Здесь нужны живые собеседники и критики.
Прискорбно, что многие курсы которые афишировали себя как курсы с ревью теряли качество после наплыва клиентов. Отзывы тому подтверждение. (естественно на независимых сайтах.)
Жаль, но не могу посоветовать именно такие курсы, но хотя бы обозначил направление в котором искать.
Еще параллельно советую читать книги что-нибудь по теме чистого кода, рефакторинга. Привычку к чистому коду нужно вырабатывать сразу, иначе будет дискомфорт в переучивании.
Когда программы станут более-менее сложнее, можно обратить внимание на TDD.
Ответ получился не конкретно по теме, но надеюсь будет полезен.Удачи.