Комментарии 13
А почему вы решили использовать джаву, а не Котлин для разработки самой либы?
Ну плюсы это хорошо. А какие минусы?
Недостатки следуют из полюсов. Недавно делал доклад о библиотеке в одной из компаний. В конце обсуждений один из программистов задал вопрос: «А что мы, программисты, будем делать?». Он увидел минус в том, что при переходе на работу с библиотекой его могут сократить.
Ну а по серьезному, сечас библиотека покрывает порядка 85-90% распространенного функционала. Нужно довести этот показатель до 99%
Ну а по серьезному, сечас библиотека покрывает порядка 85-90% распространенного функционала. Нужно довести этот показатель до 99%
Решение безусловно интересное, но, увы, 85-90%, о которых Вы говорите, очень призрачны. Как и утверждение про «в 40-50 раз меньше кода». Это больше похоже на ошибку выжившего.
Всё дело в мелочах — для разных сервисов и приложений нужен разный UX, который тоже надо построить и прорабатывать. Это относится как к бизнес-логике, так и к механике интерфейса даже на типовых решениях.
Сведя всё к наборам поставляемых компонент теряется гибкость и вариативность. Для одних и тех же компонент механика может быть очень разной. Да, можно написать кастомные компоненты. А сколько их в итоге понадобится? Гибкости при этом не прибавится.
Так же есть вопросы к качеству выходного приложения. Например, как здесь работать с сменой конфигурации и восстановлением состояния?
Вы не первый, кто предлагает подобное и не только на Android. Такие решения так и не стали массово востребованными как раз по подобным причинам.
Всё дело в мелочах — для разных сервисов и приложений нужен разный UX, который тоже надо построить и прорабатывать. Это относится как к бизнес-логике, так и к механике интерфейса даже на типовых решениях.
Сведя всё к наборам поставляемых компонент теряется гибкость и вариативность. Для одних и тех же компонент механика может быть очень разной. Да, можно написать кастомные компоненты. А сколько их в итоге понадобится? Гибкости при этом не прибавится.
Так же есть вопросы к качеству выходного приложения. Например, как здесь работать с сменой конфигурации и восстановлением состояния?
Вы не первый, кто предлагает подобное и не только на Android. Такие решения так и не стали массово востребованными как раз по подобным причинам.
«А что мы, программисты, будем делать?». Он увидел минус в том, что при переходе на работу с библиотекой его могут сократить.Если и сократят — значит он и раньше не был нужен. По-настоящему же стоит вопрос о востребованности DePro.
85-90% не совсем призрачны. Эти цифры получены при разработке реальных коммерческих приложений. И они показывают сколько функционала, в процентном отношении, приходится на кастомные элементы. Относительно «в 40-50 раз меньше кода» пару проектов разрабатывались, как по традиционной технологии, так и с применением библиотеки. После чего путем деления общего SLOC по первому и второму варианту.
Библиотека позволяет: подключать кастомные активити и фрагменты, в том числе и с компонентами библиотеки, подключать кастомный код к описанию экранов. Также имеется возможность разрабатывать кастомные компоненты и подключать их проекту с возможностью использования этих компонентов в следующих проектах.
Библиотека позволяет: подключать кастомные активити и фрагменты, в том числе и с компонентами библиотеки, подключать кастомный код к описанию экранов. Также имеется возможность разрабатывать кастомные компоненты и подключать их проекту с возможностью использования этих компонентов в следующих проектах.
Сколько этих приложений? Просто, чтобы работать с таким, заказчик либо должен быть совсем нетребовательным, либо Вам придется подгонять компоненты или саму DePro под него. С этой стороны 85-90% уже крайне преувеличенная цифра. Вы просто судите только по той массе проектов, что прошли через Вас.
Если Ваш компонент покрывает группу View, то, если его механика хоть немного не совпадает с ТЗ — придется писать кастом. Примеров масса — списки с несколькими типами ячеек, пагинация через paging library, интерактивные списки (не только кнопочки), биллинг с библиотеками провайдеров. Список может быть большим, я только привел самое часто востребованное.
Если предлагаете покрывать каждую View компонентом — то это ничем не лучше слегка продвинутой вариации Data Binding, а современная MVVM на AAC будет гораздо компактнее и гибче (если знать как писать).
Если Ваш компонент покрывает группу View, то, если его механика хоть немного не совпадает с ТЗ — придется писать кастом. Примеров масса — списки с несколькими типами ячеек, пагинация через paging library, интерактивные списки (не только кнопочки), биллинг с библиотеками провайдеров. Список может быть большим, я только привел самое часто востребованное.
Если предлагаете покрывать каждую View компонентом — то это ничем не лучше слегка продвинутой вариации Data Binding, а современная MVVM на AAC будет гораздо компактнее и гибче (если знать как писать).
Чем это лучше какого-нибудь Litho?
У них разные предназначения. Такие инструменты как Litho, Flutter, Jetpack Compose предназначены для декларативного описания интерфейса UI (ресурсов, XML файлов). Логика пишется на императивном языке программирования, например: Java, Kotlin. DePro ориентировано на программирование именно логики. В статье указано, что ресурсы формируются обычным способом.
Выглядит очень убедительно. По опыту знаю что такие кардинальные идеи могут встретить сопротивление у разработчиков. Но в конце концов для того и существует бизнес, CEO, PM, чтобы продвигать перспективные продукты, вопреки, иногда, мнению большинства, которое, как известно, не всегда бывает право.
Вот как раз у бизнеса подобные решения не востребованы. Это не кардинально новая идея и ей не один год. Более того, существуют e-commerce платформы, которые нативные, гибкие и код практически писать не надо. Очередей за ними не видно.
Одно дело упрощать разработку, другое- уменьшать гибкость, вариативность и ухудшать UX.
Решение, конечно, само по себе интересное. Оно пойдет для того, чтобы пощупать рынок с технически несложной идеей. Только зачем, когда для этого есть Flutter и Reасt Native?
Одно дело упрощать разработку, другое- уменьшать гибкость, вариативность и ухудшать UX.
Решение, конечно, само по себе интересное. Оно пойдет для того, чтобы пощупать рынок с технически несложной идеей. Только зачем, когда для этого есть Flutter и Reасt Native?
C react-native + expo я работал. У них немного другая фишка это кросс-платформенность. Если брать по времени разработки то это будет не минус а плюс 30% к разработке натива. Да, натив будет единый на iOS + Android, то есть фактически сотношение вроде бы в пользу react-native 100% + 100% соотносится к 100% + 30%. Но это если нужно сделать что-то что по функциональности похожее на обычное веб-приложение. Если нужно что-то более нативное, например пуши или работу с гео-координатами — тут или уже есть готовый компонент, если повезет, либо на интеграцию нужно затратить уже время на порядок более высокое, которое съест всю экономию.
По поводу RN полностью согласен. Потому и написал про технически несложную идею. Но, в случае DePro, всё так же может упереться в наличие подходящего компонента. В обоих случаях его разработать относительно не сложно, но проблема одного порядка — нехватка гибкости и вариативности. При том, что RN работает на 2х платформах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Декларативное программирование клиент-серверных приложений на андроид