Как лучше разбивать классы Android-проекта?

Question

[Махач Имангазалиев]

Как лучше всего разбивать классы по пакетам:
-по назначению

-database
-network
-reader
-ui

-по классам

-activities
-adapters
-fragments
-model
-utils
-widgets

Best-practices с Github рекомендуют разбивать так, как показано во втором примере, но из-за этого код приложения не будет модульным и такой код будет трудно переиспользовать (поправьте, если это не так). Как быть?

Можете также показать свои варианты.

Answer 1

[Алексей]

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

ru.mycompany.myapp
├─ activities
├─data
   └─  dao
├─views
   ├─ adapters
   ├─ customview
   ├─ fragments
   └─ widgets
├─ network
   └─api
     └─responce
├─ models
└─utils

Comments

[Махач Имангазалиев]

Спасибо за хороший ответ

Answer 2

[Константин Довнар]

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

Answer 3

[VZVZ]

Вы под винду разрабатывать пробовали? Нет? А зря.
Если бы пробовали, то понимали бы, что и ежику ясно, что разработка под нативное API ОСи - это 3,14.
Но только в винду уже давно входит высокоуровневый фреймворк .NET, который абстрагирует вас от этого 3,14 и который в общем-то можно использовать и непосредственно (хотя и он далеко не идеален, можно и еще одну обертку сделать, если уметь и понимать).
А для Android такого фреймворка толком нет ни из коробки, ни стороннего.
Так что, подобную обертку в любом случае необходимо написать самому и юзать ее.

Но! Обертка - это отдельный слой абстракции. Она никак не мешает вам группировать GUIшные классы и пакеты. GUI (туда же сервисы и т.д.) - это еще один, отдельный слой абстракции. Они не могут исключать друг друга.
Так что ничто не мешает вам сделать 2 пакета и в одном из них разместить это:
-activities
-adapters
-fragments
-model
-utils
-widgets
А в другом это:
-database
-network
-reader
-ui // здесь не GUI, а высокоуровневые средства для GUI, например, обертка для Toast

Тогда гуй останется в пакете с гуем, а пакет с фреймворком можно будет свободно перекидывать из одного проекта в другой.

Или, если проект мелкий, то можно ограничиться только этим:
-activities
-adapters
-fragments
-model
-utils (а вот сюда - кидать все обертки, ибо они и есть utils по сути своей)
-widgets