Refactoring

Some suggestions:

• Class AppDetails is really long because it has two fragment classes in the same file. Those should be moved to seperate files.
• Activity names should always end with Activity (see FDroid and SearchResults).
• All the classes directly in org.fdroid.fdroid should be moved into appropriate packages (except maybe FDroidApp).

I would make a merge request for those myself, but seeing as refactoring really sucks to review, it might be better if this is done by the project maintainers.

+1 for points on and three.

But for point two, I would rather put them in a directory called activities than calling them Activity.

For the activities, i would do both: put them in an .activities package and name them *Activity. That makes it organized and easy to see what you're working on.

Point one is obvious. It has been building up over time.

I'm not sure about point two, I won't stand in the way if everyone else is in favour. But I think it's a tad too verbose. We don't call every interface *Interface. If two things - e.g. a regular class and an activity - have the same name, then let's just call them something different. Like Permissions and PermissionsActivity.

Agreed on point three, don't see why not. Like code styles, better some package structure than none at all.

The official Android style is to name Activity subclasses something ending in Activity. I think that's good style. packages are often used to put similar classes types into "boxes". Java packages are intended to provide code separation, not subclass type sorting. For example, the difference between private void foo() and void foo() is that anything in the same package can call void foo().

So really packages should be used for collecting classes that are related to a topic, not based on what they are subclassing (e.g. Activity). Some good examples of that are org.fdroid.fdroid.net and org.fdroid.fdroid.installer.

Milestone changed to 1.0

@eighthave has a very good point on not grouping all the activities in a single package.

As for AppDetails, we want to get rid of fragments ASAP (see all the NPE fixes and work-arounds we've had to do to avoid crashes), so I would not do that bit of refactoring.