Android Package Organization

Question

I'm new to Android development, so I have some questions about the Android project / code.

• Do people usually split API calls into separate class / classes? Or do you call them inside the object itself?
• Are packages only subdirectories? As far as I understand, they are used only in the interests of the programmer as an organizational tool.

I know that these issues are somewhat subjective, but I'm interested in how other developers organize their code. Thanks!

Answer 1

Organization of advertising packages. I have been developing Android apps for about two years, and I organized the source just like Andrea Chinesi wrote. But this week, I began to think it would be more appropriate for the package to be as an application module, for example:

com.example.android .car CarActivity CarListFragment CarDetailFragment CarListAdapter ... .route RouteActivity RouteListFragment RouteDetailFragment RouteListAdapter ... .utils .services etc. 

I still do not think that twice everything that was in the "module" (for example, in a data object). But why am I thinking of this change? Because in medium or large projects there are a lot of actions / fragments / etc. In one package - and it bothers me - I see this especially for large projects purchased from other developers.

And one more advantage can be divided into module packages - java package-private method visibility.

I have not yet decided whether to use this or that option, but I think that for small projects it doesn’t matter, and for a medium or large project these may be the preferred option packages as modules.

Answer 2

I like to have separate files for each class in my Android projects, the only exception being AsyncTasks. Having this many java files, you should have more packages than the base package. I ended up with a package for each type of main class. Each class has a name ending with its type.

com.example

Activities

Contains all the actions. All classes are called Activity at the end. This way, you can immediately find out what it is when you read Java code that does not have the full package name.

adapters

Contains all adapters.

authenticator

Contains any class associated with a user signature. I create a local account and with all the classes associated with it is very convenient.

data

Contains all classes related to data management, such as ContentProvider and SQLiteHelper.

data.migrations

Contains all my SQLite migrations. I created a class for migration, read about it here, and put them in this package.

Fragments

Contains all the fragments.

Assistants

Contains helper classes. A helper class is a place to put code that is used in more than one place. For example, I have a DateHelper. Most methods are static.

interfaces

Contains all interfaces.

Models

Contains all local models. When synchronizing with the HTTP API, I parse JSON on these Java objects using Jackson. I also pull cursor lines into these models.

preferences

Contains all classes for user settings. When creating preferences, I need a custom PreferenceDialog, as well as a custom PreferenceCategory. They live here.

synchronization

Contains all classes related to synchronization. I am using SyncAdapter to retrieve data from the HTTP API. In addition to the SyncAdapter, SyncService is required, so I created the package.