Обновить
16K+
13

Пользователь

23
Рейтинг
7
Подписчики
Отправить сообщение

Только в безголовом режиме

Для себя я только такой и рассматриваю, подключение по ssh, можно собрать кастомный дашборд со статами железа, если понадобится

При желании андроид тоже можно нехило почикать

Можно, но нет желания заниматься: вырезать гугл сервисы, каким-то образом отключать systemui и другие вещи, слишком много доп работы

И при этом железо работает по-умолчанию, а не в виде исключения

Не такая большая проблема в целом, можно использовать https://github.com/libhybris/libhybris и оставаться в рамках android блобов и ядра

pmOS с огромным отрывом выигрывает по расходу ресурсов, что не менее важно

Ядро собрать с поддержкой изоляции namespases и всё всегда работало без проблем.

Лично в моем понимании, если идти в сторону сборки ядра или подобных изменений, то проще уже поставить pmOS как минимум для экономии ресурсов устройства(pmos потребляет гораздо меньше) и большей гибкости

А вариант сборки телеграмм бота как обычное приложения Андройд не рассматривали?

Не представляю, как полноценный сервис, который нужно хостить, упаковать в android приложение, чтобы оно нормально работало

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

Поддерку можно проверить в официальной wiki pmOS: https://wiki.postmarketos.org/wiki/Xiaomi_Redmi_Note_3_(xiaomi-kenzo)

У Kenzo все выглядит довольно неплохо

Можно поставить только консольку, без UI

Я это не упомянул в статье, но у меня именно вариант без UI

Не удалось настроить отключение по достижению процента зарядки

Возможно, что мой сервис поддержания зарядка подойдет

не видит доп. SD карту через SIM разъем. Хотя, например, TWRP с ней может работать

TWRP работает на ядре под Android систему, поэтому там есть все нужные патчи под железо телефона. Можно посмотреть, как обвязка sd карты сделана в android ядре и пропатчить ядро в pmos, но задачка не такая простая

огорчило то, что не работает dual режим с зарядкой по OTG . Пока что либо зарядка, либо работа с устройствами в USB HUB

Тоже проблема поддержки mainline ядро, можно попробовать поизучать android ядро с агентами и сделать патчи для себя

В целом, можно использовать в качестве сервера для каких то не сильно нагруженных вещей. У меня там Hermes агент, например

Тоже есть идея хостить OpenClaw/Hermes, заодно посмотреть на то, как железо телефона справится с двумя сервисами

У Android есть много ограничений

  • всю подобную инфраструктуру нужно разворачивать через Termux те минус гибкость

  • Без глубоких доработок системы/пересборки, нельзя убрать гугл сервисы и прочие потребляющие ресурсы вещи

  • Ограничения/оптимизации андроид по питанию нужно обходить отдельно

  • pmOS без ui после запуска потребляет ~200-300MB RAM и 0% CPU, с андроид даже сравнивать не стоит

Есть мысль: заменить акум на ионистор. В таком случае вроде как "батарея есть" и контроллер не будет с ума сходить, в то же время в случае скачков напряжения он поможет.

Можно собрать любую подходящую по характеристикам батарею, лично мне не хочется вандалить телефон и заниматься сборкой подобного

Я бы с удовольствием почитал про такую доработку, если решите сделать и рассказать об этом

Вопрос по питанию — разве околонулевая зарядка лучше, чем хождение в диапазоне 30-60%, например?

Уже ответили выше, но да, в целом лучше держать заряд на одном уровне. Литий так меньше интеркалируется в анод, таким образом удается держать объем анода на одном уровне. Меньше дельта изменения объема = меньше износ

И второй момент — можно развернуть ещё Caddy, тогда можно будет свои локальные домены использовать без пути от Tailscale.

Если честно, то не изучал вопрос тк в моем случае я не хотел выставлять бота в публичный доступ извне моей mesh-сети. Как я понимаю, то можно запустить и настроить все, что поддерживает pmOS тк это обычный линукс

У самого OnePlus 5T лежит и только форвадит СМС, тоже хочу сделать что-нибудь из него на помощь своему домашнему серверу

Есть несколько моментов, на которые стоит обратить внимание:

  • Если хочется именно чистый Linux, как в моем случае, то сначала нужно проверить, можно ли разблокировать загрузчик на телефоне. Насколько я помню, Op5t разблокируется не сложнее, чем Op3t

  • Насколько хорошо SoC и платформа в целом поддержаны в mainline Linux или наличие форков под конкретные устройства. Можно и самому доработать, но затратно по ресурсам

