What is the best way to break classes in an Android project?

Question

Android

What is the best way to break classes into packages:
-by purpose
-database
-network
-reader
-ui
-by class
-activities
-adapters
-fragments
-model
-utils
-widgets
Best-practices from Github recommend breaking as shown in the second example, but because of this, the application code will not be modular and such code will be difficult to reuse (correct if this is not the case). How to be?
You can also show your options.

Answer 1

Makhach Imangazaliyev , you would use the search on the forum to get started. A similar question was asked quite recently . Here is an example of my structure in a simple project:

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

Answer 2

Break it up however you like.
Packages are essentially just directories, how will this affect the classes themselves and their modularity? :)

Answer 3

Have you tried developing under Windows? Not? But in vain.
If they tried, they would understand that it’s clear to the hedgehog that development for the native OS API is 3.14.
But only Windows has long included a high-level .NET framework that abstracts you from this 3.14 and which, in general, can be used directly (although it is far from ideal, you can make one more wrapper if you know how and understand) .
And for Android, there is really no such framework either out of the box or third-party. So, in any case,
you need to write such a wrapper yourself and use it.
But! The wrapper is a separate layer of abstraction. It does not prevent you from grouping GUI classes and packages in any way. GUI (to the same services, etc.) is one more, separate layer of abstraction. They cannot exclude each other.
So nothing prevents you from making 2 packages and in one of them put this:
-activities
-adapters
-fragments
-model
-utils
-widgets
And in the other this:
-database
-network
-reader
-ui // not GUI here, but high-level tools for the GUI, for example, a wrapper for Toast
Then the gui will remain in the package with the gui, and the package with the framework can be freely transferred from one project to another.
Or, if the project is small, then you can limit yourself to this:
-activities
-adapters
-fragments
-model
-utils ( and here - throw all wrappers, because they are utils in essence )
-widgets