Прежде чем править манифест загляните в стили.
в папке ресурсов он есть или нет (styles)
Для теста если там нет нет добавляете item .
Пробуете запустить.
А потом уже смотрите нужны ли вам два стиля ? Нужно ли править из-за этого манифест.
Как искать ответ самому.
Видим ругается на Error inflating class com.google.android.material.navigation.NavigationView
гуглим com.google.android.material.navigation.navigationview implementation
нагугливается, что это com.shreyaspatil
Удивляемся. Пока гуглили заметили, что в пустом проекте можно попробывать сделать через визард активностей.
ок. открываем лайоут .
становимся на com.google.android.material.navigation.NavigationView
нажимаем аккорд Ctrl+B - мой любимый - перейти туда где это было определено.
попадаем в класс
мотаем вверх смотрим
package com.google.android.material.navigation;
подымем взгляд еще выше на заголовок окна и видим
com.google.android.material:material:1.1.0@aar
Мое первое предположение оказалось ложным.
Возвращаемся на лайоут.
Редим предпросмотра. Серыми квадратами рисуется, то что не смогла система правильно распознать.
Забыли подключить или написали неправильно.
Режим текстового просмотра. Что нибудь подчеркивается. Значки предупреждения в виде дерева
Студия максимально старается подсказать.
Пробуйте.
К сожалению, В вашем случае скорее всего дело в стили заданном в манифесте для активити.
Не очевидный момент. Докопаться самому через отладку сложно. item name="windowActionBar" false должно быть https://stackoverflow.com/questions/52397840/cause...
Хм, даже не подумал в эту сторону. Хотя и видел переменную сессии.
Во всех платежных системах принцип один.
В своей базе фиксируете желание пользователя заплатить/оплатить заказ.
Отправляете на страницу оплаты с указанием за что конкретно платится.
Есть подвиды, когда нужно до этого дернуть апи платежной системы и зарегистрировать там , получив конкретную ссылку, уточняющий параметр.
От платежной системы приходят два вызова.
Перед началом списания денег, что вы готовы их принять(зафиксировать покупку). Обычно такой хук тупо отвечает. Да давай деньги быстрей.
Буквально через секунду летит второй вызов (я его авизкой называю)
Тебе пришли деньги. Столько то. И вот в этот вызов платежные системы дают обычно протянуть дополнительные поля. Полезную нагрузку от кого и за что оплата. Обычно уточняющим выступает номер заказа.
При приходе авизо делаются все проверки. Точно платежная система ? сумма правильная ? и т.п. Но если отправителя обязательно проверять,
то платеж можно просто зафиксировать и оставить человеку окончательную роль принятия решения, что с оплатой все хорошо.
Т.е. Если не сошлось в копейках из-за конвертации код может сам прощать или помечать заказ что оплата была в таком то размере.
А вот тому, что приходит с гет параметрами при редиректе пользователя я бы не верил.
это просто аккорд из двух кнопок. Crtl+L
Форматирование. Отступы и т.д. Давно не показатель качества кода.
Современные среды разработки даже проведут более глубокий анализ за Вас.
Все что нужно это понимать. По делу или нет ругается .
Иногда предупреждения все же приходиться давить.
А в правом углу зеленая галка может быть и у неправильно работающего в плане бизнес логики кода.
Самый страшный бан для андроид разработчика, это когда по цепочки банятся все гугл аккаунты, которые гугл посчитал, как используемые одним человеком.
В общем Вас все равно вычислят и забанят телефоны всей семьи ;)
Забыл написать. Сам по себе SQL это тоже можно сказать язык программирования.
Хотя бы минимально с ним разобраться, чтобы понимать, что происходит под капотом более высокоуровневой обертки.
Основные команды 4 : select (тут целая вселенная ), insert, update, delete
Академически в основе SQL лежит реляционная алгебра множеств. Но если не вуз. То всякие кортежи и пересечения множеств можно наверное опустить. www.mysql.ru/docs/man/SELECT.html
Вам потребуется LIMIT смещение, сколько_брать
Берете любой учебник и делаете поправку, что в большинстве они написаны на примерах mysql_что-то
а сейчас все перешли на mysqli_
объединение таблиц.
where a.id = b.id_a эквивалент left inner join
left outer join - все записи слева и поля из второй таблицы по ключу или нулл значения.
еще есть правое объединение, но я его практически за свою жизнь не использовал.
в запрос таблица может входить больше одного раза. В этом случае ей присваивается алиас.
таблица поставленных значений войдет в запрос дважды.
Первый раз чтобы найти ид за что поставлены оценки.
соединиться с таблицей аналогов, чтобы получить за что еще можно голосовать.
теперь открытое соединение(left outer) с таблицей оценок.
Там где голосовал будут значения. А за что еще нет останется нулами.
третий джоин закрытый (left inner) . Ключ inner можно не писать (как дефолт)
остается к запросу добавить условия отбора записей. К первому алиасу оценок по ид пользователя, ко второму , что значения нет.
И в части перечисления полей, что нас интересует только ид и название из товаров.
пользуетесь его визардом создания болванки(заготовки).
Доводите не меняя ни буквы до запуска.