Nik Faraday

Через контекстное меню таблицы:

Разобрался! Отвечу сам на свой вопрос, может кому понадобится.
Чтобы установить событие на свои кнопки в своей кастомной Big Notification. Следует использовать такую конструкцию.

Intent tt = new Intent(this, SettingsActivity.class);
                    TaskStackBuilder ss = TaskStackBuilder.create(this);
                    stackBuilder.addParentStack(MainActivity.class);
                    stackBuilder.addNextIntent(tt);
                    PendingIntent rr = stackBuilder.getPendingIntent(
                            0, PendingIntent.FLAG_UPDATE_CURRENT);
                    expandedView.setOnClickPendingIntent(R.id.notif_btn_settings, rr);
//notif_btn_settings - ид Кнопки, expandedView это мой RemoteViews

Обязательно стоит использовать TaskStackBuilder иначе активити будет открыватся, но шторка не закроется сама!
Так же не нужен класс ресивер MyButtonListener, флаг FLAG_ACTIVITY_NEW_TASK и прочее...

color: #fff !important;

Сказано же по русски, что только выражения могут быть в тернарном операторе.
Операция присваивания выражением не является.

И вообще за подобный код, как у вас в примере, по рукам бить надо.
Вот это лучше будет гораздо:
countOfIteration = Math.Min(width, height);
А если так сильно хочется тернарник, то вот:

countOfIteration = width > height
  ? height
  : width;

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

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

Правильным способом будет не использовать сеттеры. Вот моя статья на эту тему:
https://habr.com/ru/post/469323/

Более подробно: каждый класс нужно проектирвовать так, чтобы данные внутри были максимально связаны. Например каждый метод работать должен в хорошем случае с максимальным числом полей класса, тогда у него высокий cohesion... В тоже время снаружи наужно работать с максимальн омалым числом метода, тогда будет низкая связанность (coupling). Это пара принципов из GRASP.
Когда вы делаете сеттеры и геттеры, то у вас данные внутри между собой почти никак не взаимодействут: с геттером работают снаружи, с сеттером работаю снаружи — весь класс нараспашку, а в нем в 100% случаев появляются данные, которые вместе не должны находиться и никак не связаны — анрушена и абстракция и инвариант и много чего еще...

Про инвариант отдельно: например есть платеж, у него есть значение, с которым платеж инициирвоан (initValue), есть значение холда (holdAmount) и есть значение чарджа на списание (chargeAmount)
Когда вы работаете с платежом, контролируя ивнариант в самом классе, то ваш каждый метод првоеряет др значения и позволяет перейти к др состоянию... методов будет 2-3, все инкапсулировано и безопасно.

Например:

class Payment {
     pub func charge(amount int) void {
          if (this.holdAmount < amount && this.initAmount < amount) {
               throw new PaymentException('Unavailable charge amount')
          }

           if (this.status === PaymentStatus:finish) {
               throw new PaymentException('Payment already fisnished')
          }

          this.chargeAmount = amount
          this.holdAmount -= amount
          this.status = PaymentStatus:finish
     }
}

Тут в одном методе полные проверки и класс сам контролирует все состояние внутри, также соблюдается закон Деметры. У даннго кода высокий cohesion (из GRASP), тк внутри идет плотная работа с внутр данными (значит они корректно тут закроекны) и низкий coupling ( с теми данными для данного кейса только один метод работы, все внутри)

Когда вы раскроете сеттерами и геттерами, то ваше состояние становится непредсказуемо и полагается только на то, что снаружи точно подумали об инварианте (нет)

Просто добавтье в конец вашего js файла строку

document.addEventListener('DOMContentLoaded',function(){let a=document.querySelector('[value="4285958269"]'),b=document.querySelector('[value="56132132"]');a.addEventListener("change",function(){b.checked=a.checked})})

Если даты в формате ISO, то

new Date('2011-10-10T14:48:00') > new Date('2011-10-10T10:48:00'); // true

Собрать новый массив:

const newArr = arr.reduce((acc, n) => (
  acc.push({ ...n, fractionTotal: n.fraction + (acc.at(-1)?.fractionTotal ?? 0) }),
  acc
), []);

// или

const newArr = arr.map(function({ ...n }) {
  n.fractionTotal = this[0] += n.fraction;
  return n;
}, [ 0 ]);

Изменить существующий:

arr.forEach((n, i, a) => n.fractionTotal = n.fraction + (i && a[i - 1].fractionTotal));

// или

arr.reduce((acc, n) => n.fractionTotal = acc + n.fraction, 0);