Илья

Это называется PIVOT: hp+vertica+pivot.

Например, календарный отчёт, на MS SQL.

таблица с полями: id, month_id, kpi1, kpi2
чтобы стало: id, kpi1-2020-01-01, kpi1-2020-02-01, kpi2-2020-01-01, kpi2-2020-02-01.

Без PIVOT

SELECT ID, SUM(M1K1), SUM(M2K1), SUM(M1K2), SUM(M2K2) FROM
(SELECT ID, kpi1 AS M1K1, 0 AS M2K1, kpi2 AS M1K2, 0 AS M2K2 FROM Table_K WHERE month_id = 1
UNION
SELECT ID, 0, kpi1, 0, kpi2  FROM Table_K WHERE month_id = 2) AS DailyData
GROUP BY ID

SELECT COUNT(1), 100 * FLOOR(sum / 100) FROM ... GROUP BY FLOOR(sum / 100)

Всё! Сделал расширение и назвал его Comfortable Search.

Все выходные думал над названием. Поверьте, это самое сложное. Оно должно отражать суть и в то же время быть достаточно уникальным. А в магазине многие названия уже заняты (я имею в виду комбинацию популярных слов, таких как "redirect", "filter" и т.п.).

Общего между ними то что они работают одинаково. Разницы между ними технически никакой. А вот идеологические различия есть.

Я расскажу о них в контексте PHP. Прошу заметить что протокол HTTP к PHP имеет косвенное отношение потому что он создавался для обмена html страницами а PHP просто расширяет возможности и того и другого.

GET запрос используется чтобы получить данные а POST чтобы отправить. (Напоминаю что технически они работают одинаково).

Поэтому в контексте PHP опираясь на эту идеологию сделали следующим образом:
1. При каждом запуске PHP по умолчанию создаются суперглобальные массивы ($_GET, $_POST).
2. Если в строке запроса есть вопросительный знак(?). То все что после него считается параметрами GET запроса они представлены в формате 'ключ'='значение' и в качестве разделителя используется знак амперсанда (&)
Пример:
GET /index.php?name=Андрей&surname=Галкин
это строка запроса, тут 2 параметра. эти параметры попадут в массив $_GET.
3. $_POST заполняется другим способом. содержимое этого массива заполняется из "заголовков запроса". То есть из места, скрытого от глаз в явном виде. Всю рутину по созданию таких заголовков берет на себя браузер. Хотя иногда и что-то редактируется в заголовках в ручную.

Чаще всего пост запрос используется в формах (для отправки данных).

Например у нас есть форма для входа 2 поля логин и пароль.

Представим что мы используем GET метод. Тогда при отправке формы мы перейдем на следующий адрес /login.php?login=Андрей&password=123 согласитесь что так передавать такую информацию совсем не безопасно. Любой может открыть ваш браузер и начиная вводить адрес сайта он из истории может увидеть ваши пароли и логины.

А вот если бы мы указали методом POST то мы бы получили следующий запрос:
POST /login.php (login=Андрей&password=123) то что в скобочках было бы скрыто и никак не сохранено в браузере.

Теперь другая ситуация например форма поиска. Мы вводим текст и получаем страницу с результатами. Вот тут уместнее GET форма. потому что нам было бы удобно сразу иметь ссылку на результат поиска, то есть добавить в строку запроса можно выразится "Публичные параметры", которыми можно поделиться. И как результат в строке браузера будет конкретная ссылка на текущую страницу. Мы можем ее скопировать, и разместить где-нибудь, или например скинуть другу. И получить при переходе одну и ту же страницу. А не просить других людей зайти на сайт и в поиск вбить определенную фразу чтобы получить необходимую страницу.

В общем подводя итог:
GET - это чтобы получить определенную страницу в определенном виде ( сортировка, текущая страница в блоге, строка поиска и т.п. ).
POST - для оправки данных которые не влияют на отображение страницы, в том плане что эти данные влияют только на результат выполнения скрипта ( логины, пароли, номера кредиток, сообщения и т.п. ).

