Критика кода одного приложения

Если идти сверху вниз по коду, то:

1) Массовые беспорядочные импорты (Вам оно всё действительно надо?).

2) Не пользуетесь модификаторами доступа.

3) Не соблюдаете правила именования переменных.

4) Context в Activity вынесен зачем-то в поле класса (в случае с Activity не лучше ли использовать this?).

5) Инициализация List<UserModel> users вынесена в отдельный метод, когда можно было сделать это сразу же в поле класса, где эта переменная объявлена.

6) Инициализацию UserAdapter adapter после п.4 казалось бы можно было сделать в поле класса, где эта переменная объявлена, но если хорошо подумать, то вынесена она отдельно, только, чтобы однажды обновить этот адаптер. RecyclerView вам предоставит адаптер по требованию .getAdapter().

7) Некоторые View вынесены в поля класса, но используются единожды за весь код, а некоторые используются вообще в момент их же инициализации. Например переменная fab_add инициализируется в onCreate в одном методе, а используется единожды всё в том же onCreate, но в другом методе. В данном случае, с опытом предыдущих пунктов, от вынесения кода в методы initViews(), setupViews(), initAdapter() следует отказаться, тогда и переменную fab_add в поле класса выносить не придётся.

8) Строковые ресурсы принято выносить в отдельный файл string, расположенный в ресурсах проекта.

9) Постоянное создание нового объекта new Handler(), когда каждая View содержит в себе Handler. Возьмите любую из ваших View, вынесенных в поле класса и скажите ей .post или .postDelayed.

10) Постоянное создание объектов на протяжении всего кода.. new Response.Listener(), new Runnable(), new Response.ErrorListener().. , Вас когда-нибудь проклянёт сборщик мусора. Например разные вариации new Runnable(), которые, если вглядываться, вероятно часто вызываются. Вот тут как раз стоило бы вынести данные объекты Runnable в поле класса проинициализировав однажды, после чего взывая к ним.

11) Такой перенос скобок мб и используется в таких языках, как C++, но в Java привычнее всё таки фигурную скобку открывать без новой строки. Если к этому поудалять лишние пробелы и учесть предыдущие пункты, то в классе UserActivity количество строк кода можно будет сократить с 400 до 200-250 (навскидку).

Это я просмотрел только один класс UserActivity. Остальные смотреть лень :)

Перед критикой: в общем неплохо, я бы даже сказал очень неплохо. Твердая 4.

Теперь критика:

1. Нарушение стиля именований - сильно смущает имя интерфейса TrigListener - неужели трудно было назвать TriggerListener?
2. Вообще что мешало TriggerListener сделать публичным внутренним классом TriggerActivity? Целостность кода не нарушалось бы
3. Сильно увлекаетесь анонимными классами - "ступеньки" кода как бы иллюстрируют проблему читаемости кода. Можно бы кое-где и разбавить лямбда выражениями
4. Есть некоторые стилистические проблемы с фигурными скобками - то они всегда с новой строки, то они на старой строке
5. Одинарные if/else зря обрамляете фигурными скобками
6. Хотя бы в бинах надо бы применять private
7. Почти не используете аннотации (кроме самоочевидной @Override) - рекомендую присмотреться к ButterKnife
8. Конструкцию

public class TriggerActivity extends AppCompatActivity implements OnClickListener, TrigListener

я бы написал так:

public class TriggerActivity extends AppCompatActivity implements OnClickListener, TriggerListener