2

I started creating a library that will be shared with several projects.

The problem is that the Android documentation is really short about how to handle properly the library projects. I got really stuck dealing with the conflicts between the few classes I have in common in both the main projects and the library project.

I checked the sample from Android (Tic Tac Toe) but it is really too basic to help, but I just remarked that they used the following packages:

  • The main project: com.example.android.tictactoe
  • The library project: com.example.android.tictactoe.library

Is the library supposed to be always contained in the main project package? If yes, how to do when several projects have to share the same library project since the main package name belongs to one main project only?

My biggest problem right now is that my app is calling a class from the library project instead of the main project, and I have really no idea what is the best approach to follow.

Thanks!

Update: My question is related to this one: Best practice: Extending or overriding an Android library project class

Community
  • 1
  • 1
Yoann Hercouet
  • 17,894
  • 5
  • 58
  • 85
  • 1
    You can have different package structure of library project. There no dependency with project structure or package name. But your current problem seems "You have imported wrong class, check import statement" – Pankaj Kumar Feb 20 '14 at 08:29
  • No the problem is that my library project uses a class that is both defined in the library and in the main project. I cannot change the import statements in the library to call the one in the main project. – Yoann Hercouet Feb 20 '14 at 08:31
  • Your statement is more confusing. What is path of that class? – Pankaj Kumar Feb 20 '14 at 08:33
  • In my main project: com.example.newproject.Parameters In my library project: com.example.commonproject.Parameters – Yoann Hercouet Feb 20 '14 at 08:37
  • So why not you use class with relative path? Like `com.example.newproject.Parameters object = new com.example.newproject.Parameters()' or `com.example.commonproject.Parameters object2 = new com.example.commonproject.Parameters()`. – Pankaj Kumar Feb 20 '14 at 08:40
  • Just for clarity: are you trying to have a project "replace" the classes in another? If so, are you trying to have the main project replace library classes or the other way around? – lucian.pantelimon Feb 20 '14 at 09:13
  • I think I might need an interface as you suggested, I will reply to your answer – Yoann Hercouet Feb 20 '14 at 09:35

2 Answers2

2

There are lots of 3rd party libraries available (such as Action Bar Sherlock) and they do not share the same package as yours.

Alexander Kulyakhtin
  • 47,782
  • 38
  • 107
  • 158
  • But is it still true when some classes are in common? When some classes from the main project must override the ones from the library project? – Yoann Hercouet Feb 20 '14 at 08:44
  • I have never tried that. I think there is no reason to have common classes between a project and a library. – Alexander Kulyakhtin Feb 20 '14 at 09:53
  • The thing is that the class from the main projects (3 different ones) is needed in the library, but I don't see how to link it to this library. Removing the class itself from the library will of course throw lots of errors. – Yoann Hercouet Feb 20 '14 at 10:05
  • I really don't know. I believe a library, being a library, should not require any artifacts from its client. If it does, it's not a library. – Alexander Kulyakhtin Feb 20 '14 at 10:23
  • Yes maybe you are right, if no other choice I will reorganize my classes and split them if necessary. Thanks anyway! – Yoann Hercouet Feb 20 '14 at 10:34
1

The packages for the library project and the main app project have no requirement of being related in any way.

In some cases it does help having the library as a sub-package of your main app package: this comes from the way you split the project and if the package for your library being a sub-package would help with organising the code, by all means make it a sub-package of your main package; otherwise, don't. It's all about structuring the code in the end.

It is ok for your app to call (actually use would be the work) classes from your library project. That's what libraries are for. They help keep code contained, reusable and decoupled from other pieces of code.

The problem is the other way around: when your library is calling a class from your main project.

The most common approach for Java and Android here is to use an interface: the library provides the interface that the main project implements, then the main project passes an instance of that implemented interface for the library project to use. The best example here would be callbacks. Android provides a set of interfaces (such as View.OnClickListener) that allow you to hook into the system and perform your application's logic (from the application's point of view, the Android classes in the SDK are the libraries).

Other approaches would be providing classes to be extended (this is just like providing interfaces, but it's used when you want to either leave the library user the option of not implementing/overriding all the methods or when you want to keep some base functionality in the object you will be receiving in your library through the use of the final modifier) and reflection (stay away from it as long as possible as it is very error-prone).

lucian.pantelimon
  • 3,673
  • 4
  • 29
  • 46
  • Thanks for the answer, it seems to be what also recommended Commonsware on this one: http://stackoverflow.com/questions/3890948/how-can-a-code-in-a-library-project-call-code-in-the-application-project. – Yoann Hercouet Feb 20 '14 at 09:37
  • By any chance, do you have an example of this interface? – Yoann Hercouet Feb 20 '14 at 09:37
  • What interface? `View.OnClickListener` is documented here http://developer.android.com/reference/android/view/View.OnClickListener.html and you can also find the source code online, but I think that this hardly suits your needs as your interface would most likely have other requirements. – lucian.pantelimon Feb 20 '14 at 09:42