3

I have several applications that differ mostly based on resources. As of now, I'm copying the code around to each application. This can be problematic. An example, fixing a bug in one, and forgetting to update to the others.

I don't think creating a JAR is appropriate for this situation, as these are application specific UI classes, (actually android activity classes in specific) including the actual app start-up code.

It may be possible to include these source files into several packages, but then I have the problem that each file specifies a specific package name on the first line.

Most of the code is related to the UI and Activity processing. (The actual common code is already in a library). A similar question is posted here. Are there any elegant solutions to this situation?

Community
  • 1
  • 1
James John McGuire 'Jahmic'
  • 11,728
  • 11
  • 67
  • 78

3 Answers3

6

A jar is absolutely appropriate for this situation. You should split your application into layers, separating the application-specific classes from the shared code.

artbristol
  • 32,010
  • 5
  • 70
  • 103
  • I should have qualified that all utility code is already in a library. The issue is with all UI-specific (android activities), especially the main start-up one. These are the bulk of the code and are referenced in the android manifest. I'll look into adding these into a jar and find a way to keep the manifest happy. – James John McGuire 'Jahmic' Jun 06 '11 at 04:39
2

I solved this by going with Android Library projects. (Not sure of the details, perhaps they are ultimately jars) Check out details here, specifically the section 'Setting up a Library Project'. I basically put in all my activity classes (except for the start-up one) into the library.

For true non-UI bound code, JARs, do seem to be the way to go.

James John McGuire 'Jahmic'
  • 11,728
  • 11
  • 67
  • 78
1

I agree with artbristol.

I also recommend to use Maven and:

  • release the common jars to a corporate Maven repository
  • declare a dependency with specific versions on these jar artifacts

Like this you don't break applications if you do some incompatible changes.

Puce
  • 37,247
  • 13
  • 80
  • 152