iPad - как я должен распространять автономный веб-контент для использования UIWebView в приложении?

Question

Я создаю приложение, которое должно загружать веб-контент для автономного просмотра на iPad. В настоящее время я загружаю некоторый веб-контент из Интернета для целей тестирования и отображаю его с помощью UIWebView. Реализовать это было достаточно просто. Теперь мне нужно внести некоторые изменения для поддержки автономного контента. В конечном итоге этот автономный контент будет загружен в выбранные пользователем пакеты.

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

1. Упакуйте содержимое в файл ZIP (или другой архив) и распакуйте содержимое, когда оно загружено на iPad.
2. Поместите содержимое в базу данных SQLite. Кажется, для этого нужны сторонние библиотеки типа FMDB .
3. Использовать Базовые данные . Насколько я понимаю, это поддерживает ряд форматов хранения, включая SQLite.
4. Используйте файловую систему и загружайте каждый необходимый файл отдельно. Хорошо, не совсем пакет, но, может быть, это лучший вариант?

Соображения / Вопросы:

1. Каковы ограничения хранения и производительность для каждого из этих методов? И есть ли общий лимит памяти для приложения для iPad?
2. Если пользователь собирается перемещаться по загруженному контенту, какой вариант проще кодировать?
3. Казалось бы, раскрутка локального веб-сервера была бы одним из наиболее эффективных способов обработки аспектов отображения контента во время выполнения. Существуют ли примеры с открытым исходным кодом, которые загружаются из пакета, как опции 1-3?
4. Другая сторона этого - создание контента, и кажется, что архивирование контента (вариант 1) является самым простым с этой точки зрения. Другие параметры, по-видимому, требуют создания инструментов для поддержки создателя контента.

Answer 1

Если у вас есть контроль над контентом, я бы порекомендовал сочетание как первого, так и третьего варианта. Если контент создан вами (например, уровни и т. Д.), Просто сохраните его на сервере, скачайте zip и сохраните его локально. Используйте CoreData для хранения Индекса о загруженных вами файлах, таких как путь к папке, в которой она хранится, и ее имя / происхождение / и т.д., но не необработанные данные. Считается, что базы данных не содержат огромное количество необработанного контента, а скорее содержат структурированные данные. И даже если они могут - Я не сделал бы этого.

По вашим соображениям:

1. Дисковое пространство - это единственное ограничение, которое я знаю на iPad. Однако базы данных имеют тенденцию работать медленнее, если они становятся слишком большими. Если вы едва сканируете данные, используйте файловую систему напрямую - это может оказаться быстрее и дешевле.
2. Индекс в CoreData может хранить все соответствующие данные. У вас будет очень простой и очень быстрый доступ. Открытие контента загрузит его из файловой системы, что быстро, дешево и не напрягает индекс.
3. Зачем вы это делаете? Перенаправьте ваш WebView в файл: // URL будет иметь тот же эффект, не так ли?
4. Должен ответить сейчас.

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

Пожалуйста, возвращайтесь, если у вас есть вопросы.

Answer 2

Вы можете создать xml-файл для каждого пакета, содержащий путь к каждому файлу в пакете, поместить его в общую для каждого пакета папку.При загрузке сначала загрузите и проанализируйте XML, а затем загрузите каждый ресурс по одному.Это избавит вас от необходимости архивировать содержимое.Создайте папку для каждого пакета локально и воссоздайте там структуру папок пакета.Таким образом, контент будет работать онлайн и офлайн без изменений.

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