"Насчет жора памяти, у ios и android работают сборщики мусора, вам просто так не дадут сожрать всю память устройства, GC начнет выгружать старый кэш и соответственно приложение начнет медленно работать, т.к. придется заново все подгружать."
Сборщик мусора очистит только тогда, когда не будет ни одной ссылки на объекты, а в данном случае они будут в стеке навигатора. Логично что либо приложение сдохнет или будет тормозить.
Интересно, как этот момент задумывался самими разработчиками flutter, они наверняка предполагали, что будет возникать такая проблема. я вот в интернетах ничего не нарыл по этому поводу.
Вообще мне кажется, что тот код, который приводиться в примерах самими разработчиками не совсем удачный:
т.е. каждый раз создается новый объект, может быть стоит не создавать каждую страницу заново, а переиспользовать ранее созданные страницы при помощи какого-нибудь сервиса.
В общем хочется понять, как другие программисты в такой ситуации действуют: то-ли не заморачиваются и делают new Page(), то-ли как то по другому. и вообще, есть ли проблема тут, может быть это я ошибочно ищу проблему там, где ее нет.
6.4.0 - совместим, ну и 6.2.0 тоже - он у меня компилировался и работал нормально в тестовом консольном приложении.
Сейчас проблема у меня решена путем обновления до 6.4.0, но первоначальный вопрос все-таки остается открытым...
Вот еще вопрос: как выполнить эти скрипты синхронно. Я поэкспериментировал сейчас и обнаружил, что если мы добавляем несколько скриптов, то они могут не успеть проинициализироваться. как сделать так, чтобы добавленные скрипты отработали по очереди?
Я скопировал в папку /etc/docker/certs.d/my-https.registry.example.com файлы certificate.crt и ca_bundle.crt, которые получил от letsencrypt (т.е. те, который содержат открытые ключи CA и моего домена), перезапустил сервер и докер стал доверять моему репозиторию.
Спасибо всем, кто откликнулся, проблема, можно сказать, решена.
Прочитав документацию https://docs.docker.com/engine/security/certificates/
сделал вывод, что докер при попытке скачать образ из репозитория, расположенного по адресу my-https.registry.example.com нужно создать в папке /etc/docker/certs.d/ папку "my-https.registry.example.com", в которую скопировать файл ca.crt который является сертификатом в формате PEM корневого CA, который выдал сертификат для сервера репозитория образов.
Я заменил имя "my-https.registry.example.com" на то, которое используется моим репозиторием, перезагрузил сервер, после чего выполнил команду docker pull my-https.registry.example.com/myimagename, но все осталось как раньше: сообщение об ошибке: "Error response from daemon: Get https://my-https.registry.example.com/v2/: x509: certificate signed by unknown authority"
как еще можно продиагностировать эту проблему, чтобы выявить, чего не хватает докеру для веры в CA, который подписал сертификат сервера my-https.registry.example.com?
ага. вижу что self link with foo: 4 работает так как нужно, но там явно указан параметр bar без значения, т.е. он будет браться из текущего копонента. а если у меня 100500 параметров и 100 ссылок, мне их тоже все перечислять придется в каждой ссылке?
Спасибо.
но получается не совсем то, что нужно.
например, если сначала нажать ссылку "foo: 1, bar: 2" (query: {foo: 1, bar: 2}), а потом "foo" (query: {foo: 3})
то получается, что параметр bar сбрасывается в значение по умолчанию.
а я то хочу, чтобы ссылка foo содержала два параметра: foo:3 и bar: <текущее значение бар>
Антон, спасибо за подсказки.
Я сегодня поэкспериментировал с маршрутами и параметрами и выяснил вот что:
Если мы в конфигурации маршрутизатора указываем пути с динамическими частями, (например так: path: "/advnotes/page/:page/scope/:scope") и указываем props:true, то все получается так, как вы и сказали, ссылки с частичным указанием пропсов (вот таких след.) действительно дополняются всеми остальными пропсами, которые были указаны в маршруте.
но с query параметрами такое не проходит, т.е. если в маршруте написать
name: "testroute",
props: (r) => ({
page: r.query["page"],
scope: r.query["scope"],
}),
а ссылки оформить как
след2
то полученная ссылка будет содержать только один query параметр, в этом случае page=2
Выходит, что если мы хотим менять url, менять только один параметр и чтобы остальные оставались прежними - то нужно использовать динамические сегменты в маршруте.
а если хотим использовать параметры query, то о сохранении остальных параметров мы должны позаботиться сами, явно прописывая их во всех ссылках.
Или может быть вы знаете какой-то способ, чтобы работать с query так же гибко как с динамическими сегментами
Отлично.
А вот еще вопрос, как лучше всего передать ссылку на возвращение, поясню:
я нахожусь в компоненте со списком, у которого много параметров в url, затем я перехожу на другой маршрут, к другому компоненту, чего-то там делаю и мне нужно вернуться к прежнему месту. Я предполагаю, что нужно в этот компонент передать какой-нибудь пропс, что-то вроде returnurl, который будет иметь значение текущей локации, а для возврата просто вызвать $router.push(returnurl)