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,
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.
NconContract JsonNewsFeed NewsFeed
DetailActivity MainActivity SplashActivity
NconDetailFragment NconListFragment SplashFragment
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-
- project.activity – To put all the activities
- project.fragment – Fragments
- 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.
- project.networkTasks– all the calls to different APIs of different services go here.
- project.services – This includes the classes which are run as services. Sometimes they overlap with network tasks.
- 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.
- 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.
com.viewsys.ncon.view.fragments ViewPagerFragment com.viewsys.ncon.view.fragments.viewpagerfragments 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:
com.business.project ├─ 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.