Веб-приложение для iPhone - сеанс и текущий URL-адрес теряются при ответе на вызов

У меня есть многостраничный веб-сайт, который предназначен для работы в качестве веб-приложения на iPhone.

Он имеет обычное:

<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no, minimum-scale=1.0, maximum-scale=1.0" />
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="default" />
<link rel="apple-touch-icon" href="/apple-touch-icon.png" />
<link rel="apple-touch-startup-image" href="/images/startup.png" /> 

Сайт не использует Sencha или Javascript для навигации между страницами, только стандартные якорные ссылки и перезагрузку страницы (я знаю, что стандартный подход к веб-приложениям заключается в использовании интерфейса, подобного Sencha).

Он отлично работает при запуске с домашнего экрана iPhone и работает так же, как при просмотре через Safari.

Однако проблема возникает, когда на телефонный звонок отвечают в середине сеанса.

После завершения вызова iPhone (в данном случае версия 4) возвращается обратно к веб-приложению, но вместо восстановления ранее просмотренной страницы перезагружает домашний экран (та же страница, которая загружается при запуске веб-приложения). )

При просмотре сайта в Safari и принятии вызова он этого не делает и сохраняет URL-адрес и текущие значения сеанса.

Это известная проблема в веб-приложениях? Есть ли обходной путь?

(у меня есть идея сохранить значения сеанса и URL-адреса в локальной базе данных SQLite, но я не уверен, что это лучший подход)


person Peter    schedule 05.10.2011    source источник
comment
Я немного погуглил, потому что меня интересовала эта тема. Похоже, это ограничение веб-приложений на iPhone, и вам придется кодировать его.   -  person Krumelur    schedule 05.10.2011
comment
Вы нашли решение своей проблемы?   -  person Christian80    schedule 14.03.2012
comment
Пока нет, но ответ Will0 ниже может сработать   -  person Peter    schedule 31.01.2013
comment
Просто сменил имя пользователя; Питер имеет в виду мой ответ.   -  person Wilbo Baggins    schedule 31.01.2013


Ответы (3)


Хитрость заключается в том, чтобы сделать это:

// Start or resume session
session_start(); 

// Extend cookie life time by an amount of your liking
$cookieLifetime = 365 * 24 * 60 * 60; // A year in seconds
setcookie(session_name(),session_id(),time()+$cookieLifetime);

Я проверил это на iOS 4.2.1, 5.1.1, 6.0 и 6.1. Сессия восстанавливается даже после выключения и перезагрузки устройства.

Для более подробного обсуждения этой стратегии вы можете взглянуть на мой ответ на этот вопрос: Поддерживать сеанс PHP в веб-приложении на iPhone

person Wilbo Baggins    schedule 30.01.2013

Вместо того, чтобы хранить информацию для входа в переменную $_SESSION, сохраните ее в $_COOKIE. Файл cookie будет сохранен в зависимости от того, когда вы установите срок его действия. Пока они входят «внутри» веб-приложения или обычной веб-версии (и файл cookie один и тот же), им не нужно будет входить в систему каждый раз или при переключении между ними.

person adamdehaven    schedule 10.03.2012

У меня была такая же проблема с моим WebApp под iOS v10. Это не было проблемой сеанса и / или файла cookie (механизм сеанса был в порядке, основанный на файле cookie с достаточным временем жизни).

Проблема заключается в том, что при работе в режиме WebApp (т. е. при запуске приложения с ярлыка на рабочем столе, а не в Safari) «контекст» теряется при переключении на другое приложение (например, при ответе на звонок). Когда вы вернетесь в приложение, запрошенный URL-адрес будет не последним, а URL-адресом, сохраненным в ярлыке на рабочем столе...

В моем случае ярлык был сделан с экрана входа в систему, поэтому каждый раз, когда я возвращался к своему приложению из другого приложения, это был URL-адрес /login... Похоже, я вышел из системы...

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

person David    schedule 20.06.2017