2012-05-09 22 views
7

Mam interfejs WWW/kontrolny Asp.Net 4.0, który używa panelu aktualizacji i niektórych przycisków. Panel aktualizacji jest połączony z zegarem, który wykonuje się co 5 sekund, powodując częściowy odświeżenie. Przyciski przełącza niektóre ustawienia, a następnie wymusza aktualizację panelu aktualizacji poprzez wywołanie podobnego do tego:Odrzucenie Ajaxa ASP.NET nagle zatrzymuje się na IPhone/IPad

var prm = Sys.WebForms.PageRequestManager.getInstance(); 
prm._doPostBack('<%= UpdatePanel.ClientID %>', ''); 
return true; 

Witryna działa poprawnie na IE/Firefox i na urządzeniach mobilnych Safari (iPhone/iPad), ale na telefon komórkowy urządzenia odrzucają losowo i po cichu przestają działać. Myślę, że to może mieć do czynienia z oszczędzaniem baterii i że safari zatrzymuje częściowy odrzut, gdy jest bezczynny. Problem polega na tym, że gdy użytkownik wraca do witryny, oddzwonienie jest całkowicie wyłączone i ani licznik czasu, ani przyciski nie powodują żadnych zwrotów. (Monitorowałem ruch sieciowy na serwerze, aby to zweryfikować). Nawet jeśli użytkownik odświeży stronę (kilka razy), częściowy oddzwonienie powraca do gry. Po prostu zatrzymuje wysyłanie danych na serwer. Nagle i bez żadnego konkretnego powodu oddzwonienie zaczyna działać ponownie. Czas przestoju wynosi często do 10 minut, co całkowicie uniemożliwia korzystanie z mojej witryny.

Biorąc pod uwagę, że to trwa tak długo, zanim odświeżenie zaczyna się od nowa, zastanawiam się, czy istnieją jakieś ustawienia po stronie klienta lub w IIS do zabawy?

Witryna będzie działać tylko na urządzeniach moich klientów, nie jest dostępna publicznie, więc jeśli są jakieś ustawienia do zabawy na kliencie, jestem na nią gotowy.

Jestem bardzo zdezorientowany i nie znalazłem sposobu na wywołanie "błędu", czasami się to zdarza. Wszelkie porady i wskazówki są mile widziane.


Aktualizacja:

Dodane niektóre obsługi błędów i mam (nie konsekwentnie) pojawia się następujący komunikat, gdy odświeżenie strony nie powiedzie się:

Strona jest wykonywania odświeżenie strony async ale ScriptManager. Właściwość SupportParialRendering ma wartość false. Upewnij się, że właściwość jest ustawiona na wartość true podczas odświeżania.

To wystarczy, oczywiście, że ta właściwość jest prawdziwa dla urządzenia, w przeciwnym razie oddzwonienie nigdy nie zadziałałoby, co nie jest prawdą.


Aktualizacja 2: Okazało się, że folloing blogu sugerujące zmianę browserCap ustawienie w pliku web.config. Próbuję tego teraz. Złoży raport. Inne sugestie są nadal bardzo mile widziane. ASP.NET 4 BrowserCaps (or: what were they thinking?)

Powyższe wyłącza javascript w Safari mobile w trybie pełnoekranowym (z ekranu głównego). Poniższy artykuł sugeruje poprawkę dotyczącą tego problemu. Gotcha: iPad versus ASP.NET

Odpowiedz

6

Wyniki w punkcie "aktualizacja 2" w moim pytaniu rozwiązują problem. Widocznie nagłówki UserAgent Safari czasami uznawane za Mozilla 0.0, jak określono w poniższym poście: ASP.NET 4 BrowserCaps (or: what were they thinking?):

Pierwszy WTF jest, że ramy .NET rzeczywiście zgłasza wyjątek, jeśli wykryje odświeżenie asynchronicznej z przeglądarką, że zgodnie do BrowserCaps nie obsługuje odświeżenia async.To tak, jakby sądzili, że wiedzą najlepiej, kto jest zdolny do asynchronicznych zwrotów, nawet przy przytłaczających dowodach przeciwnych ...

Następna WTF była znacznie trudniejsza do znalezienia. Dlaczego Safari UserAgents jest czasami uznawane za Mozillę 0.0 i dlaczego nigdy nie udało mi się odtworzyć problemu nawet przy użyciu ciągu UserAgent, który właśnie skopiowałem z wyjątku?

Odpowiedź leży w

<browserCaps userAgentCacheKeyLength="64" />

Ustawienie domyślne dla agenta użytkownika cache długości klucza jest podjęcie pierwszych 64 znaków ciągu identyfikującego. ...

i dalej w dół strony:

Ustawianie userAgentCacheKeyLength 256 rozwiązał problem, choć nadal istnieją userAgent struny, które obecnie nie są zidentyfikowane jako Mozilla 0.0. Przynajmniej teraz jest spójny.

Umieszczenie <browserCaps userAgentCacheKeyLength="256" /> w Web.Config rozwiązuje problem.


To niestety powoduje kolejny problem gdy przeglądarka Safari jest używany w trybie pełnoekranowym (link zapisanego na ekranie głównym). W trybie pełnoekranowym Safari używa innego ciągu agenta użytkownika HTTP, a ASP.NET już nie rozpoznaje przeglądarki jako Safari, zamiast tego rozpoznaje ją jako przeglądarkę ogólną bez możliwości i na przykład JavaScript i JQuery przestaną działać. Jest on dalej opracowywany w Gotcha: iPad versus ASP.NET. Rozwiązaniem jest umieszczenie następujących elementów w Page_Init na każdej stronie internetowej. Niezbyt elegancki, ale działa razem z powyższym:

protected void Page_PreInit(object sender, EventArgs e) 
{ 
    if (Request.UserAgent != null && Request.UserAgent.IndexOf("AppleWebKit", StringComparison.CurrentCultureIgnoreCase) > -1) 
    { 
     this.ClientTarget = "uplevel"; 
    } 
} 
+0

Dzięki @Avada Kedavra! Gdyby ten dokładnie ten sam problem, naprawił go '. Bardzo doceniane! Nie wstawiłem jeszcze sekcji 'Page_PreInit', czy można to po prostu umieścić na stronie MasterPage, pozwala na przepracowanie wszystkich stron? –

+0

@mcpDESIGNS: Nie próbowałem tego, ale interesuje mnie jakikolwiek sposób, który sprawi, że rozwiązanie będzie lepsze z mniejszym kodem. Czy udało Ci się osiągnąć sukces z podejściem, które sugerujesz? –

+0

Będę musiał zrobić więcej testów na tym i dam ci znać! Chciałem po prostu wstawić 'Page_PreInit' na stronie wzorcowej, abyś nie musiał go kopiować/wklejać na każdej stronie podrzędnej. –