Олег

проверка на нул,
https://developer.mozilla.org/en-US/docs/Web/JavaS...
если объект то что у него нет пропертей
https://stackoverflow.com/questions/679915/how-do-...
и в случае массива что длина больше нуля

Такое впечатление, что драйвер рендерит изображение чуть не 75 дпи.
А тестовое вложение на 1200 .

Точки это работа алгоритма дизеринга и белые полоски на буквах по той же причине. Просто на высоком разрешение их не замечаете

Возможно.
HTML, JS, CSS, IMG все нормально будет подгружаться из андроид assets.
Только аккуратно придется с путями.

Можно даже взаимодействовать с приложением
https://developer.android.com/develop/ui/views/lay...

Начальный урл будет вида
file:///android_asset/app/index.html

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

При желании даже в консольном приложении, которое пишет один человек, можно разделить на фронт и бакенд.
Для этого просто не нужно размазывать вывод по коду, а собрать его в одно место.

Чуть усложним. Привычное для пользователей приложение. Разработчики пишут их разделяя код
на части. (рисующие экран пользователя, хранящие данные, делающие действия, реагирущие на тапы/клики/ввод)
Тут тоже получается можно поделить на фронт и бек.

Теперь возмем CMS для сайта. Во фронт можно отписать шаблоны страниц, а сам движок в бакенд.

Ок. Сферический сайт PHP+MYSQL+JS+HTML+CSS
тут вроде просто. То что пишем на PHP+MYSQL бакенд. HTML+JS+CSS - фронт
И уточнять словом сервер нет необходимости. Работу можно поделить между верстальщиком и программистом.

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

Вернемся к приложениям.
"бакенд - сервер" означает, что приложение имеет серверную часть.
тут пригодиться еще один термин API - Aplitation Protocol Interface.

Технологий как с телефона/компьютера обратиться к серверу в интернете придумали достаточно много.
Простейшая из них очень похожа на общение с сайтом (GET/POST), только вместо HTML программам удобнее разбирать структуированные данные (json или xml)

Самое прикольное, что на каждом уровне цепочки общения что-то можно назвать фронтом и беком.
https://stackoverflow.com/questions/73778563/nginx...
Пример со стековерфлоу.
Nginx - общается с пользователями. Но вот человек вполне понятно для других спросил про фронт-сервер и бакенд. Откуда будут браться статические данные и куда передавать запросы требующие обработки.

Так, что "сервер" в названии это уточнение, что часть бизнес логики выполняется на другой машине (не текущей) или за нее отвечает другая программа

<?php
$mysecret = 'supersecret';

Минимальный совет из "PHP Правильный путь" звучит как храните свои конфиги хотя бы в виде php файлов.
Предположим, что мы сохранили такой скрипт в корне www.
При правильной настройке сервера посетитель увидит пустой экран по урлу //your.site/script.php
так как в нашем файле нет команд вывода.
В первой строке полный синтаксис, в варианте "<?" может случиться ситуация показа исходного текста, если сшорт таги отключены. И остается риск того, что php отвалиться и будет показываться исходный код.

Обще принятой практикой сейчас считается подход, когда все исходные файлы лежат выше диретории www рут.
В самой директории только один скрипт точки входа (index.php)

Ваши пароли скорее утекут по другой причине, чем из-за того, что к скрипту обратяться на прямую.

Вы используете eval c данными от пользователя или на сайте можно загружать через форму файлы.
На шаред хостинге ошиблись с разделением прав для ftp.

У Вас используются системы контроля версий кода и конфиги не добавлены в игнорируемые.

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

Идеально для рекламодателя. За цену одного показа аудитория, сидящая за одним NAT сервером.

Откройте логи своего сервера. Посчитайте кол-во строк с запросом какой нибудь внутренней страницы.
сравните с числом уникальных айпи с которых к ней были обращения.

Прикиньте свою упущенную выгоду. Соотнесите с затратами на сделать подсчет лучше.
Если овчинка не стоит выделки, то и так сойдет.
Единственное рекламодателю показывал бы два числа. Всего показов (уникальных IP)