Актуален ли подход к дизайну остальных клиентских приложений в google io 2010?

два года назад появился фрагмент, служба намерений, загрузчик курсора. Актуален ли этот подход, или есть ли лучший или зрелый шаблон для разработки клиента отдыха для Android, особенно по сравнению с вариантом B (У меня нет права публиковать изображение, вместо этого изображение можно найти из этот пост).

Я знаю, что часть поставщика контента очень важна. как насчет сервисного помощника и сервисного компонента? До сих пор метод startService был свойством класса Context или его подклассов. что означает, что помощник службы будет действием. Так элегантно ли инициировать действие от поставщика контента или его следует инициировать из действия сверху.

• для тех из вас, кто копался в исходном коде приложения iosched google io 2011 , рассмотрите ли вы статический класс SyncStatusUpdaterFragment в HomeActivity в качестве помощника службы, хотя он не может запустить SyncService, но он прослушивает обратный вызов от SyncService и запускает обновление пользовательского интерфейса.Так можно ли рассматривать это как отклонение от подхода Вирджила Добьянски?

Появляются служба, служба намерений, asyncTask и поток. На мой взгляд, сервис намерений подходит для синхронизации мегапака данных с удаленного сервера. Вот почему они используют его в iosched . Но общий сценарий таков, что только часть элементов будет синхронизирована с удаленным сервером. Таким образом, служба намерений слишком тяжела. даже сервисный подход. Можем ли мы просто использовать asyncTask или поток в поставщике контента или какой-либо его компонент для выполнения такого рода задач. Или есть какая-либо убедительная причина для использования службы и прохождения пути процессора помощника службы -службы -. Я говорю о серьезном приложении.

Так что вы думаете?