AE
они как бы есть,но на разных платформах они в разные классы отображаются. На JVM в java.util.HashMap, в JS обертку поверх объекта JS, в Native есть класс в стандартной библиотеки
Деревья в HashMap...
Size: a a a
2020 May 13
IM
Упс позор мне
QH
Деревья в HashMap...
ну, их там есть немножно ;)
AE
ну, их там есть немножно ;)
Под капотом) и то их напрямую как деревья не использовать)
N
Всем привет
А
Простите пожалуйста, посоветуйте куда могу обратиться с вакансией Kotlin
QH
Анастасия
Простите пожалуйста, посоветуйте куда могу обратиться с вакансией Kotlin
N
Посмотрите, кому не лень, плез. Проблема в следующем.
Прохожу книгу Андроид программирование от бигнёрдранч 4го издания, то есть адаптированная под kotlin.
В одной из глав рассматривается проблема поворота устройства и сохранение состояний различных переменных во ViewModel.
1. ViewModelProviders.of(this) теперь предикативный, и советует использовать фабрику. После выпуска книги, очевидно, что lifecycle-extensions:2.0 обновили до 2.2
Не могли бы вы скинуть какой нибудь хороший пример использования этих фабрик для решения проблемы сохранения данных?
2. До этого, я проходил те же разделы книги, но для java, где в ней просто пихали всё в onSaveInstanceState (в общем в Bundle) и соответственно, оттуда и выдёргивали.
Вопрос тут в том, использование только фабрик и провайдера в котлине для решения этих(сохранение значения переменных при изменении конфигурации) проблем теперь является принципиальным?
Прохожу книгу Андроид программирование от бигнёрдранч 4го издания, то есть адаптированная под kotlin.
В одной из глав рассматривается проблема поворота устройства и сохранение состояний различных переменных во ViewModel.
1. ViewModelProviders.of(this) теперь предикативный, и советует использовать фабрику. После выпуска книги, очевидно, что lifecycle-extensions:2.0 обновили до 2.2
Не могли бы вы скинуть какой нибудь хороший пример использования этих фабрик для решения проблемы сохранения данных?
2. До этого, я проходил те же разделы книги, но для java, где в ней просто пихали всё в onSaveInstanceState (в общем в Bundle) и соответственно, оттуда и выдёргивали.
Вопрос тут в том, использование только фабрик и провайдера в котлине для решения этих(сохранение значения переменных при изменении конфигурации) проблем теперь является принципиальным?
QH
Not Sure
Посмотрите, кому не лень, плез. Проблема в следующем.
Прохожу книгу Андроид программирование от бигнёрдранч 4го издания, то есть адаптированная под kotlin.
В одной из глав рассматривается проблема поворота устройства и сохранение состояний различных переменных во ViewModel.
1. ViewModelProviders.of(this) теперь предикативный, и советует использовать фабрику. После выпуска книги, очевидно, что lifecycle-extensions:2.0 обновили до 2.2
Не могли бы вы скинуть какой нибудь хороший пример использования этих фабрик для решения проблемы сохранения данных?
2. До этого, я проходил те же разделы книги, но для java, где в ней просто пихали всё в onSaveInstanceState (в общем в Bundle) и соответственно, оттуда и выдёргивали.
Вопрос тут в том, использование только фабрик и провайдера в котлине для решения этих(сохранение значения переменных при изменении конфигурации) проблем теперь является принципиальным?
Прохожу книгу Андроид программирование от бигнёрдранч 4го издания, то есть адаптированная под kotlin.
В одной из глав рассматривается проблема поворота устройства и сохранение состояний различных переменных во ViewModel.
1. ViewModelProviders.of(this) теперь предикативный, и советует использовать фабрику. После выпуска книги, очевидно, что lifecycle-extensions:2.0 обновили до 2.2
Не могли бы вы скинуть какой нибудь хороший пример использования этих фабрик для решения проблемы сохранения данных?
2. До этого, я проходил те же разделы книги, но для java, где в ней просто пихали всё в onSaveInstanceState (в общем в Bundle) и соответственно, оттуда и выдёргивали.
Вопрос тут в том, использование только фабрик и провайдера в котлине для решения этих(сохранение значения переменных при изменении конфигурации) проблем теперь является принципиальным?
> предикативный
что?
Вьюмодель и savedInstanceState — это совершенно разные инструменты, которые ещё и интегрируются друг с другом.
Вьюмодель не пережвает смерть процесса, в ней уместно хранить текущие соединения, асинхронные задачи и т. п., а всё, что ввёл пользователь, нужно бережно сложить в savedInstanceState.
Java/Kotlin тут совсем не при чём.
Кстати, в @android_ru есть люди, которые используют ViewModel.
что?
Вьюмодель и savedInstanceState — это совершенно разные инструменты, которые ещё и интегрируются друг с другом.
Вьюмодель не пережвает смерть процесса, в ней уместно хранить текущие соединения, асинхронные задачи и т. п., а всё, что ввёл пользователь, нужно бережно сложить в savedInstanceState.
Java/Kotlin тут совсем не при чём.
Кстати, в @android_ru есть люди, которые используют ViewModel.
N
> предикативный
что?
Вьюмодель и savedInstanceState — это совершенно разные инструменты, которые ещё и интегрируются друг с другом.
Вьюмодель не пережвает смерть процесса, в ней уместно хранить текущие соединения, асинхронные задачи и т. п., а всё, что ввёл пользователь, нужно бережно сложить в savedInstanceState.
Java/Kotlin тут совсем не при чём.
Кстати, в @android_ru есть люди, которые используют ViewModel.
что?
Вьюмодель и savedInstanceState — это совершенно разные инструменты, которые ещё и интегрируются друг с другом.
Вьюмодель не пережвает смерть процесса, в ней уместно хранить текущие соединения, асинхронные задачи и т. п., а всё, что ввёл пользователь, нужно бережно сложить в savedInstanceState.
Java/Kotlin тут совсем не при чём.
Кстати, в @android_ru есть люди, которые используют ViewModel.
большое спасибо, это то что хотелось услышать
AA
> предикативный
что?
Вьюмодель и savedInstanceState — это совершенно разные инструменты, которые ещё и интегрируются друг с другом.
Вьюмодель не пережвает смерть процесса, в ней уместно хранить текущие соединения, асинхронные задачи и т. п., а всё, что ввёл пользователь, нужно бережно сложить в savedInstanceState.
Java/Kotlin тут совсем не при чём.
Кстати, в @android_ru есть люди, которые используют ViewModel.
что?
Вьюмодель и savedInstanceState — это совершенно разные инструменты, которые ещё и интегрируются друг с другом.
Вьюмодель не пережвает смерть процесса, в ней уместно хранить текущие соединения, асинхронные задачи и т. п., а всё, что ввёл пользователь, нужно бережно сложить в savedInstanceState.
Java/Kotlin тут совсем не при чём.
Кстати, в @android_ru есть люди, которые используют ViewModel.
сейчас есть механизм сохранения данных при смерти процесса
з.ы. но это уже оффтоп
з.ы. но это уже оффтоп
QH
сейчас есть механизм сохранения данных при смерти процесса
з.ы. но это уже оффтоп
з.ы. но это уже оффтоп
savedInstanceHandle? Да, я подумал о нём и написал «которые ещё и интегрируются друг с другом»)
Н
Всем привет. Кто сможет помочь. В Android Studio при открытии файла activity_main.xml не отображаются вкладки design и text.
QH
Никита
Всем привет. Кто сможет помочь. В Android Studio при открытии файла activity_main.xml не отображаются вкладки design и text.
гугл поиск сможет помочь
KK
Not Sure
Посмотрите, кому не лень, плез. Проблема в следующем.
Прохожу книгу Андроид программирование от бигнёрдранч 4го издания, то есть адаптированная под kotlin.
В одной из глав рассматривается проблема поворота устройства и сохранение состояний различных переменных во ViewModel.
1. ViewModelProviders.of(this) теперь предикативный, и советует использовать фабрику. После выпуска книги, очевидно, что lifecycle-extensions:2.0 обновили до 2.2
Не могли бы вы скинуть какой нибудь хороший пример использования этих фабрик для решения проблемы сохранения данных?
2. До этого, я проходил те же разделы книги, но для java, где в ней просто пихали всё в onSaveInstanceState (в общем в Bundle) и соответственно, оттуда и выдёргивали.
Вопрос тут в том, использование только фабрик и провайдера в котлине для решения этих(сохранение значения переменных при изменении конфигурации) проблем теперь является принципиальным?
Прохожу книгу Андроид программирование от бигнёрдранч 4го издания, то есть адаптированная под kotlin.
В одной из глав рассматривается проблема поворота устройства и сохранение состояний различных переменных во ViewModel.
1. ViewModelProviders.of(this) теперь предикативный, и советует использовать фабрику. После выпуска книги, очевидно, что lifecycle-extensions:2.0 обновили до 2.2
Не могли бы вы скинуть какой нибудь хороший пример использования этих фабрик для решения проблемы сохранения данных?
2. До этого, я проходил те же разделы книги, но для java, где в ней просто пихали всё в onSaveInstanceState (в общем в Bundle) и соответственно, оттуда и выдёргивали.
Вопрос тут в том, использование только фабрик и провайдера в котлине для решения этих(сохранение значения переменных при изменении конфигурации) проблем теперь является принципиальным?
у официалов на кодлабс были примеры использования фабрик: https://codelabs.developers.google.com/codelabs/kotlin-android-training-view-model/index.html?index=..%2F..android-kotlin-fundamentals#0
А
Здравствуйте! Я недавно изучаю Котлин. Я встретил такую штуку в коде и не понимаю ее. Объясните мне пожалуйста.
presenter = MainPresenter(aktity, inhector)
Я тут просто создаю presenter.
Но фишка в том aktivity тут просто интерфейс а не класс. И почему то Котлин это проглатывает. Я не понимаю почему. Как он может создавать объект presenter тут, если в параметрах у него всего лишь интерфейс? Спасибо
presenter = MainPresenter(aktity, inhector)
Я тут просто создаю presenter.
Но фишка в том aktivity тут просто интерфейс а не класс. И почему то Котлин это проглатывает. Я не понимаю почему. Как он может создавать объект presenter тут, если в параметрах у него всего лишь интерфейс? Спасибо
QH
Александр
Здравствуйте! Я недавно изучаю Котлин. Я встретил такую штуку в коде и не понимаю ее. Объясните мне пожалуйста.
presenter = MainPresenter(aktity, inhector)
Я тут просто создаю presenter.
Но фишка в том aktivity тут просто интерфейс а не класс. И почему то Котлин это проглатывает. Я не понимаю почему. Как он может создавать объект presenter тут, если в параметрах у него всего лишь интерфейс? Спасибо
presenter = MainPresenter(aktity, inhector)
Я тут просто создаю presenter.
Но фишка в том aktivity тут просто интерфейс а не класс. И почему то Котлин это проглатывает. Я не понимаю почему. Как он может создавать объект presenter тут, если в параметрах у него всего лишь интерфейс? Спасибо
Я ничего не понял, например.
aktity, inhector — это, наверное, так английские дети разговаривают
aktity, inhector — это, наверное, так английские дети разговаривают
А
Извините, пишу на ходу
А
Поможете?