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

Собственные решения для разработчика развивать и разрабатывать оказалось крайне удобно. Архитектура библиотеки и ее фичи разрабатывались под конкретные задачи в проектах. И особенный случай в проекте, заставил переосмыслить всем привычные квалификаторы для DI, и добавить что-то новое.

Случай, кстати, оказался не новый, и автор много его встречал в различных проектах. Так что, думаю для многих из читателей такой пример покажется до боли знакомым.

Нелегко на рынке найти senior разработчика для конкретной сферы. Каждый из них имеет уникальные знания в своем языке и фреймворке, будь это Java, Kotlin, С++, JS или Swift. Каждый накапливал свои знания годами. Но найти senior разработчика, который одинаково хорош и C++ и в Kotlin, утром переписывает openssl, а по вечерам пинает мидлов за неправильное использование корутин, почти нереально.

Для каждого проекта нужны высококлассные специалисты, поддерживающие проект на плаву, развивающие его, предоставляя клиенту новые фичи, а заказчику - большие деньги. Уход каждого специалиста для компании приносит новые убытки, но вот уход ndk специалиста может привести проект к краху. Ладно, не все так драматично. Если у вас все под контролем.

Поздравляю, вы прошли испытательных срок, показав себя на задачках сложных и не очень. Тимлиду вы успешно обосновали неоходимость использовать DI без скоупов. А значит наступило время подойди к фреймворку и изучить его инструментарий и работу основательнее.

Библиотеке исполнился 1.0.3 релиз. Испытав себя на более тысячи тестах, он чувствует себя более чем стабильно. Однако библиотеке присущ особый характер работы. Будучи созданным разработчиком в одиночку, вы можете встретить нестандартные взгляды на архитектуру. Автору предстоит непростая задача — раскрыть особенности работы библиотеки.

Вы когда нибудь задумывались, на сколько grpc быстрый. Да в сети, ему равных нет. Если вы гоняете маленькие сообщения, которые надо быстро доставить, то лучше grpc попросту не найти ( найти, но по мнению автору protobuf остается движком сериализации, поддерживающим большее кол-во языков ). Но насколько он хорош? Сможет ли он к примеру сравнится просто с нативными вызовами?

Попробуем сравнить это, но так как в обычной жизни нам это может не пригодится, то добавим еще одно условие - сравниваем как лучший способ взаимодействия с jni библиотекой.

Ваш первый день на работе. Вчера вы рассказывали про чистую архитектуру, SOLID принципы, и про то, как создавать аккуратную и масштабируемую архитектуру.

Сегодня нужно написать простенький экран, который будет отображать список. Вы с огромным энтузиазмом начинаете реализовывать прекрасный список - каталог товаров магазина. Один запрос, один список. Все сделали красиво, фрагмент создался, подтянул из DI ViewModel, которая в свою очередь передала остальным слоям, чтоб загрузить данные по АПИ и закешировать их. Все эти компоненты правильно освобождаются, так как все это сделано как надо отдельным Субкомпонентом с отдельным скоупом.

Следующий день, оказалось, что к списку нужно добавить расценки, однако их можно загружать только отдельным запросом. Этот запрос оказался тяжелым на сервере, так что каждый ответ может приходить дольше чем обычно, и сам запрос ко всему списку разбит на несколько подзапросов. При отправке запроса клиент должен выслать список наиболее просматриваемых товаров пользователем. Бэк при этом очень попросил лишний раз запросы не делать, так как сервер и так не справляется.

В одночасье, мы понимаем, что наша шаблонная архитектура превращается из легкой и понятной в сложную и нечитабельную. А все потому, что нам нужно прежде всего обеспечить жизненный цикл компонентов достаточно большим, чтобы эти компоненты успели: собрать информацию для запроса, выполнить долгие запросы, а может быть и несколько за раз, при страничной загрузке, сохранить ответы сервера и закешировать их, также сформировать один общий список товаров с 2 разных запросов и, наконец, выполнить фильтрацию и сортировку конечного списка.