Еще есть вариант попробовать сделать в Termux, но того уровня гибкости, который дает полноценная система не получить

Согласен, метод then тут явно выигрывает по чистоте. DelegatedScreenStrategy я привёл скорее для наглядности — чтобы показать сам принцип выбора

Что мешает передать его как MutableList во вью-модель?

Ничего не мешает, с этим просто неудобно работать

  • необходимо создать список, прокинуть его в compose и di

  • все еще нужно напрямую изменять список, что я лично для меня не является удобным

  • навигация доступна не из одного места в приложении, а во многих, другими словами, требуется протаскивать список по многим местам

Лично для меня это вопрос удобства и снижения количества возможных ошибок и проблем

Да, по сути взята архитектура из Cicerone и допилена для использования с Nav3

1) в чем по-вашему выражается сильная связь?
2) чем может помочь path навигация? если это выглядит так, как в примере ниже, то в android от этого очень долго пытались уйти в навигации от гугл и наконец ушли тк типизированная в контексте android подходит гораздо больше

entry("/path/to/screen")

3) чем плох config based router в контексте android разработки?

Тоже реализовывал подобное некоторое время назад, статья есть здесь на habr
Возможно, что будет интересно: https://habr.com/ru/articles/881982/

У вас есть 3 экрана под скоупом AuthGraph. нужно чтобы при попадании в AuthGraph (не важно, в какой экран) у вас отработал метод fetch() при старте. Можете, пожалуйста, написать небольшой пример, как вы сделаете вызов? Важно, чтобы вызов был один раз за все время жизни AuthGraph.

Например, создаю AuthFeatureViewModel

Скрытый текст
class AuthFeatureViewModel : ViewModel() {

    init {
        // do something
    }
}

Помещаю ее в скоуп фичи

Скрытый текст
val authModule = module {
    scope<Screen.AuthGraph> {
        viewModelOf(::AuthFeatureViewModel)
    }
}

Инициализирую AuthFeatureViewModel

Скрытый текст
@Composable
private fun Content() {

    val navController = rememberNavController()

    NavHost(
        navController = navController,
        startDestination = Screen.AuthGraph
    ) {

        navigation<Screen.AuthGraph>(
            startDestination = Screen.AuthGraph.EmailInput
        ) {
            composable<Screen.AuthGraph.EmailInput> { navBackStackEntry ->
                val parentNavBackStackEntry = rememberParentBackStackEntry(navController, navBackStackEntry)

                ParentScopeProvider<Screen.AuthGraph>(parentNavBackStackEntry) {

                    koinViewModel<AuthFeatureViewModel>()

                    ComposeScreenScopeProvider<Screen.AuthGraph.EmailInput> {
                        /* omitted code */
                    }
                }
            }

            // omitted code
        }
    }
}

AuthFeatureViewModel создается в скоупе фичи. Но есть минус с дублированием кода, потому что этот код

Скрытый текст
ParentScopeProvider<Screen.AuthGraph>(parentNavBackStackEntry) {

    koinViewModel<AuthFeatureViewModel>()

    // omitted code
}

Должен находиться в декларации каждого экрана, на который может быть совершен самый первый переход в рамках AuthGraph

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

Да, изначально пробовал делать без них. Уперся в то, что без ViewModel не получалось понять, в какой момент закрыть скоуп фичи.

И второй вопрос касательно вашего подхода: как выполнять операции, которые должны совершаться единожды при создании родительского скоупа? 

Для такого я создаю ViewModel, в скоупе фичи и выполняю действие внутри нее

Мы у нас на проекте сделали немного вычурно – создаем composable с navHost`ом, где описываем дочерние экраны –порождает огромное кол-во контроллеров, но зато есть возможность описать родительский контекст в одном месте, а не в каждой функции

А вы уже обрабатывали кейс, когда нужно передавать параметры в объект, который живет в рамках скоупа фичи? Это отдельное приключение

Замечание справедливое, поэтому я доработал компонент и обновил статью. Спасибо!

Не, я успел их застать. Дома стоял один из таких телефонов, правда потом заменили на кнопочный, а потом на беспроводной

спасибо!

Насчет более сложный лейаутов пока что не знаю т.к. на данный момент нет идей как и о чем именно можно было бы рассказать

Информация

В рейтинге
393-й
Зарегистрирован
Активность

Специализация

Разработчик мобильных приложений, Разработчик приложений
Ведущий