iOS 8 usunął właściwość okna „minimalnego interfejsu użytkownika”, czy istnieją inne rozwiązania „miękkiego ekranu pełnoekranowego”?

(To pytanie składa się z wielu części, postaram się jak najlepiej podsumować scenariusz.)

Obecnie tworzymy responsywną aplikację internetową (czytnik wiadomości), która pozwala użytkownikom przesuwać zawartość między kartami, a także przewijać zawartość kart w pionie.

Powszechnym podejściem do problemu jest posiadanie opakowania divwypełniającego okno przeglądarki, ustawionego overflowna hiddenlub auto, a następnie przewijanie w nim poziomo i / lub pionowo.

To podejście jest świetne, ale ma jedną główną wadę: ponieważ wysokość dokumentu jest dokładnie taka sama jak w oknie przeglądarki, przeglądarka mobilna nie ukryje paska adresu / menu nawigacji .

Istnieje wiele hacków i właściwości rzutni, które pozwalają nam uzyskać więcej nieruchomości na ekranie, ale żadne z nich nie jest tak skuteczne jak minimal-ui(wprowadzone w iOS 7.1).

Wczoraj pojawiły się wiadomości, że iOS 8 beta4 został usunięty minimal-uiz Mobile Safari (patrz sekcja Webkit w Informacjach o wersji iOS 8 ), co nas zastanawiło:

Pytanie 1 Czy nadal można ukryć pasek adresu w Mobile Safari?

O ile wiemy, iOS 7 nie reaguje już na window.scrollTowłamanie, co sugeruje, że musimy żyć z mniejszą powierzchnią ekranu, chyba że zastosujemy pionowy układ lub użycie mobile-web-app-capable.

Q2 Czy nadal można uzyskać podobny miękki ekran pełnoekranowy?

Przez miękki pełny ekran naprawdę mam na myśli bez używania mobile-web-app-capablemetatagu.

Nasza aplikacja internetowa została zbudowana tak, aby była dostępna, każda strona może być dodana do zakładek lub udostępniona za pomocą natywnego menu przeglądarki. Dodając mobile-web-app-capable, uniemożliwiamy użytkownikom wywoływanie takiego menu (gdy jest ono zapisywane na ekranie głównym), co dezorientuje użytkowników.

minimal-uiniegdyś znajdował się na środku ziemi, domyślnie ukrywając menu, ale utrzymując je dostępnym za dotknięciem - chociaż Apple mógł je usunąć z powodu innych problemów z dostępnością (takich jak użytkownicy nie wiedzą, gdzie dotknąć, aby aktywować menu).

Pytanie 3 Czy warto pracować na pełnym ekranie?

Wygląda na to, że pełnoekranowy interfejs API nie pojawi się w najbliższym czasie na iOS, ale nawet jeśli tak jest, nie widzę, jak menu będzie dostępne (to samo dotyczy Chrome na Androida).

