Как стать автором
Обновить
8
0
Денис Александров @Guitariz

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

Отправить сообщение

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

Ну и отдельно спасибо за то, что в хабре появляется не только популистский контент)

Прекрасный обтекаемый ответ.

Хуавей не планирует выпускать смартфоны. Это вовсе не значит, что другие вендоры не могут выпустить смартфоны с этой операционкой.

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

Так аппстор здесь не при чем - у вас ровно такая же ситуация в любом типе разработки.

Если условных 10 лет назад можно было сляпать что-то на коленке и как то монетизировать - сейчас, увы. Трафик дорогой, встроенная реклама дешевая, Рынок приложений переполнен.

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

Но даже такой сценарий я бы рассматривал с привлечением инвестиций и коммерческой разработкой.

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

Тогда вообще непонятен весь спич. В чем проблема? Прилага есть, топ есть, статьи на хабр - хоть обпечатайся.

Написал приложение - не взлетело - сделал выводы - пошел дальше.

А вы уверены, что в финансовой неуспешности проекта виноват именно эппл? Элементарно, ожидание прибыльности от попадания в топ - это именно проблема неверных ожиданий. Сами по себе топы ничего кроме утешения своего эго не дают

Вот да, мне тоже только это на ум пришло. Но опять же, для этого лучше использовать билдеры с анонимными функциями, как например здесь
ktor.io/docs/client.html#features
По сути вместо иницализации класса мы вызываем одноименный метод, куда передаем лямбду, которая в свою очередь относится к пространству билдера. Короче сводим функциональную реализацию к декларативной, где вложенности вызовов порождают необходимые пространства.
По большому счету все это сделано только для того, чтобы не запутаться в порядке инициализации компонент и большом количестве аргументов. Если все имена аргументов самого класса и его компонентов — именованные, никаких проблем — все четко просто и понятно написано.
Я понимаю, что можно извращаться в толковании инициализации, добавлять лямбды, отдельный билдер для каждого аргумента, потом еще написать функции вроде initAfter/initBefore, но все это в конечном случае именованием аргументов решается проще, понятнее и эффективнее.
Просто для размышления — пример последнего листинга может и выглядит эффектно, но ни одного желания понять, что там внутри происходит и как оно работает, не вызывает.
Вроде бы задачка плевая была, а решаем ее, стреляя из пушки по воробьям.
Спасибо, что в современном мире есть именованные аргументы
В принципе все тоже самое работает c Java 8, если кто не в курсе…
Я понимаю, что пишу в Спортлото, но тем не менее — новый Gradle тянет требования к новой версии kotlin, а lifecycle библиотеки сидят вплоть до 1.3.20. Завел задачку в трекере, уже неделю все молчат.
Хочется затащить и начать пробовать в реальном проекте, но вот это легаси не дает ничего.
Ссылка на баг
issuetracker.google.com/issues/181156413
Актуально в случае, когда `username` и `hasUsername` не коррелируют друг с другом. Если значения самодостаточны, несомненно стоит использовать что-то из «Отряда булевых флажков».

Если эти вещи коррелируют друг с другом, надо сделать sealed class и выразить это через его состояния. В любом другом случае догодаться об их взаимосвязи невозможно
Не совсем понял Вашу идею. Могу ли попросить описать более подробно?

Есть публичный интерфейс, есть метод, в который его можно передать. По какой то неведомой логике автор этой поделки считает, что объявлять собственные экземпляры классов нельзя. Как об этом должны догодаться другие разрабы — фиг его знает.
Нормальные решения.
1) объявить интерфейс Sealed классом, закрыть таким образом возможность наследования
2) сделать абстрактный класс с таким же закрытым для переопределения конструктором
3) использовать новоязовский sealed interface как в п.1
4) убрать вообще конкретную реализацию, сделать enum ValidateType. Объявить в рамках него статический метод
validate(type:ValidateType, str:CharSequence):ValidationResult

И это все 4 регламентированых языком способа убрать наследование. В статье же один костыль меняется на другой, еще более извращенный.
Вообще печально, что статья вроде как про то, как котлин должен помогать рефакторить, но по сути вместо языковых фич используются костыли.
Отряд булевых флажков

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

На самом деле конструкция из примера обладает вполне конкретным смыслом
data class User(
    val username: String?
    val hasUsername: Boolean
)

если hasUserName выставлен, предлагать заполнить поле не нужно, независимо от того, есть там значение или нет.
Если флаг выставлен, то даже если имя хранится, предложить все равно стоит — допустим, это имя было сгенерировано по умолчанию.
Уменьшение области видимости

Костыль же.
Можно сделать более очевидные решения в виде абстрактного класса, sealed класса. А теперь еще и sealed интерфейсы будут. В конце концов, заменить передачу валидотара на передачу enum. А клиенту предоставьте статическую функцию, validate с дополнительным параметром type.
Я бы дополнил, что статья скорее про то, как заменить код RXJava на связку Coroutines + Flow.
Но на самом деле корутины позволяют писать код по другим парадигмам, и стараться придерживаться функционального подхода из RX вовсе не обязательно.
Серия статей от Елизарова (не конкретная из статьи, а очень многие за последнций год) очень хорошо показывает, что не обязательно все так усложнять
Некорректное сравнение. RX, как и Flow, происходит от Observable шаблона + ФП программирования.
— RX пошел в сторону фп, получив сотни функций преобразования
— Coroutines Flow расширяет контроль состояния, продолжая идею самих корутин

Это два подхода, порожденных observable шаблоном, но ориентированных на разный результат.

П.С. Имхо, в реальных системах подход Flow более жизнеспособен, т.к. в конечном итоге все упирается именно в контроль состояния. Абстрактно чистое фп возможно чисто теоретически — на деле же мы просто отдаем контроль состояния на сторону. Flows дают более прозрачную картину
Можно конечно, но вопрос адресности. Я думаю всякие Spring разработчики даже не в курсе, чегой-то вам понадобилось (исходя из первого сообщения в этой ветке).
Повторюсь — это задача lifecycle расширений конкретно UI слоя конкретно Android. Статья дает общее решение на уровне языка.
Надо, но это не проблема flow)
Сейчас разрабатывается lifecycle экстеншн для этого. но пока надо делать это вручную. В местах удаления с экрана, убивать и скоуп.

Информация

В рейтинге
Не участвует
Откуда
Ростовская обл., Россия
Дата рождения
Зарегистрирован
Активность