Олег

не удачный пример с платежными системами.
Данные об оплате поступают от мерчанта.
В 99% процентов случаев Ваш сайт просто отправляет посетителя на сайт платежной системы так как пройти сертификацию для работы с данными карт (Payment Card Industry Data Security Standard (PCI DSS) ) большой гиморой.
Для переадресации требуется сумма платежа, идентификатор участника платежной системы в чью пользу оплата, обычно к обязательным полям добавляют возможность добавить идентификатор оплаты со стороны продавца.
Названия полей и их количество немного отличаются от платежной системе к системе.

Есть вторая схема. Предварительная регистрация платежа (бакенд дергает апи и получает ид оплаты). Редиректит пользователя на оплату конкретного счета.

Факт успешной оплаты может проверяться по инициативе со стороны бека, так и через механизм обратных вызовов (хуков)

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

Даже в этом случае (пользователь ничего не передает) верить не желательно.
Стоит перепроверить контрольную сумму. Ограничить доступ к хукам по ip.

Типовой способ защиты: расчет контрольной суммы от
секретнаястрока+поле_данных1+поледанных2+....+полеN

Но способ не подходит для JS так как строка будет видна :(

Чешир, вот уже год Вы перебираете вещи, которые давно перестали работать из-за новых ограничений андроид.
Но в этом вопросе Вы затронули вещь, которая никогда не работала нормально.
Рутование всегда было основано на эксплуатации уязвимостей.
Атака никогда не шла из обычной программы. Это делалось все ниже (до нормальной загрузки устройства).
Подделаное системное обновление (кастомная прошивка). Компроментированный ключ поддиписи редкость.
Искали и ломали загрузчик (аналог биоса для ПК)

X-Accel-Redirect - гуглим такую фишку у nginx

Отправляем пользователя скачивать файл по ссылке с случайной строкой.
Эту случайную строку сохранеям в базу (какой файл ей соответствует и до какого времени правильная).
Например к текущему времени прибавляем 1 час.

Файловый сервер (PHP + NGINX).
Полученный ключ (через апи или напрямую в муську на первый сервер).
Проверили время жизни. Узнали, что отдавать.
Спихнули задачу на nginx (см первую строку ответа)

выложить код в Git
давайте уточним как Вы понимаете этот термин.

Я это фразу понимаю как сделать исходный код доступным (публично) другим людям.
Разберемся зачем так делают люди ?
а) ищут работу и дает ссылку (чтобы работодатели могли оценить Вас как программиста)
б) альтуристы - поклонники Open-Source (GPL)
в) для удовлетворения ЧСВ (публикуют под лицензией требующего сохранения авторства. Апач2)
г) двойное лицензирование (GPL2+коммерческая)
д)жалко выкинуть
е) еще на гитхабе есть куча реп, где люди просто пробывали что же такое гит
ж) по ошибке сделали репу публичной

А вот приватные репозитории люди используют просто потому, что так намного удобнее следить за версионностью кода и искать привнесенные ошибки между релизами.

Оплата по СБП идет поверх договора экваринга с банком.

public class AgentFactory {
    static public InterfaceAPI getAgent(String agent) throws AgentNotFoundException {
        switch (agent){
            case "dump_debug":
                return new DumpDebug(); // заглушка для локальной отладки
            case "gaz_prom":
                return new GazProm();
            case "raiffeisen":
                return new Raiffeisen();
            case "tinkoff":
                return new Tinkoff();
            case "alfa":
                return new AlfaBank();
            case "cft":
                return new CFT();
            case "yoo_kassa":
                return new YooKassa();
            case "pay_master":
                return new PayMaster();
        }
        throw new AgentNotFoundException(agent);
    }
}

Вот кого шупал в живую

Человек продает полностью готовый сайт, наполненный своим контентом.

Такое продают / покупают по формуле доход за N месяцев от сайта. То есть покупателю нужно только поменять привязку к рекламным площадкам на себя.
Купить интернет магазин по такой формуле сложнее. Больше гимороя с переводом на свое юрлицо.