W takim przypadku być może powinniśmy po prostu opuścić mobilne safari i uwzględnić wysokość ekranu (dla iPhone'a 5+, to 460 = 568 - 108, gdzie 108 zawiera pasek systemu operacyjnego, pasek adresu i menu nawigacji; dla iPhone 4 lub starszy, to 372).

Bardzo chciałbym usłyszeć kilka alternatyw (oprócz tworzenia aplikacji natywnej).

Właściwość rzutni minimal-ui nie jest już obsługiwana w systemie iOS 8. Jednak sama minim-ui nie zniknęła. Użytkownik może wprowadzić minimalny interfejs użytkownika gestem „przeciągnij w dół”.

Istnieje kilka warunków wstępnych i przeszkód w zarządzaniu stanem widoku, np. Aby minimalny interfejs użytkownika działał, musi istnieć wystarczająca ilość treści, aby umożliwić użytkownikowi przewijanie; aby minim-ui mógł zostać zachowany, przewijanie okna musi być przesunięte przy ładowaniu strony i po zmianie orientacji. Jednak nie ma sposobu na obliczenie wymiarów minim-ui przy użyciu screenzmiennej, a zatem nie ma sposobu na określenie , kiedy użytkownik jest w minim-ui z góry.

Te obserwacje są wynikiem badań w ramach rozwoju Brim - view managera dla iOS 8 . Implementacja końcowa działa w następujący sposób:

Po załadowaniu strony Brim utworzy element bieżni. Element bieżni służy do zapewnienia użytkownikowi miejsca do przewijania. Obecność elementu bieżni zapewnia, że ​​użytkownik może wejść do widoku minimalnego interfejsu użytkownika i że będzie się on utrzymywać, jeśli użytkownik ponownie załaduje stronę lub zmieni orientację urządzenia. Przez cały czas jest niewidoczny dla użytkownika. Ten element ma identyfikatorbrim-treadmill .

Po załadowaniu strony lub po zmianie orientacji, Rondo używa Krzyku aby wykryć, czy strona jest w widoku minimalnego interfejsu użytkownika (strona, która była poprzednio w minimalnym interfejsie użytkownika i została ponownie załadowana, pozostanie w minimalnym interfejsie użytkownika, jeśli wysokość zawartości wynosi większa niż wysokość rzutni).

Gdy strona jest w minimalnym interfejsie użytkownika, Brim wyłączy przewijanie dokumentu (robi to w bezpieczny sposób , który nie wpływa na zawartość głównego elementu). Wyłączenie przewijania dokumentów zapobiega przypadkowemu pozostawieniu minimalnego interfejsu użytkownika podczas przewijania w górę. Zgodnie z oryginalną specyfikacją iOS 7.1, stuknięcie górnego paska przywraca resztę chrome.

Wynik końcowy wygląda następująco:

Ze względu na dokumentację i jeśli wolisz napisać własną implementację, warto zauważyć, że nie można użyć Krzyku do wykrycia, czy urządzenie znajduje się w minimalnym interfejsie użytkownika bezpośrednio po zdarzeniu zmiany orientacji , ponieważ windowwymiary nie odzwierciedlają nowej orientacji, dopóki animacja rotacji zakończyła się. Musisz dołączyć słuchacza do zmiany orientacji zdarzenia .

W ramach tego projektu opracowano krzyk i zmianę orientacji .

Ponieważ nie ma programowego sposobu naśladowania minimal-ui, opracowaliśmy inne obejście, wykorzystujące calc()i znaną wysokość paska adresu iOS na naszą korzyść:

Następująca strona demonstracyjna ( dostępna również w Gist, tam więcej szczegółów technicznych ) poprosi użytkownika o przewinięcie, co następnie uruchomi miękki pełny ekran (ukryj pasek adresu / menu), w którym nagłówek i treść wypełnią nową rzutnię.

<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Scroll Test</title>

    <style>
        html, body {
            height: 100%;
        }

        html {
            background-color: red;
        }

        body {
            background-color: blue;
            margin: 0;
        }

        div.header {
            width: 100%;
            height: 40px;
            background-color: green;
            overflow: hidden;
        }

        div.content {
            height: 100%;
            height: calc(100% - 40px);
            width: 100%;
            background-color: purple;
            overflow: hidden;
        }

        div.cover {
            position: absolute;
            top: 0;
            left: 0;
            z-index: 100;
            width: 100%;
            height: 100%;
            overflow: hidden;
            background-color: rgba(0, 0, 0, 0.5);
            color: #fff;
            display: none;
        }

        @media screen and (width: 320px) {
            html {
                height: calc(100% + 72px);
            }

            div.cover {
                display: block;
            }
        }
    </style>
    <script>
        var timeout;

        window.addEventListener('scroll', function(ev) {

            if (timeout) {
                clearTimeout(timeout);
            }

            timeout = setTimeout(function() {

                if (window.scrollY > 0) {
                    var cover = document.querySelector('div.cover');
                    cover.style.display = 'none';
                }

            }, 200);

        });
    </script>
</head>
<body>

    <div class="header">
        <p>header</p>
    </div>
    <div class="content">
        <p>content</p>
    </div>
    <div class="cover">
        <p>scroll to soft fullscreen</p>
    </div>

</body>
</html>

Po prostu pożegnaj się z minimal-ui (na razie)

To prawda, minimal-uimoże być zarówno użyteczne, jak i szkodliwe, i przypuszczam, że kompromis ma teraz inną równowagę na korzyść nowszych, większych iPhone'ów.

Zajmowałem się tym problemem podczas pracy z moją strukturą js dla aplikacji HTML5. Po wielu próbach rozwiązań, z których każde ma swoje wady, poddałem się rozważeniu utraty miejsca na iPhone'ach wcześniejszych niż 6. Biorąc pod uwagę sytuację, uważam, że jedynym solidnym i przewidywalnym zachowaniem jest z góry określone.

Krótko mówiąc, udało mi się zapobiec jakiejkolwiek formie minimalnego interfejsu użytkownika , więc przynajmniej moja wysokość ekranu jest zawsze taka sama i zawsze wiesz, ile faktycznie masz miejsca na aplikację.

Z czasem wystarczająca ilość użytkowników będzie miała więcej miejsca.

EDYTOWAĆ

Jak to robię

Jest to trochę uproszczone, do celów demonstracyjnych, ale powinno działać dla Ciebie. Zakładając, że masz główny pojemnik

html, body, #main {
  height: 100%;
  width: 100%;
  overflow: hidden;
}
.view {
  width: 100%;
  height: 100%;
  overflow: scroll;
}

