Android BibleQuote. Планы на будущее

На сегодняшний день передо мной, как разработчиком BibleQuote для Android, стоят два насущных вопроса: очень медленный поиск и более 25% устройств на Android 3.x и выше, работающих с приложением.
Как я и обещал, на данный момент пользователи могут сами решать, какой функционал в программе должен стать следующим. И по итогам голосования в топе стоит доработка поиска, что подразумевает и скорость его работы, и расширение настроек поиска. Самым быстрым путем реализации скоростного поиска, на сегодняшний день, я вижу введение индексации модулей. Это подразумевает создание механизма, который позволит для каждого из модулей пользователя создать файл SQL-базы, который будет содержать список ссылок на каждое слово, встречающееся в Библии. Но меня смущает то, что модули будут в виде файлов, а индексы в виде БД для каждого модуля.

Также известно, что Тимофей Ха, автор BibleQuote для Windows, на сегодняшний день разрабатывает новую версию приложения. И данное приложение уже будет работать не с файловым форматом модулей, а с модулями в виде SQL-базы данных. Это говорит о том, что рано или поздно все равно придется отказываться от работы с файловыми модулями и переходить на модули в SQL-варианте. При этом индексацию для поиска уже можно будет включать в состав такого модуля.
Вот и возникает вопрос: зачем делать лишнюю работу? Может стоит сразу перейти на новый формат модулей? Благо описание данного формата Тимофей уже дал. Но ведь у пользователей на данный момент только файловые модули, конечного приложения для работы с SQL-модулями пока нет, да и где их взять? Поэтому я решил сделать следующее:

  1. Отказ от работы с файловыми модулями совсем.
  2. Работа с модулями будет производится через механизм импорта модулей пользователя в SQL-формат. Пользователь будет указывать приложению модуль для импорта, а приложение в фоне будет производить его конвертацию и добавлять в библиотеку.
  3. При конвертации одновременно будет строиться индекс для поиска.
  4. При импорте модуля пользователь сможет самостоятельно дополнить модуль метками, выбором категории, языка модуля и т.п. В последующем данную информацию можно будет использовать для работы с библиотекой модулей для отборов и поиска.

Создание такого функционала не обойдется без создания большого количества пользовательских интерфейсов. Но вот тут на второй план выходит второй аспект: количество устройств на новых версиях Android растет стремительными темпами. Рано или поздно придется переделывать интерфейс под современную парадигму. На сегодня для переделки не требуется много работы. Но с каждой доработкой количество работы по обновлению интерфейса будет нарастать. Поэтому я решил передвинуть переработку интерфейса на первый план. А, чтобы было не так обидно тем кто голосовал за поиск, предлагаю утешительный бонус. Создание такого интерфейса позволит работать одновременно с несколькими модулями, которые будут выводится в нескольких вкладках. Количество вкладок при этом можно ограничить только размером памяти устройства. Также это позволит реализовать в будущем более продуманный интерфейс для планшетов.

10 Replies to “Android BibleQuote. Планы на будущее

  1. Я бы даже и не парился с устаревающим принципом программы. Лучше перейти на новое. Или скажем старую оставить. Кто хочет, сможет развивать, код же открыт. А на основе ее начать новую и назвать, как новый проект Тимофея InterBible.

    1. На самом деле все не так сложно. В Андроид интерфейс изначально отделен от функционального кода. Поэтому смена интерфейса приведет только к небольшое переделке 6 классов. Работа с SQL-модулями так и так потребует работы. Но благодаря помощи Сергея Урсул программа готова к легкому переходу на SQL. Надо будет только написать код для чтения модулей из SQL. Ну, а импорт придется писать так и так.

  2. Рад новому интерфейсу. У меня и на планшете и на телефоне ICS. Было бы неплохо вид разделить не телефон и планшет в две колонки, например.

  3. Минусы, при переходе на новую систему (хранение модулей в SQL):

    1) увеличение размеров, потому что надо скопировать содержание модулей, плюс построить индексы. Думаю, что в несколько раз. На сегодня у меня модулей около 1GB, и будет печально если это превратиться в 3-4GB

    2) сложность использования. Например сейчас всё что нужно, чтобы управлять модулями — это просто копировать / редактировать их на SD карточке. Если перейте на SQL — надо думать, как их конвертировать, и как после изменений изменять уже существующую в SQL копию, как при необходимости вытаскивать обратно

    3) Изображения. Сейчас в модули можно включать изображения. Я не уверен, но по моему изображения будет нельзя затащить в SQL. Придётся держать их отдельными файлами? И потом думать, как прописывать к ним пути и идентифицировать какой файл к какому модулю?

    4) Скорость. В том виде, как сейчас это всё работает очень не спеша, а если будет на SQL, то только поиск ускориться, а сама навигация — открытие модулей — может серьёзно замедлиться

    1. 1. Построение индекса в любом случае даст увеличение объема. В остальном, думаю, объем самого содержания модуля сильного увеличения не даст. Хотя посмотрим. Модули после конвертации можно будет сразу удалять, чтобы не дублировать информацию. В то же время, объемы памяти сегодня не настолько критический фактор.
      2. Как я уж написал, SQL-модули — это уже действительность следующей версии. Поэтому все последующие модули будут в этом формате. Можно будет подумать об поддержке одновременно двух форматов, но индексы будут только для SQL.
      3. Изображения легко преобразуются в Base64. WebKit умеет отображать картинки из Base64.
      4. Навигация ускорится, т.к. каждый модуль будет хранится в виде отдельного SQL-файла. А также будет отдельный файл со списком всех модулей и их параметрами. Но как бы там ни было, я обязательно проведу тестирование скорости работы. Если что-то пойдет не так, то новшество отодвинутся до более удачной реализации.

  4. Можно создать онлайн сервис по созданию, конвертации и редактированию модулей. Я не профессионал в php, но мне кажется что это будет не сложно.

    1. У одного моего знакомого очень большая библиотека модулей. Чтобы заставить её заработать в таком случае потребуется всю её загружать на сервер туда и обратно. По-моему это будет затратно для очень большого количества пользователей Цитаты. А вот, если был бы такой скрипт для конвертации на десктопе — было бы круто. Тогда пользователи бы уже в устройство копировали модули.
      Но в любом случае конвертация на самом устройстве будет идти в фоне, что не будет мешать работать с программой. При этом в очередь можно будет отправить сразу все модули, а добавляться они будут по ходу завершения.

  5. Также на основе этого сервиса можно будет сделать базу модулей. И встроить в приложение «онлайн библиотеку модулей».

    1. Созданием такого сервиса сейчас занят Тимофей Ха параллельно с разработкой свежей версии программы. Может вы хотите подключиться вместе с ним в работу?

  6. Хотя меня не болит то что иконка у приложения с православным крестом, но конечно межконфесиальная иконка была бы лучше. А может есть возможность обратиться к Артуру Касимову и попросить его изменить иконку и вместо креста написать «Bible» или «Библия»? Да и приложение в поиске так названо. Ну или может самим переделать (незнаю как отреагирует на это Артур). Это ради тех, кто хочет пользоваться программой, но совесть не позволяет иметь на своем устройстве рисунок православного креста. Я думаю, что все кто грозно возмущались по этому поводу, после такой перемены будут благословлять, а это также хорошая духовная поддержка для проекта.
    Но это мои предположения… Хотя спасибо вам и за то что есть.

Комментирование закрыто