Как создавался Easy Recovery Installer (ERI) (Часть 2)

Предыдущая часть:

• Как создавался Easy Recovery Installer (ERI) (Часть 1)

Продолжаем создание ERI, теперь нам нужно разобраться с интернет хранилищем.

Хранилище

 В хранилище у нас будут лежать наши файлы, которых будет много. Основным нашим требованием к хранилищу будет "возможность получать прямые ссылки". Можно использовать какой-то FTP сервер или HTTP, нам главное просто получить прямую ссылку на файл (пример адреса: https://firmware.center/projects/Octanium/ERI/rc/moto_g_osprey_twrp303.img). Для тестирования я использовал репозиторий GitHub, у него есть некоторые ограничения, касательно объема данных, если объем данных будет превышать 2 гигабайт, GitHub может начать возмущаться (заблокировать аккаунт, закрыть репозиторий), хотя у меня там уже больше 2-х гигабайт и пока что все нормально. Но во всяком случае есть аналоги это: Bitbucket, GitLab и прочие... (нужно помнить что это не файловые хранилки, а сервисы для работы с кодом, в связи с чем у них есть некие ограничения на файлы которые вы пытаетесь туда загрузить, процесс загрузки файлов тоже специфический, но при этом отличная скорость загрузки и доступность, для мелких файлов идеально). Можно еще воспользоватся услугами хостера, который предоставляет доступ к хранилищу, которых в сети очень много. Мне повезло, я знаком с отличными ребятами из firmware.center, они мне разрешили разместить у них файлы =) (firmware.center - это сервис который бесплатно распространяет прошивки и ПО для различны устройств). Теперь подумает как наша клиентская программа будет связываться с нашим хранилищем.

Связь с хранилищем

  Связываться с хранилищем мы будем элементарно, загружая файл с списком файлов. Так как нам там нечего скрывать, мы можем обойтись без заморочек (если у вас какая-то сверх секретная информация можно использовать FTP или API, но скорость таких связей может оказаться не такой высокой как просто загрузка файла, все из-за количества запросов). В принципе если у вас в текстовой информации на открытом хранилище лежит что-то что вы хотели-бы скрыть он лишних глаз, можно содержимое файла зашифровать, и расшифровать уже в клиентской программе. У меня все файлы лежат вот тут firmware.center/projects/Octanium/ERI (мне скрывать нечего), сначала загружается файл конфигурации pg_info.ini (он содержит информацию о версии клиентской программы, и версию базы вместе с именем файла базы), после обработки программой файла конфигурации pg_info.ini, программа загружает нужный файл конфигурации с базой  recovery_base_v1.ini (это и есть наш список файлов), далее клиентская программа локально обрабатывает файл с базой, давая выбор пользователю.

 Почему два файла? - первый содержит минимум информации а значит вес его минимальный, так-же я заблокировал возможность использования не актуальной версии клиента, пользователь может использовать только актуальную версию клиента (т.к. старая версия может не корректным образом работать с базой). Еще такой подход упрощает процесс внедрения серьезных изменений в проект, например: для перехода на использование файла с базой данных (а не файла конфигурации), мне нужно просто указать путь к файла и новую версию клиентской программы в pg_info.ini.

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

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

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

  Это пожалуй основные ключевые процессы в ERI, далее я поведаю об интерфейсе клиента.

Следите за моими обновлениями, продолжение следует...

Продолжение: Как создавался Easy Recovery Installer (ERI) (Часть 3)