Кодеки это очень сложная штука для которых нужны совсем специфичные знания (ещё и слабо связанные с программированием, типа математики). Рядовые разработчики пилящие бэкэнд и мобильные приложения с такими вещами не справятся. На это нужны годы человеко-часов высокооплачиваемых специалистов.
Он изначально был таким. В последние годы (ну так, как минимум лет десять) его наоборот пытаются повернуть в сторону большей декларативности. Проблема в том что сделать это с сохранением обратной совместимости совсем непросто, и выходит какой-то монстр.
Растовский cargo в этом плане интересен тем что там есть четкое разделение между простой декларативной частью в виде toml конфига, и опциональной кастомной логикой на самом расте. В cmake же пытаются это объединить в одного монстра.
Вариант это тоже рантайм полиморфизм, там просто количество возможных вариантов типа известно на этапе компиляции в любом месте где вариант используется. У него и открытого наследования разные области применения. Наследование нужно когда есть общий интерфейс поведения и функциям которые с ним работают пофиг на конкретную реализацию, например какой-нибудь логгер.
Вариант удобен когда нужно сложить несколько взаимоисключающих (от рантайм логики) значений (которые могут быть сами по себе никаким другим образом не связаны) в одном месте и затем как-то с ними работать. Например JsonValue который может быть либо числом, либо строкой, либо массивом/объектом и т.п. В данном случае у разных типов нет какого-то общего поведения но их надо просто хранить в одном месте (как значение ключа в объекте или элемент массива).
Вероятно из play приходит "обновление" которое заменяет приложение на пустую заглушку. Так многие производители телефонов делают с приложениями-компаньонами устройств типа наушников, только наоборот. В прошивку телефона встраивается набор пустых apk, которые затем автоматически обновляются из магазина когда соответствующие устройства выходят на рынок. Для пользователя это выглядит будто приложение установилось автоматически.
Главная проблема эти API в том что никто их не использует и не тестирует, и производителям устройств пофиг на баги (встроенные приложения тв каналов используют внутренние апи которые работают лучше и недоступны обычным приложениям). В итоге на многих телевизорах получение списка каналов / епг возвращает неполную информацию или вообще не работает.
Также при воспроизведении канала через TvView банально не работают коллбэки ошибок/статусов. Например мне не удалось ни одном телевизоре получить ошибку при переключении на заскрэмблированный канал. На экране - черный квадрат Малевича, а в коллбэк ничего не приходит. Соответственно показать ошибку пользователю невозможно.
Проблема не в языке, а в том что все современные UI фреймворк - тормозное говно. И это не ограничивается C#. А обычным разработчикам деваться некуда - кушают что дают. Не имеет значение как хорошо и продуманно написан твой код, если в реальности 99,9% времени процессора будет отнимать нижестоящий код UI библиотеки.
Есть конечно вариант вернуться к WinForms но что-то не хочется, да и привязано гвоздями к Винде.
Что-то более нативное вроде WinUI работает ничуть не лучше.
В большинстве гуевых приложений узкое место - сам уй фреймворк, и разработчик приложения ничего с этим сделать не может. А использовать какой-нибудь древний фреймворк из 90-х который работает быстрее не выйдет - потому что больше не поддерживается, не собирается, а если и работает то нет базовой функциональности вроде hidpi и т.п. Или он написан на C и нормальных оберток для других языков нет.
Кодеки это очень сложная штука для которых нужны совсем специфичные знания (ещё и слабо связанные с программированием, типа математики). Рядовые разработчики пилящие бэкэнд и мобильные приложения с такими вещами не справятся. На это нужны годы человеко-часов высокооплачиваемых специалистов.
Что, даже не смогли новых закладок придумать? Действительно китайцы только копировать умеют, как и говорят!
Контроль и слежка это для вас, молодой человек, а не для корпораций
Он изначально был таким. В последние годы (ну так, как минимум лет десять) его наоборот пытаются повернуть в сторону большей декларативности. Проблема в том что сделать это с сохранением обратной совместимости совсем непросто, и выходит какой-то монстр.
Растовский cargo в этом плане интересен тем что там есть четкое разделение между простой декларативной частью в виде toml конфига, и опциональной кастомной логикой на самом расте. В cmake же пытаются это объединить в одного монстра.
Вариант это тоже рантайм полиморфизм, там просто количество возможных вариантов типа известно на этапе компиляции в любом месте где вариант используется. У него и открытого наследования разные области применения. Наследование нужно когда есть общий интерфейс поведения и функциям которые с ним работают пофиг на конкретную реализацию, например какой-нибудь логгер.
Вариант удобен когда нужно сложить несколько взаимоисключающих (от рантайм логики) значений (которые могут быть сами по себе никаким другим образом не связаны) в одном месте и затем как-то с ними работать. Например JsonValue который может быть либо числом, либо строкой, либо массивом/объектом и т.п. В данном случае у разных типов нет какого-то общего поведения но их надо просто хранить в одном месте (как значение ключа в объекте или элемент массива).
Вы сначала восстановление состояния (например текущего поиска) после того как система убивает приложение в фоне сделайте. Стыдоба же.
Вероятно из play приходит "обновление" которое заменяет приложение на пустую заглушку.
Так многие производители телефонов делают с приложениями-компаньонами устройств типа наушников, только наоборот.
В прошивку телефона встраивается набор пустых apk, которые затем автоматически обновляются из магазина когда соответствующие устройства выходят на рынок. Для пользователя это выглядит будто приложение установилось автоматически.
Главная проблема эти API в том что никто их не использует и не тестирует, и производителям устройств пофиг на баги (встроенные приложения тв каналов используют внутренние апи которые работают лучше и недоступны обычным приложениям). В итоге на многих телевизорах получение списка каналов / епг возвращает неполную информацию или вообще не работает.
Также при воспроизведении канала через TvView банально не работают коллбэки ошибок/статусов. Например мне не удалось ни одном телевизоре получить ошибку при переключении на заскрэмблированный канал. На экране - черный квадрат Малевича, а в коллбэк ничего не приходит. Соответственно показать ошибку пользователю невозможно.
А пленку менять кто будет?
Звёзды и пыль выброшенные из галактик из-за их гравитационного взаимодействия
С самолётов космические ракеты уже запускали, это действительно эффективнее чем с земли: https://en.m.wikipedia.org/wiki/Northrop_Grumman_Pegasus
Главная проблема в том что большую ракету самолёт не поднимет, так что так можно выводить на орбиту только микро спутники.
Как минимум можно разрешить локальный доступ для сайтов которые уже крутятся на локалхосте, а остальным обрезать.
Или использовать для этого систему разрешений.
Нашел в фильтрах
Где это? Не нахожу такую опцию в настройках unblock origin
Самое странное тут это то что браузеры такое испокон веку разрешали. Это ж по сути огромная дырень в песочнице JS.
Есть отличное опенсорсное Breezy Weather в F-Droid
Есть для этого встроенная функциональность, explicit instantiation:
Само собой в этом случае шаблон можно использовать только с теми типами которые были явно перечислены.
Проблема не в языке, а в том что все современные UI фреймворк - тормозное говно. И это не ограничивается C#. А обычным разработчикам деваться некуда - кушают что дают. Не имеет значение как хорошо и продуманно написан твой код, если в реальности 99,9% времени процессора будет отнимать нижестоящий код UI библиотеки.
Есть конечно вариант вернуться к WinForms но что-то не хочется, да и привязано гвоздями к Винде.
По-моему все предельно ясно - президент послал, значит надо пользоваться отечественным!
Что-то более нативное вроде WinUI работает ничуть не лучше.
В большинстве гуевых приложений узкое место - сам уй фреймворк, и разработчик приложения ничего с этим сделать не может. А использовать какой-нибудь древний фреймворк из 90-х который работает быстрее не выйдет - потому что больше не поддерживается, не собирается, а если и работает то нет базовой функциональности вроде hidpi и т.п. Или он написан на C и нормальных оберток для других языков нет.