Повторная обработка событий, полученных из Kafka

1. Если остановить listener container не происходит ребалансировка consumer group?
2. Насколько долго выполняется обработка сообщения? Если делать комит offset после обработки сообщения и добавить сюда spring retry то можно выскочить за timeout обработки сообщения.
3. И еще всегда хотел спросить — какое количество партишенов для топика считается нормальным?
   Я понимаю что все зависит от размера кластера, но может есть какие-то рекомендации.

Spring bean custom scope

Так же как и для request scope бинов

Scope(value = "custom", proxyMode = ScopedProxyMode.TARGET_CLASS)

Spring bean custom scope

Что бы это все работало надо указать
proxyMode = ScopedProxyMode.TARGET_CLASS
Это необходимо что бы создавался прокси вокруг бина, и этот прокси уже будет получать инстанс бина из scope

Альтернативная версия упаковки Java приложения в Docker

в свое время юзал вот этот очень удобный плагин от sptofy — https://github.com/spotify/docker-maven-plugin

Droidutils — набор решений, которые ускоряют разработку приложений под Android

A Retrofit и GSON вам не нравятся?
а для асинхронности есть groundy

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

теперь понимаю задачу, из DI юзал только android annotation. так что не могу сказать как там с dagger быть.

для остального я пока вижу только один выход: синглтоны и фабрики

для всего остального есть Parcelable and Serializable.

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

а зачем «получить прямую ссылку на созданный GroundyTask»? если хотите отменить таск — то надо TaskHandler который получаете после вызова queueUsing.

я обычно в каждом таске пишу статический метод запуска

public static TaskHandler start(Context context, BaseFindPrinterCallback callback) {
    return Groundy.create(FindPrinterCommand.class).callback(callback).queueUsing(context);
} 

и да, я обычно пишу базовый класс калбека для команды типа

public static abstract class BaseFindPrinterCallback {

        @OnSuccess(FindPrinterCommand.class)
        public void onSuccess() {
            onSearchFinished();
        }

        @OnCallback(value = FindPrinterCommand.class, name = CALLBACK_ADD_PRINTER)
        public void onAddPrinter(@Param(EXTRA_PRINTER) PrinterInfo printerInfo) {
            handleAddPrinter(printerInfo);
        }

        protected abstract void onSearchFinished();

        protected abstract void handleAddPrinter(PrinterInfo printerInfo);
    }

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

А вы можете предсказать сколько займет запись файла?

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

А не сравнивали retrofit и android annotations в части работы с REST? Сам android annotations для этого не пользовал, интересно услышать впечатления.

rest из android annotations — это набор аннотаций и обвертка для работы с spring android. его тоже надо будет затянуть с собой

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

ну cursor window не должен расти, может вы не закрываете курсоры? или вылазит просто при пролистовании списка?

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

пруф в студию плиз.
вот тут — SQLiteCursor четко видно, что юзаеются окошки. посмотрите на метод move например

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

Но а что если вам нужно получить какие-то данные, на основе них что-то записать в БД и, например, записать что-нибудь в файлик?

я всегда юзаю сервис

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

заглянул в ProviGen — чего там кода меньше? все также описываете контракт, uri, столбцы
а у меня еще и вьюхи можно достаточно легко писать

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

Надо пробовать, смотреть. Вот вам и джава — есть море вариантов делать одно и тоже и никто не скажет какой самый хороший.
Надо попробовать и сравнить. просто такие эксперименты делать на продакшен проекте не будешь. надо сначала на мелком прожекте. где цена ошибки не велика.

да и привычка — очень странная вещь.

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

я с опаской отношусь к ORM. главная проблема с ними — вытаскивание огромного количества данных в память. вот и все.
курсор хорош тем — что он держит cursor window на базу. и не засоряет память. а когда вы двигаетесь по списку вверх/вниз — он двигает окно.

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

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

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

как по мне, идея тредов которые захватывают UI контекст — не айс. потом могут быть мемори лики например

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

для загрузки картинок патались юзать picasso

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

Ну ретрофит да — но она менее удобная. но она не может заменить сервис.

Еще раз об архитектуре Android приложения или джентльменский набор библиотек

ну насколько я понимаю она частично работает на рефлекшене.
+ просто руки еще не дошли, попробовали пока такую связку. под «попробовали» я имею ввиду нормальный продакшен проект.
как только поюзаю ее — постараюсь написать и о ней.