Во-первых, это зависит от того, какое приложение вы делаете.
Вы должны сделать текстовое или схематическое описание того, как пользователь будет работать с приложением. Зафиксируйте каждый возможный сценарий. Запишите примеры, которые будут использованы позже для тестов.
Решите, что относится к функциональности, а что - к изменяемой конфигурации. Извлечение функций и объектов данных из сценариев.
Исходя из сценариев, примите решение, каким будет ваше приложение. Это сервис, активность, виджет, даже поставщик контента или сложная система, включающая в себя несколько разных компонентов. Проверьте свое решение против сценариев.
В случае сложной системы распределите функциональные возможности и объекты данных между компонентами приложения. Составьте список компонентов и их компонентов (действия или что-то еще).
Составьте список компонентов пользовательского интерфейса с описанием того, что они делают (пока НЕ КАК). Это будут виджеты и действия или фрагменты или макеты позже.
Сделайте черновые макеты для компонентов пользовательского интерфейса. Делайте простые переходы от одного к другому. Посмотрите на интерфейс. Вернитесь к сценариям и воспроизведите их все с помощью своего чернового интерфейса. Все компоненты и классы пользовательского интерфейса объединены в одну иерархию пакетов или пакетов.
Составьте список объектов данных. Решите, что будет в чем. Планируйте их как коллекции или таблицы в БД или разных БД. Сделайте их как классы, поместите их в другую иерархию пакетов или другой пакет. Сюда же помещаются помощники БД - классы, которые общаются с БД по SQL
Создайте тестовые классы (JUNIT или лучше TestNG) для заполнения пользовательского интерфейса и объектов данных тестовыми данными и их запуска.
Адаптеры не должны быть общедоступными, поскольку они используются только в родительском GroupView. Итак, обычно нет файлов для адаптеров.
Вы не класть все глобал в специальные классы статических - это плохая практика. Вы смешиваете так код и конфигурацию. Используйте это очень интересное решение . На данный момент это лучшее, что я знаю для Android.
Данные конфигурации должны быть помещены в ресурсы. Если некоторые из них являются сложными, используйте источники XML и анализаторы. Преобразуйте данные ресурсов в глобальные переменные. Не все из них будут статичными! Например, они могут принадлежать к основному экземпляру Activity.
Не используйте ненастраиваемые константы в коде! Может быть, только ваше имя :-). Каждая константа иногда становится непостоянной.
С другой стороны, если какой-то из вас код не является обычным Java, а сценарии - смесь данных и языка, то вы можете и должны смешивать данные и код.
Всегда делайте так: напишите что-нибудь - подключите что-то к группе - добавьте тест (ы) для этой новой вещи - протестируйте эту новую - протестируйте основную часть - повторите. Только маленькие шаги!
Редактировать. Вы также можете использовать тестовую разработку - писать тесты перед соответствующим кодом. Таким образом, выполняя тесты до того, как код будет готов, вы проводите двойное тестирование - таким образом вы проверяете, действительно ли тесты реагируют на некорректный код.