На #AndroidDevSummit18 были доклады, которые очень хорошо смогли структурировать знания по теме. Примером такого доклада является «Files for Miles».
В рамках доклада спикер рассказал о
* Разных папках с файлами в Android и для чего они служат
* Storage Access Framework
* Direct Boot: Device и Credentials Protected Storage, как работать с ними и когда использовать
* Принципы работы кэша приложения: выделения памяти, новые принципы очистки кэша приложений, работа в Android с лимитами в кэше
* Очистка памяти на диске при необходимости (например загрузке большого файла)
* Шаринг фалов
* Рекомендации по работе с файлами через JNI
В рамках доклада спикер рассказал о
* Разных папках с файлами в Android и для чего они служат
* Storage Access Framework
* Direct Boot: Device и Credentials Protected Storage, как работать с ними и когда использовать
* Принципы работы кэша приложения: выделения памяти, новые принципы очистки кэша приложений, работа в Android с лимитами в кэше
* Очистка памяти на диске при необходимости (например загрузке большого файла)
* Шаринг фалов
* Рекомендации по работе с файлами через JNI
Автор: @ArtemBagritsevich
#ArchitectureComponents - это уже некий стандарт в Android разработке, поэтому разработчики допускают много ошибок, в связи с чем есть паттерны, котрых надо придерживаться, и антипаттерны, которых надо избегать, при работе с этим компонентом.
Что важно знать о работе с #LiveData, чем поделились на #AndroidDevSummit18:
* LiveData - это не Stream (или Observable из Rx), а скорее Holder значения.
* Не стоит создавать дополнительный lifecycle внутри #ViewModel, лучше использовать Transformation. Как пример, приводится оператор map который преобразует #LiveData на слое репозитория в #LiveData c данными с UI слоя, что является более безопасным подходом.
* #MediatorLiveData. Я не являюсь большим поклонником кастомных операторов, так как большинство задач можно решить используя стандартные операторы, однако они приводят пример того как написать map используя MediatorLiveData.
#ArchitectureComponents - это уже некий стандарт в Android разработке, поэтому разработчики допускают много ошибок, в связи с чем есть паттерны, котрых надо придерживаться, и антипаттерны, которых надо избегать, при работе с этим компонентом.
Что важно знать о работе с #LiveData, чем поделились на #AndroidDevSummit18:
* LiveData - это не Stream (или Observable из Rx), а скорее Holder значения.
* Не стоит создавать дополнительный lifecycle внутри #ViewModel, лучше использовать Transformation. Как пример, приводится оператор map который преобразует #LiveData на слое репозитория в #LiveData c данными с UI слоя, что является более безопасным подходом.
* #MediatorLiveData. Я не являюсь большим поклонником кастомных операторов, так как большинство задач можно решить используя стандартные операторы, однако они приводят пример того как написать map используя MediatorLiveData.
#ProjectTreble - очень хорошая инициатива от Google, представленная на #GoogleIO17, которая позволяет упростить обновление устройств, отделив Android Framework on реализации Vendora: драйверов, работы с новыми датчиками и пр. Применение такого подхода стало обязательным для всех устройств, которые выпускаются с Android O и более новыми версиями ОС.
https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html
В рамках #AndroidDevSummit18 показали преимущества Project Treble - #GenericSystemImage (GSI). Технология позволяет вам запустить голый Android, не дожидаясь обновления от производителя. Производители устройств используют GCI (который строится на последних исходниках #AOSP) для проверки реализации интерфейса производителя на их устройствах.
Это дает разработчикам возможность на чистой версии Android на основе AOSP на любом Treble совместимом устройстве.
https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html
В рамках #AndroidDevSummit18 показали преимущества Project Treble - #GenericSystemImage (GSI). Технология позволяет вам запустить голый Android, не дожидаясь обновления от производителя. Производители устройств используют GCI (который строится на последних исходниках #AOSP) для проверки реализации интерфейса производителя на их устройствах.
Это дает разработчикам возможность на чистой версии Android на основе AOSP на любом Treble совместимом устройстве.