Возможность вложенных каталогов на Android

Question

В настоящее время я разрабатываю приложение для дневников и Android-дневников, которое позволяет пользователю создавать записи и хранить их по дням. Чтобы достичь этого, я подумывал о том, чтобы иметь папку для каждого дня и подпапку в папке каждого дня для каждой записи. Это, вероятно, демонстрирует, что лучше:

день-> запись журнала-> данные записи журнала -> другая запись журнала за этот день-> данные записи журнала -> и т. д.

Теперь, с папкой на каждый день, я уже нахожусь в 365 каталогах, и, возможно, еще больше в них. Это заставляет меня сомневаться в целесообразности реализации такого количества подкаталогов.

Это связано с предупреждением, что я не буду проходить через КАЖДЫЙ каталог сразу, но при максимальной загрузке, возможно, 31 день для отображения в календаре.

Последний вопрос: будет ли мое приложение замедлено для навигации по большому количеству каталогов, или мне вообще не придется об этом беспокоиться? Что мешает мне просто создавать решения для баз данных SQL для приложения, так это то, что в настоящий момент я абсолютно не знаю SQL и не знаю, как легко / быстро его освоить.

Помощь / комментарии / идеи приветствуются Спасибо!

Answer 1

Полагаю, вы имеете в виду каталоги файловой системы, например, на SD-карте? Если так, ИМХО, вы «действительно» не хотите этого делать - я видел примеры того, как такая система «подачи» идет ужасно неправильно из-за сложности.

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

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

В этом случае XXX будет числовыми символами от 001 до> 999, представляющими «номер» записи, допускающей 999 записей журнала в день (более чем достаточно). Использование формата год-месяц-день (ГГГГММДД) позволит сортировать строки с именами файлов в хронологическом порядке, усиленном XXX («001» предшествует «002» в операции сортировки по возрастанию строк). Это также позволило бы выполнять поиск по шаблону (все текстовые файлы записей журнала за данный месяц начинаются с «ГГГГММ».

Выше приведен простой пример, и я бы, вероятно, пошел хотя бы на один шаг дальше и использовал бы один XML-файл для каждого дня. Формат, такой как ...

<journal date=20110213>
    <entry number=001>
        <data topic=My journey to work>On my way to work today blah...</data>
    </entry>
    <entry number=002>
        <data topic=Morning meeting>Fell asleep, blah...</data>
    </entry>
</journal>

Я бы тогда пропустил XXX в имени файла и просто использовал YYYYMMDD.xml.

Ладно, только пара углов (я мог бы бродить, но не буду).

Вы упоминаете об использовании БД SQL - в общем, базовый SQL довольно прост, но он может быть настолько сложным, насколько вы готовы. В соответствии с вашими требованиями вы могли бы избежать использования одной таблицы с относительно небольшим числом столбцов, и механизм БД мог бы обрабатывать большую часть системы «подачи» для вас. Я бы порекомендовал вам попробовать несколько вводных руководств по SQL, прежде чем решить, какой путь выбрать.