Android best practices for package structure issue [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

Based on

• Android-package-structure-best-practice

• Android-Architecture

I have made the following Android package structure:

• com.company.product.activities

• com.company.product.database

• com.company.product.fragments

• com.company.product.fragments.adapters

• com.company.product.models

But at times, as per requirement I need to have an adapter for a custom dialog.

Where should I put this? Because it is a small adapter, it is mostly used within an activity in a dialog, with operations reflecting back to the activity.

Problems faced are:

1. Too much context (Activity) reference is passed to the adapter.

2. All methods end up public, which violates the OOP concept of hiding implementation details.

3. How much of a difference would it make to have a private adapter along with packaging structure? Is this the standard method for Android project package structure?

Answer 1

I would put the adapter in a adapters package. Even if it is small adapter, mostly its to be used within a activity in a dialog, with operations reflecting back to activity you will never know how that adapter is going to evolve and in what situation it is going to be used.

Regarding to your concerns:

1. Too much of context references - Each instance of your adapter will have a single Context to reference. As long as you're not leaking anything from your adapter, then this is not a problem. You may have this adapter extended by other implementations as well and that will apply to those implementation as well.
2. All methods end up public, which fails the OOP's concept of hiding implementation details. As long as you're calling adapter from your app (which should always be the case) and you're not building an SDK, then I really don't see the problem. If you're worried about OOP best practices, I would rather worry about making the adapter respect Single Responsibility Principle: don't let the adapter do more than display the given data.
3. Considering re-usability, I would rather not have adapter as a private (static or not) class member. To add more, there is a best practice that discourages usage of private access when you're dealing with calling private code from inner classes.

So to wrap-up, considering re-usability, Single Responsibility and the best practice article, I'm in favor or separating adapters to dedicated classes.