То есть тут ценность в том, что у сайта есть органический трафик. Но опять, могут перед продажой и накрутить.

без контента, добавить свой контент и подключить к своему домену

И пропадает весь смысл покупки готового сайта.

Движок Вы пишите openCart бесплатный с купленными модулями. Угу вот только купленные модули, думаю с привязкой к домену( а вы его меняете) и модули уже становятся не купленными.

В своей функции goLink
Вы просите операционку найти программу, которая умеет открывать урлы.
Можно пойти сложным извилистым путем. Объяснять, что Ваша программа достойнее всех других открыть этот интент.
Но это же ваша программа, поэтому проще заставить свое webView просто загрузить этот урл.
Если сам просмотр на другой активити, то зови ее просто по имени класса.

этика (гугл плей) требует наличие раздела "Used Open-Source". Перечисляешь библиотеки и прочее.
Минимально - название и тип лицензии.
мит,апач и их аналоги для медиа ресурсов. "Вирусные" не беру (требующие раскрытия исходго кода).
Внимательнее со случаем двойных лицензий (есть фришная и коммерческая), эти любят досудебки выкатывать прогам, что смогли набрать аудиторию.

В общем, если у Вас будет меньше 1000 установок в магазине, то Вы неуловимый Джо (так как никому не интересны)

таплинк ? погуглил. Очередной конструктор сайтов.
думаю Вам придется перейти на платный тариф.
прошку. А возможности прикручивания произвольного html/js не вижу в самом навороченном тарифе

Работа с перефирией через USB заключается в отсылке данных в подходящий endpoint и прослушивании парного ему. Относительно просто работать с bulk transfer. Но скорее всего там все же com over usb. Тут без готовой библиотеки сложно. Мониторинг состояния
https://www.upspowercom.com/pcm-download/UPS-Proto...
ну или что-то похожее, если эта документация не подойдет для вашей модели.

Попробуй сперва какой либо готовой прогой терминалом для ком порта пообщаться.

1) зачем Вам имя сайта в условиях ? Не вижу тут задачи для которой это требуется.
2) почитайте про единую точку входа и роутинг. В виде отдельных php файлов давно не пишут.

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ /index.php?path=$1 [NC,L,QSA]

Не старееющая классика. Все чего нет как физического файла на вход скрипта.
переменная path тут даже не нужна. Можно через $_SERVER все нужное получить.
3) для однозначности со слешом в конце попробуй добавить
DirectorySlash Off

ок. Вспомним 90е- начало 00х
/maincraft - предпалагаю, что должно получиться game.php?slug_game=maincraft

RewriteRule ^/maincraft$ /game.php?slug_game=maincraft [NC,L,QSA]

Ну так и напиши как отдельные регулярки все свои случаи.
Главное, чтобы у тебя подпапок физических не было

Нейронку что-ли хотите развернуть?
На хостинге собираются задачи. Домашний сервак через АПИ их забирает и по мере готовности публикует

сходи на packagist и выбери себе либу.
В свое время я взял hoa/websocket, но сейчас проект заброшен.
В любом случае можешь из этих примеров найти вдохновение

https://developer.android.com/distribute/google-pl...
Имхо по углам срезал много

Угу, а я еще подобных вопросов могу назадавать.
Пишут ли приложения меньше 100 мегабайт в ХХХХ году ?
Жива ли ява или котлин ее совсем вытеснил.
Не пора ли забыть про лайоты и генерить интерфейс через код. (бррр до сих YII2 с отвращением вспоминаю)

Одна активность и куча фрагментов - это имхо следствие удобного для простых случаев сеймества классов Navigate.
Но в более сложных приложениях там тоже не все так замечательно.
Например в приложении магнита на главном экране три контейнера, в которых меняются фрагменты. Хотя может уже переписали.

Нет серебряной пули. А в этом году их еще новых завезли.

