А что входит в компонент по-умолчанию? Может привести несколько примеров реальных из проекта?
Например, ваш H1/H2/H3 Component. В нём определяются только размеры текста?
А например цвет куда? Или цвет это уже внешняя стилизация компонента?
Было бы здорово описать минусы тех. решений о которых вы говорите "дебри". Возможно у тех решений есть плюсы, которых нет у вас. И на долгой дистанции(или большого проекта) ваше решение не будет работать.
Лично для меня пока из существующих решений для среднего проекта мне подошёл MvRx от AirBnb.
Во-первых они построили его на существующих элементах(Fragment, ViewModel). Во-вторых всю работу со Store/Reducer скрыли с глаз долой.
Да тоже подумал о курсоре. То что из коробки не получится использовать. Только самим реализовывать логику.
А как у вас сейчас производительностью с разными размерами файлов? 5000 строк, 15000 строк?
А не получилось бы здесь использовать RecyclerView? Т.е. для каждого элемента списка свой маленький EditText.
Я применял такой способ просто для отображения огромных файлов без редактирования, ну и они были без стилизации. Всё вроде работало прекрасно без тормозов, по крайней мере скролл.
А как решать проблему с анимациями между компонентами? Например, есть экран на котором есть несколько компонент взаимодействия с которым приводят к анимациям с изменением вёрстки(смещения, расскрытия, сдвиги и т.д). Как применять server driven UI в таких случаях? Уже нельзя просто взять и убрать/добавить компонент из ответа сервера. Анимация сломается.
Скучаю по временам, когда люди не хотели войти в айти, а просто становились разработчиками. Когда это не было распиарино и когда из каждого утюга не вещали про курсы "middle за 3 месяца".
Не очень понял в чём преимущество создания своих кастомных компонент над уже стандартными. В этом примере вы меняется дефолтный стиль.
Но разве мы не можем в темах и сейчас поменять стиль стандартных компонент без необходимости наследоваться? Всякие buttonStyle, materialButtonStyle, toolbarStyle и прочие аттрибуты..
Полосы — это разные соотношения видео и экрана. Возможно окко по-умолчанию делают масштабирование на весь экран. Полос вы не видите, но и часть изображения может обрезаться.
А как бы стали делать автоматическое обнаружение других "ваших" телефонов внутри локальной сети без необходимости в коде и ручками вбивать IP?
Я у себя в похожей задаче сделал простой протокол обнаружения поверх udp multicast/broadcast. Но может есть какие-то решения из коробки вообще без костылей?
Я бы не стал говорить, что всё прям ужасно. Если у вас на одном экране пара фрагментов и нужно взаимодействие, и именно эта комбинация этих фрагментов только один раз встречается в приложении, то зачем придумывать себе проблему и потом же решать её? Я понимаю, что это может ухудшать переиспользуемость, но что если она и не нужна в конкретном месте..
А почему в мобилках не используется подход один на всё, а чаше разделяют по экранам?
Я просто не знаю веб, и интересно почему там это ок, а у нас в мобилках не ок..
Ещё несколько вопросов:
1) Что делает блок Business logic внутри компонента? Только преобразуется state в business object? Что если объединить его с ViewModel и сразу делать state->viewobject?
2) Представим ситуацию. У вас на экране два компонента. В одном чекбокс, а в другом кнопка. По чекбоксу надо делать enable/disable кнопки. Как будет выглядеть путь? Пройдёт ли он через всё, или это сразу будет выполнено во view слое?
В зависимости от подхода, Middleware и Reducer может быть один на весь экран или даже приложение, или же каждая бизнес сущность будет иметь свой Middleware и Reducer
А вот можно поподробнее про "один на всё приложение"? Насколько это подходит для мобильных приложений на ваш взгляд? Есть ли примеры таких приложений?(Только больших, а не с 2-3 экранами).
В свою очередь я подумал, что, если то же количество усилий, которое требуется для прокачки хард-скиллов для перехода из middle в senior-разработчика, вложить в развитие софт-скиллов, продвижение по карьерной лестнице может быть даже более эффективным
Т.е. с точки зрения навыков программиста(математика, структуры данных, алгоритмы, архитектуры, написание кода) вы остались на уровне middle?)
Ну прям rocket science:)… чтобы сбросить вес надо меньше лопать сахар и булки.
А что входит в компонент по-умолчанию? Может привести несколько примеров реальных из проекта?
Например, ваш H1/H2/H3 Component. В нём определяются только размеры текста?
А например цвет куда? Или цвет это уже внешняя стилизация компонента?
Было бы здорово описать минусы тех. решений о которых вы говорите "дебри". Возможно у тех решений есть плюсы, которых нет у вас. И на долгой дистанции(или большого проекта) ваше решение не будет работать.
Лично для меня пока из существующих решений для среднего проекта мне подошёл MvRx от AirBnb.
Во-первых они построили его на существующих элементах(Fragment, ViewModel). Во-вторых всю работу со Store/Reducer скрыли с глаз долой.
Да тоже подумал о курсоре. То что из коробки не получится использовать. Только самим реализовывать логику.
А как у вас сейчас производительностью с разными размерами файлов? 5000 строк, 15000 строк?
А не получилось бы здесь использовать RecyclerView? Т.е. для каждого элемента списка свой маленький EditText.
Я применял такой способ просто для отображения огромных файлов без редактирования, ну и они были без стилизации. Всё вроде работало прекрасно без тормозов, по крайней мере скролл.
А как решать проблему с анимациями между компонентами? Например, есть экран на котором есть несколько компонент взаимодействия с которым приводят к анимациям с изменением вёрстки(смещения, расскрытия, сдвиги и т.д). Как применять server driven UI в таких случаях? Уже нельзя просто взять и убрать/добавить компонент из ответа сервера. Анимация сломается.
Вроде первоначальный вариант был прекрасен. Зачем вы всё испортили и обмазали всё паттерном?)
Скучаю по временам, когда люди не хотели войти в айти, а просто становились разработчиками. Когда это не было распиарино и когда из каждого утюга не вещали про курсы "middle за 3 месяца".
Поработать бесплатно или за еду?) Вот вам и опыт..
Не очень понял в чём преимущество создания своих кастомных компонент над уже стандартными. В этом примере вы меняется дефолтный стиль.
Но разве мы не можем в темах и сейчас поменять стиль стандартных компонент без необходимости наследоваться? Всякие buttonStyle, materialButtonStyle, toolbarStyle и прочие аттрибуты..
Полосы — это разные соотношения видео и экрана. Возможно окко по-умолчанию делают масштабирование на весь экран. Полос вы не видите, но и часть изображения может обрезаться.
Немного вопрос не по теме, а по:
А как бы стали делать автоматическое обнаружение других "ваших" телефонов внутри локальной сети без необходимости в коде и ручками вбивать IP?
Я у себя в похожей задаче сделал простой протокол обнаружения поверх udp multicast/broadcast. Но может есть какие-то решения из коробки вообще без костылей?
Хмм, спасибо за статью. Подумаю стоит ли теперь даже пробовать попасть в Яндекс..
Я бы не стал говорить, что всё прям ужасно. Если у вас на одном экране пара фрагментов и нужно взаимодействие, и именно эта комбинация этих фрагментов только один раз встречается в приложении, то зачем придумывать себе проблему и потом же решать её? Я понимаю, что это может ухудшать переиспользуемость, но что если она и не нужна в конкретном месте..
А почему в мобилках не используется подход один на всё, а чаше разделяют по экранам?
Я просто не знаю веб, и интересно почему там это ок, а у нас в мобилках не ок..
Ещё несколько вопросов:
1) Что делает блок Business logic внутри компонента? Только преобразуется state в business object? Что если объединить его с ViewModel и сразу делать state->viewobject?
2) Представим ситуацию. У вас на экране два компонента. В одном чекбокс, а в другом кнопка. По чекбоксу надо делать enable/disable кнопки. Как будет выглядеть путь? Пройдёт ли он через всё, или это сразу будет выполнено во view слое?
А вот можно поподробнее про "один на всё приложение"? Насколько это подходит для мобильных приложений на ваш взгляд? Есть ли примеры таких приложений?(Только больших, а не с 2-3 экранами).
Т.е. с точки зрения навыков программиста(математика, структуры данных, алгоритмы, архитектуры, написание кода) вы остались на уровне middle?)
Интересно, это касается текущих сотрудников или и будущих тоже?
Если и будущих, то это серьёзный прецедент уже..
Да, там сравнивается через equality.