Home » Android » java – What is the best practice for putting classes under package names in Android

java – What is the best practice for putting classes under package names in Android

Posted by: admin May 14, 2020 Leave a comment

Android Studio 0.8.11


I have just completed a test on Android which was to build an app that takes a live news feed, and display them. However, the instructor was very critical as I put all my classes under one package.

I am just wondering what is the best practice for packaging classes. For my particular test I have the following classes under this package name:


My classes were these:

DBHelper          <-- database creating and ugprading
DetailActivity    <-- activity that add the NconDetailFragment
NconContract      <-- properties of the database schema columns, table name
NconDetailFragment <-- detail fragment
NconListFragment  <-- list fragment
NconViewPager  <-- just the view pager
JsonNewsFeed   <-- class that downloads and parses the json format
MainActivity   <-- Main activity
NewsFeed       <-- class of properties getters/setters for news feed
NewsFeedDB     <-- simple array list to store all the object from the sqlite3 DB
SplashActivity <-- activity that add the splashFragment and the NconListFragment
SplashFragment <-- splash fragment
Utilities <-- just some simple utility functions

Many thanks for any suggestions,

How to&Answers:

First you could separate by Model (classes holding your data) and view (everything for the display) and then you could create subpackages for different types of classes.

For Example:













You should try to minimize package dependency cycling. That means one package can depend on an other (or multiple other) package and use their classes but the required package should minimize the dependency to the first package. so the dependeny calls should only go into one direction.


Well, I use the following packages-

  1. project.activity – To put all the activities
  2. project.fragment – Fragments
  3. project.broadcastReceiver
  4. project.databaseHelpers – To put the database helper classes for handling individual tables as well as the main SqliteHelper class which is used to create all the database tables.
  5. project.networkTasks– all the calls to different APIs of different services go here.
  6. project.services – This includes the classes which are run as services. Sometimes they overlap with network tasks.
  7. project.general – This includes general classes. For example, suppose you store student data in a table. Then you can have a Student class. When you create and populate an instance of it, then you can pass the data associated with student with clarity.
  8. project.utils – This includes utility classes. These classes primarily have static methods. For example, the method to get the HttpResponse as string would be put in one of these classes.

As a general rule, what Steve said is correct, apply the principle of cohesion and coupling.


I structure my packages similarly to Simulant’s advice, I’ve found that to be the best approach to maintaining a well structured project.

However, I also create sub-packages for objects that are extending one of your own objects.
For example:


YourViewPagerFragment1 extends ViewPagerFragment
YourViewPagerFragment2 extends ViewPagerFragment
YourViewPagerFragment3 extends ViewPagerFragment

This particular approach can be very useful for navigating around your project once it gets a bit bigger, especially if you’re extending a lot of previous functionality of custom objects.


Dividing your classes into packages should be done according to the programming principles of Cohesion and Coupling.

Cohesion, simply stated, means that things that are related (or of a type) should go together. For example, your Fragments, and your Activities, as suggested by Simulant.

Coupling is how closely different things depend on one another. Wherever possible, things should be loosely coupled – where dependencies only go one way. If two modules depend on one another, we say that they are tightly coupled, and they should be part of the same package – though you may want to separate their dependencies by introducing an interface. If the dependencies are only one way (as they should be) then you can have them separated into different packages.


Try always to keep the modules loosely coupled so that it can support scalability in the future. If you put all the classes in the same package it may lead to scalability issues. Keep the fragments, activities, models everything in a different package.


Please take a look in this repository, it presents the best practices for android development, and one of these practices is the java package architecture.

In a nutshell, you can do like this:

├─ network
├─ models
├─ managers
├─ utils
├─ fragments
└─ views
   ├─ adapters
   ├─ actionbar
   ├─ widgets
   └─ notifications

Activities and fragments are not classified as views, because they are controllers, but they also handles the view, so put in their own packages.