Предварительно заполнить автономный appcache HTML5 для UIWebView в приложении iOS - PullRequest
13 голосов
/ 14 ноября 2011

Можно ли создать UIWebView с предварительно заполненным автономным кэшем приложений HTML5, чтобы он работал автономно, даже если пользователь впервые обращается к UIWebView?

Если да, то как?

Я знаю, что могу добиться этого с помощью других механизмов, но вышеизложенное - мой первый выбор.И мне просто любопытно, если это возможно.

Я ничего не вижу в документации.

Ответы [ 3 ]

6 голосов
/ 23 ноября 2011

То, что вы ищете, это два файла в вашей папке кеша.

ApplicationCache.db и cache.db

Они оба находятся в Library / Caches / [идентификатор вашего пакета] папка для вашего приложения, к которой у вас есть полный доступ.Вы можете добавить предварительно заполненные данные кэша в свой пакет и просто скопировать их в папку кэшей при запуске приложения.

Кстати, вы можете играть с ними легко, так как они простые, базы данных SQLITE.

Надеюсь, это поможет

4 голосов
/ 21 ноября 2011

Я думаю, что это может сводиться к вопросу о том, можете ли вы программно записать в файл кэша UIWebView (то есть, находится ли кэш UIWebView в песочнице вашего приложения) - если вы не можете, то игра окончена. Если вы можете , то возникает вопрос, что произойдет после того, как вы поместите предварительно заполненный файл кэша на место, и будет ли UIWebView «одурачен», думая, что он уже загружен и кэшировал ваш контент HTML5.

Если вы используете iPhone Simulator для тестирования своего приложения, посмотрите ~/Library/Application Support/iPhone Simulator/5.0/Applications (замените "5.0" на вашу версию iOS, если это необходимо). Вы должны увидеть длинную строку шестнадцатеричных цифр для каждого приложения, которое вы скомпилировали в симуляторе; найдите тот, который соответствует вашему приложению, а затем найдите в подпапке Library/Caches/[your app's identifier] файл с именем Cache.db.

Это может быть местом, где UIWebView хранит данные своего кэша. Если это не так, игра окончена, и ответ на ваш вопрос «нет, это невозможно». Если это , то есть , где UIWebView кэширует данные, тогда может иметь возможность заполнить этот Cache.db файл в симуляторе, захватить файл, сохранить его в комплекте вашего приложения и затем написать кеш в соответствующее место, когда пришло время предварительно заполнить кеш.

Во всяком случае, это линия атаки, которую я бы использовал, чтобы определить, возможно ли это - я вполне уверен, что ответ будет "нет, невозможно", если не выяснится, что кеш UIWebView делает находится в песочнице вашего приложения, доступна для записи вами, и вы можете обмануть UIWebView, заменив его файл кэша.

1 голос
/ 30 ноября 2011

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

Если вы используете Chrome, это похоже на их стратегию, которую они используют, чтобы сделать просмотр немного быстрее: когда страница загружается, они сразу находят все ссылки на странице и разрешают ссылки, поэтому, если пользователь нажимает на ссылку, он отключается. не нужно ждать ответа от DNS-серверов, прежде чем увидеть страницу, как это уже сделано для них!

Надеюсь, это имело немного больше смысла.

QUOTE:

это довольно крутой вопрос. рассмотрите только то, что указано в справочнике разработчика, иначе Apple отклонит ваше приложение. Вы можете использовать принудительную загрузку в скрытом представлении, чтобы разогреть кэш. таким образом, у вас есть возможность добавлять элементы в кеш, но у вас нет возможности удалять элементы из кеша, если вы не знаете внутренних алгоритмов кеширования ... Я бы сказал, что это меньше взлома и больше техники! - Виннибад 23 ноября в 17:26

@ vinnybad: Я не совсем уверен, что вы подразумеваете под «принудительной загрузкой». Можете ли вы уточнить это? (Звучит так, что, возможно, стоит дать ответ, а не комментарий!) - Тротт 23 ноября в 17: 40

...