Начну с того, что развиваю два андроид приложения ps402d (служба печати) и виртуальный принтер (
https://play.google.com/store/apps/details?id=ru.a...). Глубоко это в теме или нет решать Вам.

Сетевые принтеры можно разделить на те, что с IPP и более простые 9100. ( остальные варианты можно отбросить)
через директ можете считать, что статус узнать нельзя. Как вы пишите, тут нужен двух сторонний обмен данными, но вот формат такого ответа не стандартизирован. Может как один так и 3 байта. И другие придумки вендоров.

А вот IPP вещь приятная и задокументированная по RFC.

Теперь на счет оперативности статусов. Не дергают принтеры постоянно !!!!
Первый уровень пассивное прослушивание mDNS. При необходимости явный запрос сетевого ресолва запомненного ранее использованного принтера.
Из днс ответа делаются два вывода : принтер онлайн / принтер офллайн.

Следующий уровень.
Пользователь определился на какой принтер будет печатать. Можно тут уже запустить паралельный тред с опросом состояния принтера (трекинг). Из такого ответа уже получается полноценный статус принтера:
простаиваю печатаю, кончается тонер, открыта крышка, подавился бумагой.
Но такое постоянное замучивание принтера имхо излишне.

Часто перед самой печатью, принтеру посылается команда "проверь задание" (Validate-job).
Но опять же по моему, тут хватило бы просто запросить статус принтера (один раз вместо постояного потока)

Отсылается задание на печать.
Дальше логичнее трекать его состояние работы, но можно и через смену состояний принтера. (занят - простой)

На этом статусы принтера спулеру печати больше не интересны.

Пойманую ошибку автоматом ресетить тоже нет никакого резона, ее наоборот надо пользователю показать.

УК РФ Статья 146 УК РФ Статья 273

Андроид приложение подписывается разработчиком.
Поэтому приложение релиз без "хеша" просто не может существовать.
https://support.google.com/googleplay/android-deve...


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

Во первых, PageSpeed инсайт это просто попугаи от гугла. Снесите с сайта яндекс метрику и сразу +10-20.
100 попугаев означает лишь только одно - гугл не знает как эту страницу сделать быстрее.
с оценкой 100 страница может открываться 5-10 секунд, а отрисовывающаяся менее секунды иметь оценку на уровне 70-80.

Во вторых, показателей быстродействия гораздо больше.
Как бакендер (и на то, что влияет БД) я бы ориентировался на "Время до передачи первого байта ответа"
Минимум этого отклика 5-7мс. Н-р голый PHP или Symfony с прогретыми кешами, когда для ответа не используется ничего кроме самого PHP.

Страница с одним запросом (SELECT ) по первичному индексу это от 5мс.
Время от реквеста до начала ответа должно быть менее 100мс (в идеале 25-50мс).

Во вторых, мне кажется что вы смотрите время полной отрисовки страницы.
Тут нужно оптимизировать время отрисовки начального фрейма страницы. Если на странице много картинок, то сделать ленивую подзагрузку их. Сперва плейсхолдеры, а к моменту прокрутки скачивать.

Возвращаясь к выносу муськи на другой сервер.
В пределах одного компа лучше с ней работать через сокеты. Стек TCP медленее. А если на другом, то сравнивайте сами, ахз может у Вас там будет 10Гигабитс. Но я бы на это не расчитывал, не те тарифы.

Оптимизируйте запросы. Создавайте оптимальные индексы. Для сложных фильтров стоит подумать о других механизмах.

400к - это не то количество, чтобы уже на нескольких хоститься.
В конце концов возьмите дедик (физический сервер в аренду), а не пару VDS.

P.S. Заниматься глубокой оптимизацией на VPS считаю извращением. Так как никогда не знаешь какой на этой машине окажется оверсейлз (продано 146 процентов ресурсов или больше ). Стоит ли что-то кешировать в оперативе или будет только хуже, когда там виртуалки начнут переключаться и свопиться под большой нагрузкой от соседей по серваку.