e-d-w-i-n / recipeapp Goto Github PK

Right now this buttons only responsive in the text area.

Change recipe details UI to match design from Figma

Images in ViewPager blinking before loading

1. В проекте перемешалось объявление функций и переменных. Удобнее всего, когда идет блок объявления переменных, а потом функций, не перемешивая их объявление

2. Повторяется написание функции Toast. Как можно заметить, в основном там меняется только отображаемая строка. Поэтому вызов Toast можно вынести в отдельную extention функцию к фрагменту, где на вход будет только нужная строка или ресурс.

3. RecipePictureFragment В некоторых моментах нарушен котлиновский кодстайл:

ContextCompat.checkSelfPermission(
requireContext(), Manifest.permission.WRITE_EXTERNAL_STORAGE)
== PackageManager.PERMISSION_GRANTED -> {
saveImage()
}
По котлиновскому кодстайлу будет

ContextCompat.checkSelfPermission(
requireContext(),
Manifest.permission.WRITE_EXTERNAL_STORAGE
) == PackageManager.PERMISSION_GRANTED -> {
saveImage()
}

Двойные табуляции там, где их не должно быть. Пример LoadImage.kt :

Glide.with(context)
.load(imageUrl)
.placeholder(ColorDrawable(Color.WHITE))
.into(this)

4. Паттерн даты лучше вынести в отдельные константы, так как такой формат может использоваться почти во всем проекте

val updateDate: String = SimpleDateFormat("dd.MM.yyyy", Locale.getDefault())
.format(Date(lastUpdated * 1000))

5. Converters название функций fromString() и toString() по сути неправильны тут. Так как в этом классе есть еще и другие конвертеры, кроме как для List<String>, то название функций не дает информации для какого типа данных они предназначены. Назвать функции в таком случае стоит fromStringList и toStringList

6. SaveImage.kt Указание аннотации @Suppress("DEPRECATION") избавляет от варнинга студии, что используется deprecated код, но это не избавляет от того факта, что такой код всё еще используется и его использования нужно избегать)

Rework retrofit stuff to parse "Recommended recipes" properly

Current error screen is kinda ugly, this app needs a new one.

Refactor and simplify it

1. Достаточно большие функции onViewCreated в классах фрагментов. Эта функция, по сути, является точкой входа исполнения твоей логики во фрагменте, поэтому желательно делать эти функции максимально короткими и разбивать на функции поменьше.

2. Встречаются куски с достаточно большой воложенность. Если вложенность становится больше 3, то стоит задуматься над переносом внутренней логики в отдельную функцию

3. collect'ы лучше обрабатывать в классах ViewModel'ей, так как бОльшая часть логики должна находится именно там. Классы View должны отвечать в основном только за отображение данных.

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

5. Есть повторяющиеся куски кода, к примеру загрузка изображения через Glide. Лучше такие куски кода выносить в отдельную утилиту или экстеншн и потом переиспользовать во всем проекте

6. Транзакции в бд лучше делать в самом Dao классе. Так и логика добавления будет в одном месте и можно будет сразу передавать только нужный Dao в класс репозитория, а не весь RecipeDatabase

7. Не очень ясна необходимость в PreferencesManager'е. Первое на что хотелось бы обратить внимание, это то, что для хранения сортировки вполне достаточно хранить и обновлять в нужной вью модели. Второе, если всё же и использовать preferences, то сами они больше относятся к логике data, поэтому желательно и хранить их в соответсвующей директории. Тоже касается и networkBoundResource. Он используется для работы с data сущностями, получением запросов с сервера и обращению к бд, поэтому его нахождение вне data немного выбивается.

8. Лишняя вложенность в xml файле с деталями фрагмента. Можно было оставить либо только LinearLayout, либо ConstraintLayout у ScrollView чайлда

9. Лучше давать названия классам исходя из того, для чего они нужны. К примеру название Pager2ViewHolder не дает информации для чего конкретно нужен данный класс. Лучше переименовать примерно как ImagesViewHloder или PictureViewHolder. Тоже касается и его вьюхолдера

10. Чтобы избежать лишней вложенности в функциях, в которых почти постоянно используется один элемент, можно писать конструкцию fun sth() = with(useditem) {...}. Важно заметить, что при такой записи будет возвращаться результат последней строчки этой функции

11. Лучше не использовать Deprecated функции, студия сама подскажет как лучше сделать, достаточно навестись на deprecated метод и там будет подсказка что лучше всего использовать.

Change UI to match new design prototype