Następnie:

1. następnie za pomocą js ustawiam #mainwysokość na dostępną wysokość okna. Pomaga to również w radzeniu sobie z innymi błędami przewijania występującymi zarówno w systemie iOS, jak i Android. Oznacza to również, że musisz poradzić sobie z tym, jak go zaktualizować, pamiętaj, że;

2. Po przekroczeniu granic zwoju blokuję nadmierne przewijanie. Ten jest trochę głębszy w moim kodzie, ale myślę, że możesz równie dobrze przestrzegać zasady tej odpowiedzi dla podstawowej funkcjonalności. Myślę, że może trochę trzepotać, ale wykona zadanie.

Zobacz demo (na iPhonie)

Na marginesie: ta aplikacja również jest godna uwagi, ponieważ korzysta z wewnętrznego routingu do mieszania adresów, ale dodałem również monit dla użytkowników iOS, aby dodać do domu. Uważam, że w ten sposób pomaga lojalność i powracających gości (a więc utracona przestrzeń powraca).

Najłatwiejszym sposobem, aby to naprawić, było ustawienie wysokości elementów body i HTML na 100,1% dla każdego żądania, w którym agentem użytkownika był iPhone. Działa to tylko w trybie poziomym, ale to wszystko, czego potrzebowałem.

html.iphone, 
html.iphone body { height: 100.1%; }

Sprawdź to na https://www.360jungle.com/virtual-tour/25

Głównym problemem tutaj wydaje się, że safari na iOS8 nie ukryje paska adresu podczas przewijania w dół, jeśli zawartość jest równa lub mniejsza niż rzutnia.

Jak już się dowiedziałeś, dodanie dopełnienia na dole omija ten problem:

html {
    /* enough space to scroll up to get fullscreen on iOS8 */
    padding-bottom: 80px;
}

// sort of emulate safari's "bounce back to top" scroll
window.addEventListener('scroll', function(ev) {
    // avoids scrolling when the focused element is e.g. an input
    if (
        !document.activeElement
        || document.activeElement === document.body
    ) {
        document.body.scrollIntoViewIfNeeded(true);
    }
});

Powyższy css powinien być warunkowo zastosowany, na przykład z dodawaniem gt-ios8klasy przez sniffing UA <html>.

Chcę skomentować / częściowo odpowiedzieć / podzielić się swoimi przemyśleniami. Używam techniki overflow-y: scroll do dużego mojego nadchodzącego projektu. Korzystanie z niego ma dwie GŁÓWNE zalety.

a) Możesz użyć szuflady z przyciskami akcji u dołu ekranu; jeśli dokument przewinie się, a dolny pasek zniknie, stuknięcie przycisku znajdującego się na dole ekranu spowoduje najpierw wyświetlenie dolnego paska, a następnie kliknięcie. Również sposób, w jaki to działa, powoduje problemy z modami, które mają przyciski na samym dole.

b) Gdy używasz przepełnionego elementu, jedyne rzeczy, które są odmalowywane w przypadku poważnych zmian css, to te na widocznym ekranie. To dało mi ogromny wzrost wydajności podczas używania javascript do zmiany css wielu elementów w locie. Na przykład, jeśli masz listę 20 elementów, które wymagają odmalowania, a tylko dwa z nich znajdują się na ekranie w przepełnionym elemencie, tylko te zostaną przemalowane, a pozostałe zostaną przemalowane podczas przewijania. Bez tego wszystkie 20 elementów jest przemalowywanych.

.. oczywiście zależy to od projektu i jeśli potrzebujesz którejkolwiek z wymienionych przeze mnie funkcji. Google używa przepełnionych elementów dla Gmaila, aby korzystać z funkcji opisanych w punkcie a). Imo, warto poświęcić chwilę, nawet biorąc pod uwagę niewielką wysokość starszych telefonów (372px, jak powiedziałeś).

