Сожалею, но я не смог понять почему "стейт-машина для выполнения асинхронного кода"? А какие "механические связки" Вы имеете ввиду? И почему они приведут к запутыванию логики?
Хорошее начало! Кликбейтное =) Надеюсь, что мы пытаемся рассказать не об одном и том же. Хотя если подумать, то я даже буду рад, если кто-то ещё пришел к таким же выводам. Будет о чем поговорить =)
Обратите внимание, что регулярное выражение - это механизм, который определяет какие последовательности символов входят в язык, а какие - нет. Он изначально не привязан к тексту. Хотя текстовые строки и являются частным случаем строк, с которыми работает регулярка, но также она может быть задана для строк, состоящих из emoji, например, или бинарных символов.
Также коллеги выше правильно заметили, что синтаксис регулярных выражений может меняться в зависимости от имплементации.
Вы можете ознакомиться с курсом "теория автоматов" на edx, там хорошо рассказано про регулярные выражения, на мой взгляд. Кстати, для меня было большим откровением узнать, что конечные автоматы и регулярные выражения - это одно и то же, с точки зрения решаемой задачи.
У вас в приложении можно выбрать отдельно тему для всего Activity и отдельно темы для диалогов?
Нет, тема выбирается для всего приложения целиком, но она может содержать информацию для стилизации диалогов.
Просто в теме Activity можно создать пользовательский атрибут для темы диалога, в диалоге сослаться на него и дальше все переопределять стандартными методами. На первый взгляд — отличное решение или есть какие-то «подводные камни»?
Да, можно попробовать. Можно даже просто переопределить в теме аттрибуты android:dialogTheme и dialogTheme, если хотите повлиять на все диалоги, которые запущены на Вашем Activity.
А почему вы вообще планируете использовать setTheme() в таком контексте? Ведь существует стандартный механизм переопределения тем. Это для тех случаев когда один и тот же диалог на разных экранах имеет разное отображение?
Мы даем пользователям возможность выбирать тему, поэтому стандартный механизм нам не подходит. По стандартному механизму задается базовая тема, а этот механизм меняет ее на тот вариант, который выбрал пользователь.
Я так понял что «решение с диалогом» и «отправка событий экранов» раньше была в базовых классах, а теперь это все живет в ActivityLifecycleCallbacks. С какими вы столкнулись проблемами что решили применить такой подход или какие он дал вам преимущества по сравнению логикой основанной на базовых классах?
Да, раньше это было в базовых классах. Мы перешли на многомодульное приложение и не хотели вытаскивать базовую Activity в корневой модуль. К тому же так не приходится думать о соблюдении соглашения «все Activity должны наследоваться от базовой», мы можем просто добавлять общий функционал во все приложение сразу, не переписывая код.
Добрый день.
На самом деле эта статья построена на примерах из нашего приложения, хотя они и переписаны с целью привлечь внимание к конкретным вариантам использования. В прошлом году мы провели серию крупных рефакторингов, связанных с отказом от базовых Activity и некоторых singleton'ов. Часть кода, которая связана с жизненным циклом Activity как раз была заменена на решения на основе ActivityLifecycleCallbacks.
Если кратко по каждому, то:
мы пока не используем решение с setTheme(), но планируем его внедрение;
для ряда задач мы используем решение с диалогом, но фильтрация организована так, чтобы диалоги отображались на конкретных экранах;
отправка событий экранов у нас построена именно так, как в статье;
внедрение зависимостей используется в обоих вариантах в разных приложениях.
Статья выглядит как крик типичного школьника/студента на тему "это не тот язык который я знаю и люблю, поэтому он плохой, и это никак не связано с тем, что я не смог его выучить".
Практической пользы от неё нет совсем.
Очень жаль, что кто-то может опубликовать такое от имени JUG.ru. Это мелко, низко, написано ради хайпа и не стоит той кармы, которую получил автор.
Коллега, извиниие, если грубо, но учите матчасть.
Согласен с предыдущим комментатором: во всех случаях действуют обычные правила Type Erasure. В последнем надо поменять местами ограничения: чистка идёт до первого параметра. Про первый я тоже не совсем понял, но посмотрю, когда буду у компа.
По поводу вложенных прерываний: да, я знаю, читал про это, но в этой библиотеке нет вложенных вызовов, поэтому простительно. Они могли бы быть, если бы мы вызывали функцию отключения прерываний внутри файлов портирования библиотеки, но там я не нашел мест, где это нужно делать. Думаете стоит включить пояснения по этому вопросу в статью?
По поводу "изобретено до нас": я не зря указал в статье, что мы работаем с HAL. HAL снижает порог вхождения в разработку под STM, но на нем можно сделать не все, это же все-таки абстракция. Пришлось немного запарится, и я решил поделиться своим видением: можно использовать HAL, но нужно использовать немного хаков, думаю это будет полезно тем, кому надо "очень срочно" портировать библиотеку и у них нет опыта работы с StdPeriph, который, как заявляют STM, устарел.
Вероятно должен, но в freeModbus контролируют только 3.5t интервал. В porttimer.c мы как раз инициализируем таймер, который занимается контролем этого интервала. FreeModbus перезапускает таймер каждый раз, когда приходит новый байт, и начинает обрабатывать сообщение, когда таймер обнуляется.
По поводу "двойного" таймера: знаю, что есть многоканальные, не расскажу, потому что не работал с ними.
Официальная документация на HAL описывает 3 способа взаимодействия с периферией:
Polling
Interrupt
DMA
И во всех случаях можно и нужно передавать буферы данных.
Если интересует конкретно DMA, то я, пока, его не использовал, но там идея в том, что мы пишем данные в память, а потом DMA-контроллер сам скармливает его периферии. DMA надо отдельно инициализировать (CubeMX справится).
Я не совсем понял. Я же сам управляю направлением передачи, нет?
По поводу TC: я смотрел исходники HAL, и там TC вызывается программно. Или есть возможность получить это прерывание аппаратно?
Но идея мне понравилась, можно перенести переключение направления передачи прямо в обработчики прерываний и посмотреть что получится.
Я не включал их в статью, потому что она (реализация интервалов) спрятана под капотом.
Сразу стоит уточнить, что это не те интервалы, которые надо выдерживать, а те, которые нельзя превышать. То есть, если Вы превысите межпакетный интервал, то система считает, что на линии проблемы. Проверкой межпакетного интервала занимается таймер, который мы портировани в porttimer.c.
Сожалею, но я не смог понять почему "стейт-машина для выполнения асинхронного кода"?
А какие "механические связки" Вы имеете ввиду? И почему они приведут к запутыванию логики?
Хорошее начало! Кликбейтное =)
Надеюсь, что мы пытаемся рассказать не об одном и том же.
Хотя если подумать, то я даже буду рад, если кто-то ещё пришел к таким же выводам. Будет о чем поговорить =)
Пожалуйста! Продолжайте писать!
Коллега, спасибо за статью!
Обратите внимание, что регулярное выражение - это механизм, который определяет какие последовательности символов входят в язык, а какие - нет. Он изначально не привязан к тексту. Хотя текстовые строки и являются частным случаем строк, с которыми работает регулярка, но также она может быть задана для строк, состоящих из emoji, например, или бинарных символов.
Также коллеги выше правильно заметили, что синтаксис регулярных выражений может меняться в зависимости от имплементации.
Вы можете ознакомиться с курсом "теория автоматов" на edx, там хорошо рассказано про регулярные выражения, на мой взгляд. Кстати, для меня было большим откровением узнать, что конечные автоматы и регулярные выражения - это одно и то же, с точки зрения решаемой задачи.
Привет, это хорошее замечание. Это как раз была тема для следующей статьи.
А вот и она https://habr.com/ru/company/yamoney/blog/492272/
Нет, тема выбирается для всего приложения целиком, но она может содержать информацию для стилизации диалогов.
Да, можно попробовать. Можно даже просто переопределить в теме аттрибуты android:dialogTheme и dialogTheme, если хотите повлиять на все диалоги, которые запущены на Вашем Activity.
Мы даем пользователям возможность выбирать тему, поэтому стандартный механизм нам не подходит. По стандартному механизму задается базовая тема, а этот механизм меняет ее на тот вариант, который выбрал пользователь.
Да, раньше это было в базовых классах. Мы перешли на многомодульное приложение и не хотели вытаскивать базовую Activity в корневой модуль. К тому же так не приходится думать о соблюдении соглашения «все Activity должны наследоваться от базовой», мы можем просто добавлять общий функционал во все приложение сразу, не переписывая код.
Добрый день.
На самом деле эта статья построена на примерах из нашего приложения, хотя они и переписаны с целью привлечь внимание к конкретным вариантам использования. В прошлом году мы провели серию крупных рефакторингов, связанных с отказом от базовых Activity и некоторых singleton'ов. Часть кода, которая связана с жизненным циклом Activity как раз была заменена на решения на основе ActivityLifecycleCallbacks.
Если кратко по каждому, то:
Статья выглядит как крик типичного школьника/студента на тему "это не тот язык который я знаю и люблю, поэтому он плохой, и это никак не связано с тем, что я не смог его выучить".
Практической пользы от неё нет совсем.
Очень жаль, что кто-то может опубликовать такое от имени JUG.ru. Это мелко, низко, написано ради хайпа и не стоит той кармы, которую получил автор.
Коллега, извиниие, если грубо, но учите матчасть.
Согласен с предыдущим комментатором: во всех случаях действуют обычные правила Type Erasure. В последнем надо поменять местами ограничения: чистка идёт до первого параметра. Про первый я тоже не совсем понял, но посмотрю, когда буду у компа.
По поводу "изобретено до нас": я не зря указал в статье, что мы работаем с HAL. HAL снижает порог вхождения в разработку под STM, но на нем можно сделать не все, это же все-таки абстракция. Пришлось немного запарится, и я решил поделиться своим видением: можно использовать HAL, но нужно использовать немного хаков, думаю это будет полезно тем, кому надо "очень срочно" портировать библиотеку и у них нет опыта работы с StdPeriph, который, как заявляют STM, устарел.
По поводу "двойного" таймера: знаю, что есть многоканальные, не расскажу, потому что не работал с ними.
И во всех случаях можно и нужно передавать буферы данных.
Если интересует конкретно DMA, то я, пока, его не использовал, но там идея в том, что мы пишем данные в память, а потом DMA-контроллер сам скармливает его периферии. DMA надо отдельно инициализировать (CubeMX справится).
По поводу TC: я смотрел исходники HAL, и там TC вызывается программно. Или есть возможность получить это прерывание аппаратно?
Но идея мне понравилась, можно перенести переключение направления передачи прямо в обработчики прерываний и посмотреть что получится.
Их сделали, чтобы студенты могли практиковаться, или для создания прототипов.
Сразу стоит уточнить, что это не те интервалы, которые надо выдерживать, а те, которые нельзя превышать. То есть, если Вы превысите межпакетный интервал, то система считает, что на линии проблемы. Проверкой межпакетного интервала занимается таймер, который мы портировани в porttimer.c.