Pull to refresh

Comments 16

Немного странно видеть вложенный в ConstraintLayout CardView, который для размещения вложенных компонентов использует RelativeLayout
Картинка с iPhone X специально добавлена, чтобы заходили сюда и задавали этот вопрос?
Нет. Это картинка с той статьи, ссылку на которую я указал вначале, она там была в качестве примера.
Сразу видно Джависта перешедшего на Котлин, но пока-еще не научившегося писать идеоматичный код.

P.S. Зачем тянуть в проект Rx только для отправки запроса? Чем не подошли корутины? Они проще, код с ними чище, и работают из коробки. Плюс не нужно знать 100500 операторов сторонней библиотеки. Я могу понять зачем Rx в Java, но вот в Kotlin — нет.
Про корутины спасибо. Не знал, ограничился синтаксисом, а вот глубже копнуть было лень:(
Coroutines — это способ писать асинхронный код в функциональном стиле. Также помогает избежать `Callback Hell`
Rx — это больше к логике. Когда вы стоите потоки данных и управляете ими с помощью операторов.

Если на собеседовании у вас спросят «Зачем вы используете Rx в Android Application» и вы ответите «Для асинхронности», то это будет ну очень плохой ответ (от слова совсем). Rx и Coroutines это вообще из разных отраслей программирования.
Я вот понять не могу — что несет эта статья в массы? Может рассказывает, что то новое, что то интересное или может хотя бы просто оригинальное решение старой задачи новым способом?
В одной из прошлых статей по теме автор спросил — переводить ли эту часть. Люди попросили перевести — автор уважил.
Это не реклама. Просто для людей которые хотят юзать котлин, но не знают с чего начать создан этот простой туториал.
Да достаточно уже информации по котлину, хорошей правда к сожалению мало, но для того что бы «начать» более чем достаточно. Просто оказавшись хотя бы в радиусе 100 метров от любого андроид разработчика достаточно сказать шепотом «Котлин или джава...» и тебя научат, покажут, расскажут и похоливарят на пустом месте.

P.S. Вот написали бы тоже самое на дарте с флаттером, более ответственно и с подробностями техническими — я уверен статья была бы полезнее. Но это не точно
override fun getItemCount(): Int {
        return result.size //Возвращаем размер массива данных
}

Так вроде получше


override fun getItemCount() = result.size //Возвращаем размер массива данных

На сколько я помню, JB готовили типобезопасный билдер для описания макетов, нечто вроде kotlinx.html, чтобы избавить всех от xml

В принципе это гуд, ведь сейчас в любой нормальной приложухе один скрин разрастается на сотни и тысячи строк xml что реально просто не может не бесить, ведь в этой всей каше найти что-то и поменять занимает немало времени.

Как по мне, так вся прелесть билдера именно в типобезопасности, нельзя описать, например TextView вне RelativeLayout

Хотел промолчать, извините, но не могу. Это боль для моих глаз и код ревью этой статьи.
Последней каплей стало это

Мы будем использовать Rx поэтому наша Get функция должна возвращать Observable.

GET(«v1/ticker/»)
fun getCryptocurrency(): Observable<List>

Это прям бельмо на глазу. 95% людей на моей практике не понимают идеологию Rx.
Observable — наблюдаемые потоки данных, в которых вы допускаете больше одного вызова onNext. Обьясните мне, как запрос к сети может спровоцировать подобное действие? Ну естественно про существование `Single` и `Complitable` люди вообще не знают.

Далее по списку
class CardViewHolder(itemView: View?) :

override fun onCreateViewHolder(parent: ViewGroup?, viewType: Int): CardViewHolder {
return CardViewHolder(LayoutInflater.from(parent?.context)


Почему вы допускате `nullable` в parent и view? Что произойдет если parent == null?

Ладно, последний вопрос, что это вообще за DTO?

data class ResponseItem(@SerializedName(«id»)
@Expose var id: String?,
@SerializedName(«name»)
@Expose var name: String?,


Вы уверены на счет повсеместного nullabe и необходимости использования `@Expose` анотации?

К сожалению, пока что это больше похоже на сборник плохих примеров как использовать Kotlin RxJava и Retrofit
Sign up to leave a comment.

Articles