Какая связь между хорошим источником данных и хорошо отображаемыми данными?

Почему и когда мне следует реорганизовать свой код?

Этот краткий обзор хорошо отредактированного кода ответит на эти самые вопросы.

Недавно я работал над Up, приложением для iOS, целью которого является повышение заинтересованности людей в работе.

Я отвечал за создание календаря с нуля. Этот календарь был довольно сложным, потому что для каждой даты цвет менялся в зависимости от количества достижений на эту дату, аналогично полосе GitHub.

Кроме того, когда выбрана дата, отображаются все достижения за этот день, отсортированные по часам.

Исходная реализация

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

Для этого мне нужно было отслеживать каждую дату и все задачи, выполненные в этот день.

Я использовал словарь, чтобы отслеживать дни. Ключом для словаря была дата в строковом формате, а значением - массив, содержащий все задачи на этот день.

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

Рефакторинг

Я хотел, чтобы каждый час был отдельным разделом. Однако для этого потребуется рефакторинг представлений, а также источника данных. Вот как выглядит новый макет:

Для правильного отображения всей этой информации мне потребовалось несколько вещей:

  1. Чтобы отображать в календаре правильный цвет, мне нужно было общее количество задач, выполняемых каждый день.
  2. Чтобы рассчитать количество разделов в табличном представлении, мне нужно было общее количество часов, в течение которых задачи были выполнены за выбранный день. Например, если бы я выполнял задачи только в 14 и 16 часов, мне нужно было бы только 2 дополнительных раздела, а не по одному на каждый час.
  3. Для каждого часа мне нужен был эффективный способ получить все выполненные задачи, чтобы отображать их в табличном представлении.

Реализация

Я создал собственную модель календаря. Он содержит словарь, который, как и раньше, имеет строки даты в качестве ключей, но вместо массива значениями являются объекты Day.

Объект Day содержит массив массивов, каждый подмассив представляет час. Счетчик подмассивов - это количество часов, которое используется для расчета количества разделов в табличном представлении.

При отображении данных в разделе мы используем подмассив, связанный с этим разделом.

Объект «День» также отслеживает общее количество целей, чтобы легко их получить при отображении цветов в календаре.

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

Спасибо, что нашли время прочитать эту статью. Если вам понравилось, не стесняйтесь оставлять несколько аплодисментов 👏 и, если вы нашли это полезным, поделитесь 📬 , чтобы он также мог помочь другим людям!