CODEWITHSUNDEEP
androidandroid-activitypackage
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

Reputation: 5759

Android separate packages

I have a large UI (about 20-25 screens). How should I organize my code? Should I separate by functionality into different packages? Should I have one package for all UI classes and then create sub packages to organize? Or should I not create separate packages and organize into folders. Any help would be greatly appreciated.

Upvotes: 3

Views: 2657

Answers (2)

Kaloyan Roussev
Kaloyan Roussev

Reputation: 14711

I've tried to separate my classes in logical packages as much as possible.

  • activities
  • adapters (adapters for listviews mostly)
  • asynctasks (communication with the server for the most part)
  • core (contains a constants class and the base activity that holds the global vairables, as well as the sliding menu and action bar)
  • fragments
  • interfaces (mostly listener/observer pattern interfaces, used to notify for success/failure of an asynctask or database operation)
  • localsqlitedb (contains the sqlqueries class, the database helper class and other db-related classes)
  • objects - contains plain old java objects (pojos) representing different entities from my app (a user, a user's item, a category)
  • utilities - images handling, email senders, custom toast makers and so on

I think its easy to maintain and reuse code organized this way

I also use naming conventions so I know what a class or a file is about at a glance

in the layouts folder:

activity_login.xml
activity_register.xml
dialog_delete_profile_confirmation.xml

in the drawable folder:

icon_feed.xml
icon_search.xml
images_loading_splash_screen.png
images_default_avatar.png

in the asynctasks package

GetUserDataFromServerAsync.class
RegisterUserAsync.class

(so that when I refer these in the code I know its not the internal handler class, but the class that communicates with the server)

Upvotes: 1

Vicente Plata
Vicente Plata

Reputation: 3380

When you create a folder, it becomes a package. My favourite structure for large projects is as follows:

  • UI
  • Core / Logic
  • DAO / Connections
  • Utils
  • Models / TOs / VOs

Hope this helps.

Upvotes: 8

Related Questions