Новый проект.

[Озорная Свинья]

Проектирую новое приложение, которое впоследствии станет мировым лидером среди ПО для Андроида.
На этапе проектирования возникаю вопросы, в приложении будет использоваться Splash-активити индикатор подключения, который в свою очереьд должен запустить сервис с подключением к серверу.
Я так понял что этот Splash-активити, должен быть описан в манифесте, как: "android.intent.category.LAUNCHER", а главный активити, как: "android.intent.category.DEFAULT" или же это всё не обязательно?
Стоит ли создавать отдельные файлы с дополнительными классами или же постараться этого избежать? Какие способы взаимодействия между ними, тоесть видна ли public переменная или метод одного класса из другого?

[rezak90]

которое впоследствии станет мировым лидером среди ПО для Андроида.

Стоит ли создавать отдельные файлы с дополнительными классами или же постараться этого избежать?

А что лучше всё в один файл? Соблюдайте красоту.

[Озорная Свинья]

Да я что-то не увидел красоты во взаимодействии между классами в Java, То что предлагает Андроид СДК, вообще мне кажется какими то дикими методами, хотя хз, мож я что то не допонял((

[rezak90]

Значит Вы не доконца понимает принципы ООП раз не видите взаимодействия между калссами.

[neoksi]

Да я что-то не увидел красоты во взаимодействии между классами в Java, То что предлагает Андроид СДК, вообще мне кажется какими то дикими методами, хотя хз, мож я что то не допонял((

Это приходит со временем, вначале голову ломаешь, но потом, как поймешь и научишься абстрагироваться, то все становится прекрасно.

[Foenix]

Значит Вы не доконца понимает принципы ООП раз не видите взаимодействия между калссами.

Проектирую новое приложение, которое впоследствии станет мировым лидером среди ПО для Андроида.
На этапе проектирования возникаю вопросы, в приложении будет использоваться Splash-активити индикатор подключения, который в свою очереьд должен запустить сервис с подключением к серверу.

Круто, уселась, жду продолжения.

Значит Вы не доконца понимает принципы ООП раз не видите взаимодействия между калссами.

А там интуитивно все

[rezak90]

интуитивно становится тогда когда на руках уже десятки тысяч программных дорожек

[Foenix]

интуитивно становится тогда когда на руках уже десятки тысяч программных дорожек

ну не знаю, ТС так сам сказал))

[Mikhail_dev]

Стоит ли создавать отдельные файлы с дополнительными классами или же постараться этого избежать?

Старайся делить на сущности. На что-то, что делает этот предмет логическим в цепочке. Вот сервис к примеру и активность, это разные сущности. Например машины и мотоциклы. Пакет к примеру будет один, а класса два. Или же класс один, а сабкласса два от него.
Но не всегда это прокатывает. Иногда получается так, что код вырастает выше чем в 1500 строк в одном классе. И что-то поделить сложно. К примеру у нас код сервиса разросся до тысяч 5000 строк кода. Пришлось делить по классам так:
1. Сервис
2. обработка GPS данных
3. общение с сервером один класс
4. общение с сервером второй класс
5. работа с базой данных
6. работа с фотографиями
7. Логгер
8. Класс Settings, в котором хранятся статические константы, можно запросить различные пути к нужным дирректориям и всё в таком духе
9. Класс загрузчик при старте телефона
10. ... сущности. К примеру есть объект чекпойнт. Он отдельная сущность. Он вынесен в отдельный класс. Есть маршрут. он тоже отдельная сущность. Он вынесен тоже в отдельный класс.
Это пакет сервиса, он не содержит работы с UI интерфейсом и всем таким. Вот такое вот деление происходит. Некоторые классы могут быть очень маленькими, некоторые очень большими. Но стиль программирования (общепризнанный) обычно говорит, что длина строки не более 80 символов, кол-во строк метода не более 20, размер класса не более 1000 строк. Тут вам в помощь книги для понимания как правильно писать код.

Какие способы взаимодействия между ними, тоесть видна ли public переменная или метод одного класса из другого?

Все переменные приватные. доступ только по get. статические константы можно использовать с public видимостью.