• Java / Kotlin: почему так сделать нельзя?

    @red-barbarian
    потому что при сборке R.string.bomba становится целочисленной константой
    Ответ написан
  • React Native vs Kotlin, что выбрать?

    @red-barbarian
    За тебя никто не сделает выбор. Это во многом зависит от самого приложения и как оно будет развиваться.
    попробуй посмотреть https://www.youtube.com/watch?v=OgdT2zWOZ7o
    а также поговорить с опытным разработчиком или участником аналогичного проекта. Вообще решение во многом зависит от бюджета)
    Ответ написан
    Комментировать
  • Как отправить Post запрос в json используя retrofit2?

    @red-barbarian
    что бросается в глаза
    "https://faucetpay.io/api/v1/" сделать "https://faucetpay.io/api/v1"
    Ответ написан
    Комментировать
  • Стоит ли учить Java для android?

    @red-barbarian
    Если планируете заняться профессионально , то нужно знать два языка. Если пишите для себя достаточно kotlin.
    Сейчас почти все проекты начинаются как kotlin. И большинство переписываются (или дополняются) на котлин. Т.е. вероятность, что на легаси проектах будет java есть.
    Ответ написан
    Комментировать
  • Как запустить второе Activity с помощью kotlin?

    @red-barbarian
    Прямо под Ваш случай написали доку
    Start another activity
    Вообще она (документация там) классная. Описано много частых случаев в примерах. И главное у Вас не будет пробелов в знаниях.
    Ответ написан
    Комментировать
  • Правильно ли я использую абстрактный класс Animal?

    @red-barbarian
    Сам вопрос провоцирует: Да! Не правильно! )
    Но если серьезно.
    Не стройте систему от абстрактного к конкретному. Так хорошо в учебнике. в реальности это порождает много ненужных слоем и классов. Делайте это от конкретного к абстрактному. Т.е. есть два класса которые вы применяете. у них есть общее. Вынесите общее в абстрактный класс. Т.е. исходим с низу к абстрактному.

    Второй момент. Связана с полиморфизмом. Это придумать интерфейс а затем его реализацию. Но это другая песня.
    Ответ написан
  • Как организовать синхронную последовательность команд на колбеках с RxJava2?

    @red-barbarian
    Советы на то, что я понял из вопроса)
    1. разделить callback'и и rx. Т.е сделать обвертки которые возвращают Observable/Single/... т.е. типа (назовем) RxB
    2. на более абстрактном уровне работа с RxB . стандартные merge, flatMap и тд (стандартный код Rx)

    и) Лучше вместо PublishSubject использовать PublishRelay

    пункты стандартные. Можно почитать почти во всех книгах. Главное разделить на уровни и тогда все станет ясно
    1) callback -> rxjava
    2) rxjava код
    3) rxjava подписка в ui
    Ответ написан
    Комментировать
  • Как создать XML-файл с программным кодом для нескольких Activity?

    @red-barbarian
    пару-тройку идей:
    - сделать fragment. Код написать в фрагменте.
    - создать класс обработчик, которому будут делегировать обрабатывать нажатия и проч
    - создать кастомную вьюху. Которая будет сразу вставляться ( вместо include)

    на выбор. Исходите от своих способностей и требований приложения.
    Ответ написан
    Комментировать
  • Стоит начинать учить Java / Kotlin и с чего начать?

    @red-barbarian
    Реалии таковы:
    Нужно определить платформу под которую хотите писать, затем выбирать язык.
    Из максимально "широких" языков это Java. Выполняется на всем, где есть jvm. Есть для GUI - JavaFX (убого, но для любого ПК). Для игр LibGdx
    IDE Intellij Idea - для всех платформ (win, linux, mac)

    Из простых Python + QT

    kotlin пока еще лучше после Java учить. Возможно в будущем что-то поменяется. Сейчас практически все курсы/книги прямо или косвенно предполагают знание Java
    Ответ написан
    Комментировать
  • Как вы проектируете классы в ООП и их взаимодействие?

    @red-barbarian
    Чаще всего, в той сфере где вы работаете уже есть уже принятые архитектурные решения. Бест практики. Придерживаться их - избавиться от многих проблем в будущем.
    1. обще принятое - значит не будет сюрпризов для программистов которые сопровождают код
    2. не нужно тратить время для изобретения велосипеда.
    3. название переменных, пакетов и функций говорят о предназначении в контексте архитектуре.
    4. помощь сообщества.
    Теперь если программист решил придерживаться общепринятого (хорошего) решения, у него не будет вопросов как организовать ключевые классы. остаются 20% классов для особых случаев (упростить, разбить большие классы и проч) Желательно эти случае решать также "общепринято". Попробовать шаблоны, если они подходят. Типовые решения и типовые названия.
    Если нужна для проектирования даже бумажка - это значит есть сложность. Это уже плохо. Эта сложность должна быть очень обоснована. Постараться сделать все максимально просто - это искусство и в этом творчество.)
    Ответ написан
    Комментировать
  • Книги, советы, курсы по архитектуре приложений?

    @red-barbarian
    Открою секрет )
    Пишите тесты. Тесты невозможно написать на плохую архитектуру. Делая новый класс, думайте как будете его тестировать. У вас сразу появится стремление выполнять половину принципов SOLID. (даже если вы их не знаете). Стремление сделать классы лаконичными. С хорошим интерфейсом. Стремление разбивать приложение на компоненты.
    Про это много есть статей. тестируемость и архитектура.
    Затем можно почитать какие-нибудь книжки. Для начала Роберта Мартина PPP - дословно не помню) но три пи легко можно найти и перевод. (он для C# вроде, но книга классная)
    Попробуйте TDD. В работе возможно она не будет нужна, но ухватить идею как создается хороший интерфейс можно.
    Затем постоянно себе напоминать, что код пишется для программиста (не для компилятора). Т.е. код это объяснение другому (более тупому))) программисту как это работает. Из этого: хорошие названия - 80% успеха. Остальное архитектура и проч.
    Читать код. Свой, чужой, бест практики.
    То что свой код бесит - это нормально. Плохо если старый код нравится - значит рост прекратился. Это тревожный звоночек.
    Итого.
    1)Начинайте свой рост с умения писать тестируемый код.
    2) когда почувствуете жжение нехватки опыта в конкретных механизмах (паттернах, принципах) начинайте читать книги.
    3) пишите код для тупых программистов (это скромность)
    4) быть вне зоны комфорта это нормально.
    5+) Почитывайте книги Чистый код Мартина и Совершенный Код Макконнелла (те главы которые вам "заходят")
    Удачи в умении сделать сложное простым.)
    Ответ написан
    1 комментарий
  • Как понять что программирование это твое?

    @red-barbarian
    Просто.
    Берешь (дикий) легаси код. И добавляешь туда функционал.
    Это твое если:
    Ты желаешь, что бы твои изменения этого кода были понятны другим людям.
    Тебе интересно, как можно улучшить имеющийся код.
    Тебе важен конечный результат для заказчика. (т.е. функционал должен быть разработан)
    Тебе важно, что твой код можно легко изменить, доработать и т.д.
    И от выше перечисленного ты получаешь удовольствие (от результатов)
    Это не твое:
    Если ты не можешь справиться с желанием набить лицо создателю кода с которым работаешь.
    Если ты не можешь справиться, с тем, что делишь код на свой и чужой. Баги свои и проекта.
    Если ты не можешь заинтересовать себя работать с скучным функционалом.

    В Совершенном Коде, есть страница, где говорится, что умность скорее вред для программиста, чем помощь. Программист борется со сложностью. Это его основное предназначение. Лучше быть тупым (или считать себя тупым), но с кодом который все легко понимают, чем умным который пишет коротко но не понятно.
    Ответ написан
    Комментировать
  • Как реализовать принцип единственной обязанности?

    @red-barbarian
    Совет прочитать роберт мартин чистая архитектура
    Хотя бы главу о SRP
    Обратить внимание "Мартин определяет ответственность как причину изменения и заключает, что классы должны иметь одну и только одну причину для изменений." Обратить внимание когда допускается все оставить в одном классе и когда желательно разделить класс.

    Пока мало опыта разбивать на слои как в примерах чистой архитектуры (в интернете достаточно)
    Или набивать шишки и думать почему я не сделала так как это было в примерах)
    Помнить цель солид очень прагматична - сделать код который легко сопровождается. Всегда об этом помнить.
    Ответ написан
    Комментировать
  • Как организовать передачу данных из Activity в Presenter используя MVP?

    @red-barbarian
    Не надо хранить промежуточные данные. Презентер сразу получает данные от вьюхи. presenter.setTime(time)
    Затем презентер принимает решение, что с ними делать и если отображать то вызывает view.update(time)
    Кстати, обязательно разделяйте презентер и активити интерфейсом.
    Ответ написан
    Комментировать
  • О чем нужно рассказать, когда спрашивают про архитектуру проекта/приложения?

    @red-barbarian
    Отвечай "мы стараемся придерживаться чистой архитектуры, но у нас столько легаси кода..." )))
    Вообще Роберт Мартин писал, что основное преимущество ООП, что это позволило разбивать систему на части-плагины. Т.е. систама разбита на довольно независимые части которые, которые взаимодействуют между собой через довольно устойчивые интерфейсы.
    Архитектура это как эти плагины разметить в системе.
    Например чистая архитектура имеет узнаваемую структуру
    в ценре бизнеслогика, вокруг вещи которые предоставляют логике данные, сохранение этих данных... вокруг различные сервиса, отображение в ui, работа с сетью, с базой данных и т.п.
    Т.е. получается слои. Важный момент, что внутренний слой не зависит от слоя который внешний. Поэтому появляется независимость от реализации от внешних слоев. И к этому появляется сравнительное простое тестирование частей системы.
    Т .е. (на примере чистой архитектуры, описанной здесь совсем не точно и очень сумбурно)
    Рассказ об архитектуре должен быть об разбивании системы на части и как эти части зависят друг от друга. И какие выгоды или проблемы такое разбиение дает.
    Так же часто сопутствуют вопросы "как организовано взаимодействие слоя А со слоем/компонентой Б". Там скорее проверяется знаете ли вы решение типовых проблем. И шаблонов. например MVP, MVC, MVVM, Repository и проч.
    Ответ написан
    Комментировать
  • DatePicker как вывести день недели?

    @red-barbarian
    создать расширение
    DatePickerDialog.updateDate(Calendar)...
    далее

    val datePicker = DatePickerDialog(this).apply{
        updateDate(Calendar.getInstance())
        setOnDateSetListener{_,.....
                textView2.text = ....
        }
    }

    datePicker.show()
    Ответ написан
    Комментировать
  • Почему пишет "приложение AppName остановлено"?

    @red-barbarian
    Потому что из бэкграунда не надо менять вьюхи.
    Или если менять то не через set
    Ответ написан
    Комментировать
  • Что учить первым OOP или java?

    @red-barbarian
    Это практически две разные сферы.
    В хорошей книге всегда будет java + основы ООП.
    Но проблема в том что основы не меняют обычное мышление новичка на объектное.
    Т.е. по привычке все пишется и понимается с точки зрения процедурной парадигмы. А нужно старается понимать с точки зрения где сложная система это набор объектов. Поэтому хорошо бы взять что то простое и паралельно изучать объектно ориентированное проектирование.

    Также лучше сразу читать основы чистого кода. Что бы потом не переучиваться и не ломать себя.
    Три вещи параллельно.
    Хотя многое зависит и от Вашего опыта.
    Ответ написан
    Комментировать
  • Паттерн MVP - в чём его суть?

    @red-barbarian
    Cуть в том, что код в активити сложно тестируем. Кроме того, проблема разрастания активити, включение в него разного рода кода который работает с вьюхами, логикой, базой данных, сервисами и проч и проч.
    Поэтому программистами искались выходы и находились. )
    MVP был придуман задолго до андроида. Суть его (как и других аналогичных шаблонов) в разделении модели и ui. Особенность в том, что мы делаем полностью пассивную вьюху, логику вьюхи переносим в presenter.
    схематично это так: есть интерфейс view. активити реализует этот интерфейс. презентер знает об этом интерфейсе.
    Получается презентер не зависит напрямую от активити, только от некого интерфейса. Поэтому его сравнительно легко тестировать (подставляя свою заглушку view)
    Так решается две основных проблемы:
    - код стал более тестируемым
    - код разделен на пассивную активити и ее логику в презентере.
    По вопросам:
    1. активити читает пароль и логи и передает их в презентер (вызывая соотвествующие методы презентера). а он далее из обрабатывает.
    2. отрисовку данных делает активити с интерфейсом (названным например ActivityView). презентер имеет ссылку на этот интерфейс (активити передает свою ссылку ему), а далее вызывает например activityView.setText(text)
    3. есть два подхода
    а) время жизни презентера равен (не больше) времени жизни активити
    б) время жизни презентера больше времени жизни активити
    соотвественно а) данные сохраняются в budle и передаются в презентер
    б) данные хранятся в презентере
    4 - выше
    5. активити - пассивный объект. управление через презентер. любая хоть немного сложная логика в презентер.
    Применение интерфейсов обязательно. иначе потеряем тестируемость и не избавимся от жесткой зависимости презентер-активити.

    это все описано очень неточно. например вместо "активити" можно подставить "фрагмент". но суть надеюсь понятна.
    Ответ написан
    Комментировать