Re: [androidbrasil-dev] Duvida sobre fragments

Matheus, uma alternativa é que vc pode deixar a parte de "setagem do adapter" a cargo do Fragment e usar a conexão da Activity com o Service apenas pra "contabilizar" a quantidade de abas/fragments que devem ser criados. Já que, como vc já viu, o Fragment é meio que "reciclado" ao invés de destruído, o número de conexões no serviço não seria problema...

Já sobre "reter as instâncias" pode ser que funcione bem, mas vc teria que testar pra saber se o código e a natureza "oculta" do RetainInstance (seja pela Activity ou pelo Fragment) é mais fácil de entender e manter do que fazer conexões distintas e isoladas com o Service.

Agora, sobre o static, eu já comentei que aquela variável RUNNING era desnecessária, já que o comportamento do Context#startService(Intent) e do Context#bindService(Intent, ServiceConnection, int) são idênticos: iniciar o serviço se ele não estiver rodando e, como vc comentou, ele é meio "singleton", além de que a documentação é clara sobre o "restart automático" que o service sofre em caso de escassez de recursos.

Toda a coisa do static é uma prática ruim, pois estamos falando de estado global, e onde todo mundo põe a mão, nada dá certo. O static é um drawback em relação à OO. OO quer dizer isolamento, herança e composição de informações/comportamentos. Quando vc apela pra estado global e compartilhado, vc está criado rotinas procedurais. Não estou jogando o static na fogueira mas, exceto em caso de uso de constantes (que sofrem um tipo de copy-n-paste na hora da compilação) e recursos extremamente custosos computacionalmente falando (onde vc pode usar outras estratégias, como cache ou factories), eu não acho que valha a pena.