Так аппстор здесь не при чем - у вас ровно такая же ситуация в любом типе разработки.
Если условных 10 лет назад можно было сляпать что-то на коленке и как то монетизировать - сейчас, увы. Трафик дорогой, встроенная реклама дешевая, Рынок приложений переполнен.
Я могу предположить, что можно изобрести что-то инновационное и стрельнуть, пока конкуренты не очухаются (и потом с большей вероятностью, им продаться).
Но даже такой сценарий я бы рассматривал с привлечением инвестиций и коммерческой разработкой.
А попытка свой труд монетизировать вот так - давайте будем честными, без дизайна, рекламы, маркетинга, девопса и много чего еще сделать действительно хорошее приложение - тяжело. И тем более тяжело не потратить на него пол жизни и увидеть соизмеримую своим часам сумму прибыли приложения.
А вы уверены, что в финансовой неуспешности проекта виноват именно эппл? Элементарно, ожидание прибыльности от попадания в топ - это именно проблема неверных ожиданий. Сами по себе топы ничего кроме утешения своего эго не дают
Вот да, мне тоже только это на ум пришло. Но опять же, для этого лучше использовать билдеры с анонимными функциями, как например здесь ktor.io/docs/client.html#features
По сути вместо иницализации класса мы вызываем одноименный метод, куда передаем лямбду, которая в свою очередь относится к пространству билдера. Короче сводим функциональную реализацию к декларативной, где вложенности вызовов порождают необходимые пространства.
По большому счету все это сделано только для того, чтобы не запутаться в порядке инициализации компонент и большом количестве аргументов. Если все имена аргументов самого класса и его компонентов — именованные, никаких проблем — все четко просто и понятно написано.
Я понимаю, что можно извращаться в толковании инициализации, добавлять лямбды, отдельный билдер для каждого аргумента, потом еще написать функции вроде initAfter/initBefore, но все это в конечном случае именованием аргументов решается проще, понятнее и эффективнее.
Просто для размышления — пример последнего листинга может и выглядит эффектно, но ни одного желания понять, что там внутри происходит и как оно работает, не вызывает.
Вроде бы задачка плевая была, а решаем ее, стреляя из пушки по воробьям.
Я понимаю, что пишу в Спортлото, но тем не менее — новый 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. Объявить в рамках него статический метод
Это тот случай, когда разработчик втыкает любимые паттерны проектироавния с пользой и без пользы. Разлепить состояние письма и состояние уведомления не позволила религия, поэтому будем есть кактус.
Одно состояние
На самом деле конструкция из примера обладает вполне конкретным смыслом
data class User(
val username: String?
val hasUsername: Boolean
)
если hasUserName выставлен, предлагать заполнить поле не нужно, независимо от того, есть там значение или нет.
Если флаг выставлен, то даже если имя хранится, предложить все равно стоит — допустим, это имя было сгенерировано по умолчанию.
Уменьшение области видимости
Костыль же.
Можно сделать более очевидные решения в виде абстрактного класса, sealed класса. А теперь еще и sealed интерфейсы будут. В конце концов, заменить передачу валидотара на передачу enum. А клиенту предоставьте статическую функцию, validate с дополнительным параметром type.
А в чем специфика kotlin-android кода? Это ж все просто кусками нарезаный официальный стайлгайд.
Вообще для студия умеет в автовыравнивание + официальный стайлгайд. Почему не просто запомнить комбинацию клавиш и закрыть вопрос навсегда? Или кому то платят за форматирование кода (может еще и чужого)?
Да, остальные правила можно подсветить detekt'ом. И повесить на коммиты хуком.
Я бы дополнил, что статья скорее про то, как заменить код RXJava на связку Coroutines + Flow.
Но на самом деле корутины позволяют писать код по другим парадигмам, и стараться придерживаться функционального подхода из RX вовсе не обязательно. Серия статей от Елизарова (не конкретная из статьи, а очень многие за последнций год) очень хорошо показывает, что не обязательно все так усложнять
Некорректное сравнение. RX, как и Flow, происходит от Observable шаблона + ФП программирования.
— RX пошел в сторону фп, получив сотни функций преобразования
— Coroutines Flow расширяет контроль состояния, продолжая идею самих корутин
Это два подхода, порожденных observable шаблоном, но ориентированных на разный результат.
П.С. Имхо, в реальных системах подход Flow более жизнеспособен, т.к. в конечном итоге все упирается именно в контроль состояния. Абстрактно чистое фп возможно чисто теоретически — на деле же мы просто отдаем контроль состояния на сторону. Flows дают более прозрачную картину
Можно конечно, но вопрос адресности. Я думаю всякие Spring разработчики даже не в курсе, чегой-то вам понадобилось (исходя из первого сообщения в этой ветке).
Securities Times: Huawei не планирует выпускать смартфоны с Harmony OS за рубежом
Прекрасный обтекаемый ответ.
Хуавей не планирует выпускать смартфоны. Это вовсе не значит, что другие вендоры не могут выпустить смартфоны с этой операционкой.
Flutter vs Native: почему мы переходим с первого на второй
Все равно, как можно такими популистскими фразами обосновать такие изменения, которые просто с двух ног фигачат всю экономику разработки - непонятно.
5 причин не начинать писать приложение под macOS/iOS
Так аппстор здесь не при чем - у вас ровно такая же ситуация в любом типе разработки.
Если условных 10 лет назад можно было сляпать что-то на коленке и как то монетизировать - сейчас, увы. Трафик дорогой, встроенная реклама дешевая, Рынок приложений переполнен.
Я могу предположить, что можно изобрести что-то инновационное и стрельнуть, пока конкуренты не очухаются (и потом с большей вероятностью, им продаться).
Но даже такой сценарий я бы рассматривал с привлечением инвестиций и коммерческой разработкой.
А попытка свой труд монетизировать вот так - давайте будем честными, без дизайна, рекламы, маркетинга, девопса и много чего еще сделать действительно хорошее приложение - тяжело. И тем более тяжело не потратить на него пол жизни и увидеть соизмеримую своим часам сумму прибыли приложения.
5 причин не начинать писать приложение под macOS/iOS
Тогда вообще непонятен весь спич. В чем проблема? Прилага есть, топ есть, статьи на хабр - хоть обпечатайся.
Написал приложение - не взлетело - сделал выводы - пошел дальше.
5 причин не начинать писать приложение под macOS/iOS
А вы уверены, что в финансовой неуспешности проекта виноват именно эппл? Элементарно, ожидание прибыльности от попадания в топ - это именно проблема неверных ожиданий. Сами по себе топы ничего кроме утешения своего эго не дают
Паттерн проектирования Builder (Строитель) в Java
ktor.io/docs/client.html#features
По сути вместо иницализации класса мы вызываем одноименный метод, куда передаем лямбду, которая в свою очередь относится к пространству билдера. Короче сводим функциональную реализацию к декларативной, где вложенности вызовов порождают необходимые пространства.
Паттерн проектирования Builder (Строитель) в Java
Я понимаю, что можно извращаться в толковании инициализации, добавлять лямбды, отдельный билдер для каждого аргумента, потом еще написать функции вроде initAfter/initBefore, но все это в конечном случае именованием аргументов решается проще, понятнее и эффективнее.
Просто для размышления — пример последнего листинга может и выглядит эффектно, но ни одного желания понять, что там внутри происходит и как оно работает, не вызывает.
Вроде бы задачка плевая была, а решаем ее, стреляя из пушки по воробьям.
Паттерн проектирования Builder (Строитель) в Java
Kotlin. Лямбда vs Ссылка на функцию
Представляем бета-версию Jetpack Compose
Хочется затащить и начать пробовать в реальном проекте, но вот это легаси не дает ничего.
Ссылка на баг
issuetracker.google.com/issues/181156413
Стоп рефакторинг. Kotlin. Android
Если эти вещи коррелируют друг с другом, надо сделать sealed class и выразить это через его состояния. В любом другом случае догодаться об их взаимосвязи невозможно
Есть публичный интерфейс, есть метод, в который его можно передать. По какой то неведомой логике автор этой поделки считает, что объявлять собственные экземпляры классов нельзя. Как об этом должны догодаться другие разрабы — фиг его знает.
Нормальные решения.
1) объявить интерфейс Sealed классом, закрыть таким образом возможность наследования
2) сделать абстрактный класс с таким же закрытым для переопределения конструктором
3) использовать новоязовский sealed interface как в п.1
4) убрать вообще конкретную реализацию, сделать enum ValidateType. Объявить в рамках него статический метод
И это все 4 регламентированых языком способа убрать наследование. В статье же один костыль меняется на другой, еще более извращенный.
Стоп рефакторинг. Kotlin. Android
Стоп рефакторинг. Kotlin. Android
Это тот случай, когда разработчик втыкает любимые паттерны проектироавния с пользой и без пользы. Разлепить состояние письма и состояние уведомления не позволила религия, поэтому будем есть кактус.
На самом деле конструкция из примера обладает вполне конкретным смыслом
если hasUserName выставлен, предлагать заполнить поле не нужно, независимо от того, есть там значение или нет.
Если флаг выставлен, то даже если имя хранится, предложить все равно стоит — допустим, это имя было сгенерировано по умолчанию.
Костыль же.
Можно сделать более очевидные решения в виде абстрактного класса, sealed класса. А теперь еще и sealed интерфейсы будут. В конце концов, заменить передачу валидотара на передачу enum. А клиенту предоставьте статическую функцию, validate с дополнительным параметром type.
Руководство по стилю Kotlin для Android разработчиков (Часть I)
Руководство по стилю Kotlin для Android разработчиков (Часть I)
Вообще для студия умеет в автовыравнивание + официальный стайлгайд. Почему не просто запомнить комбинацию клавиш и закрыть вопрос навсегда? Или кому то платят за форматирование кода (может еще и чужого)?
Да, остальные правила можно подсветить detekt'ом. И повесить на коммиты хуком.
Как безболезненно мигрировать с RxJava на Kotlin Coroutines+Flow
Но на самом деле корутины позволяют писать код по другим парадигмам, и стараться придерживаться функционального подхода из RX вовсе не обязательно.
Серия статей от Елизарова (не конкретная из статьи, а очень многие за последнций год) очень хорошо показывает, что не обязательно все так усложнять
Корутинная эволюция в Kotlin. Чем отличаются Channels, Broadcast channels, Shared flows, State flows
— RX пошел в сторону фп, получив сотни функций преобразования
— Coroutines Flow расширяет контроль состояния, продолжая идею самих корутин
Это два подхода, порожденных observable шаблоном, но ориентированных на разный результат.
П.С. Имхо, в реальных системах подход Flow более жизнеспособен, т.к. в конечном итоге все упирается именно в контроль состояния. Абстрактно чистое фп возможно чисто теоретически — на деле же мы просто отдаем контроль состояния на сторону. Flows дают более прозрачную картину
Корутинная эволюция в Kotlin. Чем отличаются Channels, Broadcast channels, Shared flows, State flows
Корутинная эволюция в Kotlin. Чем отличаются Channels, Broadcast channels, Shared flows, State flows
Корутинная эволюция в Kotlin. Чем отличаются Channels, Broadcast channels, Shared flows, State flows