Jest to możliwe, używając czegoś takiego jak poniższy przykład, który przygotowałem przy pomocy pracy z ( https://gist.github.com/bitinn/1700068a276fb29740a7 ), która nie całkiem działała na iOS 11:

Oto zmodyfikowany kod, który działa na iOS 11.03, proszę o komentarz, jeśli zadziałał.

Kluczem jest zwiększenie rozmiaru BODY, aby przeglądarka mogła przewijać, np .: wysokość: calc (100% + 40px);

Pełna próbka poniżej i link do wyświetlenia w przeglądarce (przetestuj!)

<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>CodeHots iOS WebApp Minimal UI via Scroll Test</title>

    <style>
        html, body {
            height: 100%;
        }
        html {
            background-color: red;
        }
        body {
            background-color: blue;
            /* important to allow page to scroll */
            height: calc(100% + 40px);
            margin: 0;
        }
        div.header {
            width: 100%;
            height: 40px;
            background-color: green;
            overflow: hidden;
        }
        div.content {
            height: 100%;
            height: calc(100% - 40px);
            width: 100%;
            background-color: purple;
            overflow: hidden;
        }
        div.cover {
            position: absolute;
            top: 0;
            left: 0;
            z-index: 100;
            width: 100%;
            height: 100%;
            overflow: hidden;
            background-color: rgba(0, 0, 0, 0.5);
            color: #fff;
            display: none;
        }
        @media screen and (width: 320px) {
            html {
                height: calc(100% + 72px);
            }
            div.cover {
                display: block;
            }
        }
    </style>
    <script>
        var timeout;

        function interceptTouchMove(){
            // and disable the touchmove features 
            window.addEventListener("touchmove", (event)=>{
                if (!event.target.classList.contains('scrollable')) {
                    // no more scrolling
                    event.preventDefault();
                }
            }, false); 
        }

        function scrollDetect(event){
            // wait for the result to settle
            if( timeout ) clearTimeout(timeout);

            timeout = setTimeout(function() {
                console.log( 'scrolled up detected..' );
                if (window.scrollY > 35) {
                    console.log( ' .. moved up enough to go into minimal UI mode. cover off and locking touchmove!');
                    // hide the fixed scroll-cover
                    var cover = document.querySelector('div.cover');
                    cover.style.display = 'none';

                    // push back down to designated start-point. (as it sometimes overscrolls (this is jQuery implementation I used))
                    window.scrollY = 40;

                    // and disable the touchmove features 
                    interceptTouchMove();

                    // turn off scroll checker
                    window.removeEventListener('scroll', scrollDetect );                
                }
            }, 200);            
        }

        // listen to scroll to know when in minimal-ui mode.
        window.addEventListener('scroll', scrollDetect, false );
    </script>
</head>
<body>

    <div class="header">
        <p>header zone</p>
    </div>
    <div class="content">
        <p>content</p>
    </div>
    <div class="cover">
        <p>scroll to soft fullscreen</p>
    </div>

</body>

Pełny przykładowy link tutaj: https://repos.codehot.tech/misc/ios-webapp-example2.html

Możliwe jest uruchomienie aplikacji internetowej na pełnym ekranie zarówno na iOS, jak i Androidzie, nazywa się to PWA i po ciężkiej pracy było to jedyne rozwiązanie tego problemu.

PWA otwierają wiele interesujących opcji rozwoju, których nie można przegapić. Zrobiłem już parę, sprawdź ten Publiczny i prywatny podręcznik przetargowy dla projektantów (hiszpański). A oto angielskie wyjaśnienie ze strony CosmicJS

Nie zrobiłem projektowania stron internetowych na iOS, ale z tego, co pamiętam, widziałem podczas sesji WWDC i dokumentacji, pasek wyszukiwania w Mobile Safari i paski nawigacyjne w systemie operacyjnym będą teraz automatycznie zmieniać rozmiar i zmniejszać się, aby wyświetlać więcej treści.

Możesz to przetestować w Safari na iPhonie i zauważyć, że po przewinięciu w dół, aby zobaczyć więcej treści na stronie, pasek nawigacji / wyszukiwania jest automatycznie ukryty.

Być może pozostawienie paska adresu / paska nawigacyjnego w niezmienionym stanie i nie tworzenie pełnego ekranu jest tym, co najlepsze. Nie widzę, żeby Apple robił to w najbliższym czasie. I co najwyżej nie kontrolują automatycznie, kiedy pasek adresu pokazuje / ukrywa się.

Oczywiście tracisz nieruchomości ekranowe, szczególnie na iPhonie 4 lub 4S, ale wydaje się, że nie ma alternatywy od wersji Beta 4.