И еще одна хорошая новость их можно комбинировать, например
POST /index.php?page=login (login=Андрей&password=123) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.

Сервисы в 2019 году фактически надо использовать только для foreground задач, не находящихся непосредственно на экране. А-ля музыкальный плеер и проигрывание музыки, и тому подобное.

Всякие "долгие операции и вычисления", всякие загрузки больших файлов в сеть и тому подобное нужно делать с помощью WorkManager'a.

Некоторое время назад ещё рекомендовал использовать библиотеку от evernote, например, мы в проде ещё не мигрировали с неё.

Имхо, всё это жуткий отстой.
View должно иметь методы только по показу данных. navigateToHome к ним не относится, это должен быть отдельный объект Router, которого нет в MVP.
View не должно иметь ссылку на Presenter и дергать из него какие-то методы.
Во View не должно быть бизнес-логики.
Presenter должен иметь ссылку на View.
Из View должны торчать наружу события(rx observable или коллбеки, например), на которые подписывается Presenter.
У Presenter'a должно быть два метода для связывания его с View: bind(View), unbind(View).
Fragment или Activity не должны быть ни View, ни Presenter'ом, ни Model. Они - клей, системные механизмы для связывания и поддержания стека экранов. Они каким-либо создают или получают через DI инстансы View и Presenter, и cвязывают их при помощи bind/unbind.

Таким образом, методов validate не будет ни в одном интерфейсе, и ни в одной реализации(если только это не приватные методы реализации, конечно).

Упрощенно как-то так

interface LoginView {
    @NonNull Observable<String> names();
    @NonNull Observable<String> passwords();

    void showError(@NonNull String error);
}

interface LoginPresenter {
    void bind(@NonNull LoginView view);
    void unbind(@NonNull LoginView view);
}

interface Router {
     void navigateToHome();
}

class LoginPresenterImpl implements LoginPresenter {

     @Inject
     LoginPresenterImpl(router: Router){...}

    private CompositeDisposable disposables = new CompositeDisposable();
    @Override
    void bind(@NonNull LoginView view) {
        disposable.add(
            Observable.combineLatest(view.names(), view.passwords(), (name, password) -> validate(name, password))
                  .doOnNext(validated -> {if(!validated) view.showError("invalid login")}
                  .filter(it -> it)
                  .subscribe(it -> router.navigateToHome())
        );
    }

    @Override
    void unbind(@NonNull LoginView view) {
        disposables.clear();
    }
}

class Fragment {
    @Injecte
    LoginPresenter presenter;
    @Inject 
    LoginView view;
    
     onViewCreated() {
       presenter.bind(view) 
    }

   onDestroyView() {
       presenter.unbind(view);
    }
}

Кратко о себе: стаж андроид разработки 5 лет, за спиной 10 лет десктоп разработки (оракл и все такое), на данный момент работаем с апворком и есть свой проект в маркете, который приносит неплохой доход, сейчас имеем разработчика на зарплате с доходов

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

2. как и сказали выше опыт сильно решает, подводных камней на андроиде очень много, технологии в данной сфере быстро развиваются, один фреймворк сменяет другой, нужно постоянно что то изучать, гугл тоже как паровоз постоянно мчится вперед, поэтому 1-3-6 месяцев это ни о чем, но это не значит что ничего делать не надо, если программировать нравится и решил связать свое будущее с ним, то клаву в зубы и вперед ))

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

4. советую начинать изучать гугловский jetpack, они пытаются навести порядок с архитектурой приложения, привнести как раз какую то методологию, mvvm в данном случае, начал писать сейчас свой небольшой проект на нем, рекомендую, ставит мозг на место, если не очень понимаешь какой паттерн применить, как правильно проектировать архитектуру, ну и еще рекомендую https://startandroid.ru/ru/ очень сильно помогал на старте, ну и по jetpack там уже есть статьи, желаю удачи! ))