Pull to refresh
10
0
Кирилл Терехов @adev_one

Android разработчик

Send message

В runtime всё равно будет использоваться какая-то одна версия транзитивной зависимости. В случае Gradle — самая новая из указанных (version 2)

  1. Есть SaveStatePresenter в зависимости com.github.adevone.summer:summer-android-save-state. Внутри него в state можно класть только то, что можно положить в Bundle. Это проверяется в compile-time. Так как используется Bundle, это Android-only решение. Сейчас я в процессе разработки чего-то подобного, но мультиплатформенного. На базе kotlinx.serialization, например.
  2. Думаю, это можно решить это с помощью expect/actual. Лично я использую flow для пагинации.

Да, в MVVM примерно такое же количество кода, но нужно городить отдельные классы для того, чтобы прокинуть несколько параметров в один эвент. Не всегда удобно, как по мне.


MVP для мультиплатформы мне нравится тем, что во время компиляции проверяется, все ли методы view реализованы. Когда есть две платформы и одна из них опережает другую, это очень удобно.

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

На мой взгляд, больше похоже на пример применения SRP, если Parcel и UrgentParcel — это разные, с точки зрения бизнеса, сущности и будут меняться по разным причинам.


Тогда тот факт, что в них один и тот же код — случайность и скоро их код может стать совершенно разным.


Если же это UrgentParcel — просто особый вид Pracel, то почему бы не унаследовать его интерфейс от IParcel, применив в реализации делегирование интерфейса, например? Если переиспользование кода через наследование не устраивает по каким-то причинам

Проект, пока что, на стадии разработки и не всё готово. Байт-код для llvm из Kotlin уже генерируется, а поддержка эмулятора заявлена, но, пока не реализована, насколько мне известно.
Сначала генерируются хедеры для кода на Objective-C, который используется Kotlin'ом. Хранятся они в формате ".def". Генерируются с помощью cInterop.

После этого нужно скомпилировать этот используемый код на Objective-C в llvm байт-код (.bc) с помощью компилятора llvm clang.

Затем компилятору Kotlin konanc передаются хедеры Objective-C и файлы исходного кода (.kt). Он тоже сгенерирует llvm байт-код (.bc).

И, наконец, весь байт-код сливается вместе через llvm-lto.

Дальше можно, например, собрать из получившегося ".o" файла статическую библиотеку (.a) и использовать её в своём приложении под iOS, предварительно сгенерировав из Kotlin хода хедеры для Objective-C (я не нашёл способа это сделать сейчас. Возможно, он в разработке).

В этой статье описан процесс компиляции Kotlin вместе с C++: justmaku.org/2017-06-07-kotlin-on-ios
Спасибо, если так думать, то многое встаёт на свои места. Планируются какие-нибудь новые фичи, завязанные на это?
Переслушаю подкаст. Может, я пропустил что-то, но почему даны столь серьёзные гарантии обратной совместимости для неоднозначной фичи, если можно было сделать аннотацию, а потом, если что, пометить её как deprecated и через несколько версий выпилить без поднятия мажорной версии языка? Может, Java научится сама грамотно инлайнить лямбды и выводить общие типы и тогда эта фича станет абсолютно бесполезной и даже вредной.
Добавил бенчмарки. Дублирую ссылку. https://github.com/a-dminator/anko_benchmark
View, в любом случае, держит в себе контекст и ссылка на него даже не weak. Поэтому если передать View за пределы Activity, то это Activity неизбежно утечёт.
Спасибо, действительно лаконично выглядит
А по поводу производительности, хороший вопрос, что затратнее: загрузка анонимного класса или обращение к ресурсу, которое является I/O операцией. Я пробенчмаркаю, когда появится минутка.
Спасибо, поправил. После конструктора родителя и перед конструктором самого класса.

Нужно или дублировать объявление каждого виджета, или каждый раз проходить по всей иерархии вьюх в поисках нужного. Плюс неудобно когда объявление части вью находится в одном месте, а другая часть — в другом. Имхо, хорошо верстать на языке для вёрстки, если на нём действительно можно описать всю вёрстку.

Более развёрнутый вариант:

fun foo() {

    fun loop() {
        (0..10).forEach one@ { i ->
            (0..100).forEach two@ { j ->
                if (j == 5) {
                    return@two  // continue для вложенного
                    return@one  // break для вложенного или continue для внешнего
                    return@loop // break для внешнего
                }
                print("$i, $j\n")
            }
        }
    }

    loop()
}
Условный тернарный, возможно, потом сделают. Его сложно реализовать из-за того, что "?" и ":" — по отдельности тоже имеют смысл.

https://discuss.kotlinlang.org/t/ternary-operator/2116/12
Вместо break можно написать вот такую конструкцию:

(0..10).forEach one@ {
    (0..10).forEach two@ {
        if (0 == 0) {
            return@one
        }
    }
}

Спасибо за пример.

Смущает использование Flowable, он может упасть из-за размера буфера и имеет больший оверхед, чем Observable. Так же не понимаю, зачем нужен synchoronized в BindableAdapter. Он тоже создаёт оверхед и не имеет смысла. RxJava позволяет писать код без синхронизаций.
Спасибо, действительно интересный кейс
Согласен, что Rx не заканчивается на замене streams, но применение этого, скорее, про сервера и Scala. Я пока не видел кейсов под Android, в которых долгоиграющий Observable или Flowable приносит больше пользы, чем проблем из-за сложного жизненного цикла UI-компонентов (потребителей данных), который нужно обслуживать. Буду рад, если вы приведёте пример
1

Information

Rating
Does not participate
Location
Челябинск, Челябинская обл., Россия
Date of birth
Registered
Activity