Aplikasi Web Full Screen

() translation by (you can also view the original English article)

Salah satu masalah pertama yang dihadapi saat membuat aplikasi web seluler dari awal adalah jumlah ruang yang digunakan oleh address bar browser. Tutorial ini akan menunjukkan cara mendapatkan kembali layar real estat yang hilang ke address bar saat memperhitungkan perubahan orientasi, masalah ketinggian konten, dan tautan dokumen internal.

Perubahan Selanjutnya pada Teknik & Software

Aspek-aspek tertentu dari aplikasi atau teknik yang digunakan dalam tutorial ini telah berubah sejak awal dipublish. Ini mungkin membuatnya agak sulit untuk diikuti. Kami sarankan untuk melihat tutorial terbaru tentang topik yang sama:

Mobiletuts+ Kategori Aplikasi Web

Mendefinisikan Masalah

Salah satu aspek paling sulit dalam mendesain perangkat seluler adalah terbatasnya ruang layar yang tersedia. Aplikasi web seluler harus ramping dan intuitif agar dapat bersaing dengan aplikasi asli, dan kehadiran interface pengguna browser sering kali hanya mengurangi pengalaman pengguna dan estetika situs secara keseluruhan.

Misalnya, perhatikan screen shot situs web seluler berikut:

Screenshot di atas diambil pada iPhone 4 dengan address bar Mobile Safari dan toolbar ditampilkan.

Sekarang lihat screenshot yang sama tanpa UI browser:

Versi iPhone dari situs tersebut memperoleh 60 piksel dengan menghapus address bar di bagian atas dan 44 piksel dengan menghapus button bar di bagian bawah untuk mendapatkan total 104 piksel logis ruang layar vertikal (jumlah ruang yang diperoleh pada perangkat Android bervariasi , tetapi hasilnya serupa). Saat mencoba membangun pengalaman mendalam, mudah untuk mengetahui dari screenshots di atas apa perbedaan besar yang dapat dibuat perubahan sekecil itu.

Sayangnya, browser web seluler utama belum memberikan metode yang mudah dan universal kepada developers untuk hanya mengaktifkan atau menonaktifkan UI browser. Namun, ada dua pendekatan umum untuk menyelesaikan pekerjaan, dan keduanya akan dibahas dalam tutorial ini.

Pendekatan Meta Tag

Jika aplikasi web Anda hanya menargetkan iOS, maka solusi yang ideal adalah mengatur tag meta berikut di bagian <head> dari dokumen HTML Anda:

1
2	<meta name="apple-mobile-web-app-capable" content="yes" />

Dengan melakukannya akan menghapus sepenuhnya address bar dan toolbar dari Mobile Safari, seperti yang ditunjukkan pada screenshot kedua di atas.

Selain fakta bahwa kode ini hanya akan bekerja dengan tepat di perangkat iOS, ada masalah besar lainnya dengan pendekatan ini: kode ini hanya akan berfungsi setelah pengguna menambahkan situs web ke layar beranda dan ketika pengguna meluncurkan situs secara mandiri. Safari Seluler.

Saya telah membaca laporan yang belum dikonfirmasi bahwa pendekatan meta tag akan benar-benar berfungsi pada beberapa perangkat Android juga, tetapi tentu saja itu tidak berfungsi pada Nexus S saya dan sepertinya tidak didukung secara resmi oleh Android sama sekali.

Ini jelas kurang ideal. Menambahkan situs web ke layar beranda iOS adalah fitur iOS yang tidak dikenal yang mungkin tidak diketahui oleh banyak pengguna dan tidak mungkin digunakan saat menjelajah web dengan santai.

Mungkin suatu hari vendor browser akan bersatu dan menyediakan meta tag lintas-platform tunggal untuk kontrol halus atas UI browser tanpa menghalangi aliran aplikasi browser web normal (seperti apa kehidupan ini jika benar-benar terjadi). Sampai saat itu, kita harus membawa barang-barang ke tangan kita dengan cara kuno yang baik: dengan menggunakan JavaScript.

Counterpoint: Mengizinkan developers untuk mengontrol keberadaan address bar dan/atau tab bar memberikan kebebasan kreatif kepada developers dengan mengorbankan kebebasan pengguna akhir dan keseluruhan pengalaman menjelajah. Tanpa pola UX yang konsisten untuk menavigasi kembali atau memasukkan URL baru, pengguna akan menjadi bingung saat menjelajah dan dalam beberapa kasus tidak dapat meninggalkan situs tanpa sepenuhnya mengatur ulang browser.

Counter-counterpoint: Membuat pola UX baru yang memberdayakan developers untuk menentukan ada atau tidaknya kontrol browser sambil secara bersamaan mempertahankan kontrol pengguna akhir atas navigasi (mungkin dengan kombinasi efek fade-in-out dan 'ketuk ganda' isyarat atau mungkin dengan memaksa aplikasi layar penuh untuk diluncurkan di jendela baru) dapat menyeimbangkan kedua minat.

Pendekatan JavaScript

Banyak frameworks aplikasi web lintas-platform yang kini tersedia bergantung pada apa yang pada dasarnya merupakan hack JavaScript sedekat mungkin untuk memberikan pengalaman layar penuh. Frameworks berikut semuanya mencakup beberapa variasi dari solusi JavaScript yang akan saya tunjukkan dalam tutorial ini:

Bagi Anda yang hanya menginginkan kode tanpa narasi:

Saya menerima kode di atas pada GitHub: Gist, jadi silakan pisahkan, modifikasi, atau sarankan perubahan. Perlu diingat bahwa ini adalah peretas yang bergantung pada browser. Hal ini mungkin berubah di masa depan. mungkin tidak mencakup setiap edge case. Ini belum diuji pada Blackberry dan Windows Phone 7.

UPDATE 9/3/2011:
Berkat feedback dari John Boxall di bawah ini, saya telah menambahkan satu lagi persyaratan dalam listener event "load". Fungsi hideAddressBar() sekarang hanya akan dipanggil jika pengguna belum mulai menggulir sebelum event "load" dipicu.

Bagi Anda yang ingin mempelajari persis bagaimana dan mengapa trik kecil yang rapi ini bekerja, baca terus!

Menjelajahi Lubang Kelinci

Intinya, jumlah trik untuk apa yang dapat diringkas menjadi satu baris JavaScript:

1
2	window.scrollTo(0, 1);

Panggilan scrollTo adalah metode objek browser window dengan signature berikut:

1
2	scrollTo(x, y);

Argumen pertama mengontrol jarak untuk scroll jendela pada x-axis dan argumen kedua mengontrol jarak untuk scroll jendela pada y-axis.

Konsep umum adalah bahwa sementara kita tidak bisa secara teknis menghapus kontrol browser dari browser web, kita dapat scroll konten viewport ke bawah untuk menghapus address bar dari jendela.

Jadi, mengapa hanya memindahkan Y-axis 1 pixel? Bukankah seharusnya 60 piksel untuk iPhone? Itu adalah pemikiran awal saya juga. Namun, address bar secara teknis bukan bagian dari viewport dokumen. Daripada benar-benar menggulir konten ke bawah 60 piksel, kita sebenarnya mengambil keuntungan dari kekhasan WebKit (bug?) Yang secara otomatis akan menghapus address bar ketika metode scrollTo dipanggil. Dalam pengujian saya, saya dapat mencapai efek yang diinginkan pada iOS dengan menetapkan nilai Y ke integer apa pun, termasuk -10, 0, 1, atau 60. Namun, di Android, hanya bilangan bulat positif yang mencapai efek yang diinginkan, karenanya menjadikan "1" offset Y terbaik untuk digunakan untuk peretasan browser.

Langkah selanjutnya adalah menentukan kapan harus memanggil metode scrollTo. Idealnya ini harus terjadi tepat setelah halaman dimuat. Semua implementasi berikut ini bekerja dalam pengujian saya dan terdaftar dalam urutan keanggunan:

Menambahkan listener event:

1
2	window.addEventListener("load", function() { window.scrollTo(0, 1); });

Menambahkan listener event inline:

1
2	<body onload="window.scrollTo(0, 1);">

Di dalam tag script tertanam (bagi yang merasa pemberontak):


    <script>
        window.scrollTo(0, 1);
    </script>
</body>
</html>

Jika Anda mencoba ketiga sampel ini di Android, semuanya akan bekerja dengan baik (meskipun contoh ketiga sangat jelek). Namun, jika Anda mencoba hal di atas di iOS, tidak ada yang terjadi.

Untuk alasan yang tidak sepenuhnya jelas bagi saya, Mobile Safari di iOS tidak mampu menerapkan hack scroll dengan salah satu dari listeners event di atas saja.

Agar ini bekerja di iOS, Anda perlu membuat sedikit penundaan antara saat listener event diaktifkan dan ketika metode scrollTo dijalankan.

Ini dapat dengan mudah dilakukan dengan metode setTimeout seperti yang ditunjukkan:


window.addEventListener("load", function()
{
    setTimeout( function(){ window.scrollTo(0, 1); }, 100 );
}

Metode signature untuk fungsi setTimeout adalah:

1
2	setTimeout(code, milliseconds, [ lang ])

Jadi, dalam contoh saya, saya menyediakan fungsi anonim yang berisi panggilan scrollTo untuk dieksekusi setelah penundaan 100 milidetik. Anehnya, hal di atas masih bekerja untuk saya terlepas dari bilangan bulat yang disediakan untuk penundaan milidetik. Ini bekerja dengan -100, 0, dan 1 serta 100. Akibatnya, rekomendasi saya adalah menggunakan 0 untuk argumen milidetik.

Pada titik ini, address bar kita yang menyembunyikan cuplikan JavaScript harus terlihat seperti salah satu contoh berikut:

Listener event:


<head>
    <title>Fullscreen Test</title>
    <script>
      window.addEventListener("load", setTimeout( function(){ window.scrollTo(0, 1) }, 0));
    </script>

Listener event Inline:

1
2	<body onload=" setTimeout( function(){ window.scrollTo(0, 1) }, 0); ">

Hebat! Jadi sekarang kita bisa beralih untuk benar-benar membangun sesuatu yang bermanfaat, bukan? Sayangnya tidak. Masih ada beberapa masalah khusus browser yang dapat merusak hack ini.

Tinggi Konten Tidak Cukup

Bagaimana jika konten Anda tidak cukup besar untuk mengisi seluruh layar? Dalam hal ini, Anda tidak akan memiliki scrollbar vertikal, dan trik yang ditunjukkan di atas tidak akan berfungsi. Selain hanya menambahkan lebih banyak konten ke halaman Anda, setidaknya ada tiga metode lain yang tidak terlalu ketat yang dapat Anda ambil untuk mengatasi masalah ini.

Opsi 1: Tetapkan `Initial-Scale`

Pendekatan pertama adalah memodifikasi initial-scale halaman web Anda sampai konten Anda memenuhi seluruh viewport. Anda dapat melakukan ini dengan tag meta berikut:

1
2	<meta name="viewport" content="width=device-width, initial-scale=1.0">

Anda harus bermain-main dengan nilai skala awal sampai Anda menemukan skala/jumlah zoom yang cocok dengan kebutuhan spesifik Anda.

Opsi 2: Tetapkan Tinggi Minimum

Pendekatan kedua adalah menggunakan atribut CSS sederhana. Anda dapat menerapkan nilai min-height yang cukup besar pada tag body atau elemen level blok lainnya di halaman Anda untuk memperhitungkan ruang putih kosong. Namun, Anda harus berhati-hati di sini karena dua alasan: nilai piksel tepat yang diperlukan oleh atribut min-height akan bervariasi tergantung pada initial-scale (yaitu pembesaran) halaman dan nilainya akan berubah jika pengguna memutar dari potret ke mode lansekap atau sebaliknya. Basic syntax untuk mengatur atribut min-height pada tag tubuh ditunjukkan di bawah ini:

1
2	body { min-height: 900px; }

Sekali lagi: nilai piksel aktual yang digunakan bergantung pada initial-scale/zoom situs Anda. Anda mungkin harus pergi cukup tinggi atau sangat rendah.

Opsi 3: Atur Ketinggian dengan JavaScript Secara Dinamis

Pendekatan ketiga adalah memeriksa secara dinamis properti document.height terhadap properti window.outerHeight dan kemudian secara dinamis meningkatkan document.height bila perlu.

Untuk mengikuti cuplikan kode JavaScript adalah solusi non-framework untuk masalah ini:


   <script>
      window.addEventListener("load", function(){  
          if(document.height <= window.outerHeight)
          {
              document.body.style.height = (window.outerHeight + 50) + 'px';
              setTimeout( function(){ window.scrollTo(0, 1); }, 50 );
          }
          else
          {
              setTimeout( function(){ window.scrollTo(0, 1); }, 0 ); 
          }
      }
      );
    </script>

Pada baris 5 di atas, saya telah menambahkan jumlah padding yang tampaknya arbitrer (+50). Ini diperlukan agar efeknya berfungsi di iOS dan Android. Saya juga harus memposisikan ulang panggilan ke setTimeout karena iOS tidak akan menghasilkan auto-scroll segera setelah mengatur document.body.style.height. Apa yang saya temukan sangat aneh adalah bahwa saya tidak hanya perlu memposisikan ulang panggilan setTimeout, tetapi untuk iOS saya juga harus menambahkan penundaan yang tampaknya sewenang-wenang sebesar +50 jika saya baru saja mengubah ketinggian dokumen. Ini tidak terjadi pada awalnya (saat menggunakan listener load tanpa menetapkan nilai baru untuk tinggi dokumen).

Tautan Internal/Anchor

Variasi pada peretasan browser di atas sudah banyak diterapkan di web. Namun, setidaknya ada satu kasus penggunaan yang memaksa browser untuk menggulir ke 0,1 adalah pendekatan yang salah: pengunjung yang datang ke situs Anda melalui anchor (a.k.a. tautan internal). Untuk mengakomodasi kasus tepi ini, Anda hanya perlu memanggil scrollTo(0, 1) jika tag hash tidak ada dalam URL. Untuk menerapkan pendekatan ini, yang harus dilakukan adalah memeriksa keberadaan nilai di window.location.hash dan kemudian menyelimuti listener event load kita dalam kondisi tersebut. Melakukan hal itu membuat kita memiliki sesuatu seperti berikut:


      if( !window.location.hash )
      {
          window.addEventListener("load", function(){  
              if(document.height <= window.outerHeight + 10)
              {
                  document.body.style.height = (window.outerHeight + 50) +'px';
                  setTimeout( function(){ window.scrollTo(0, 1); }, 50 );
              }
              else
              {
                  setTimeout( function(){ window.scrollTo(0, 1); }, 0 ); 
              }
          }
          );
      }

Perubahan Orientasi Perangkat

Masalah lain yang mungkin Anda temui berkaitan dengan perubahan orientasi perangkat. Di iOS, ketika pengguna memutar ponsel dari mode portrait ke mode landscape, offset gulir tidak akan berubah secara otomatis (Android tampaknya tidak membiarkan masalah ini). Ini berarti bahwa pengguna Anda akan ditinggalkan di suatu tempat lebih jauh ke bawah halaman dari yang dimaksudkan.

Perbaikan untuk ini adalah untuk mengatur listener event di window.onorientationchange untuk diberitahu ketika orientasi berubah, dan kemudian untuk menjalankan window.scrollTo(0, 1) memanggil lagi setelah perubahan terjadi.

Sepertinya ini saat yang tepat untuk mulai refactoring kode dengan memisahkan kode yang bertanggung jawab untuk menyembunyikan address bar menjadi fungsi independen. Setelah melakukan itu, kita pergi dengan yang berikut:


      function hideAddressBar()
      {
          if(!window.location.hash)
          { 
              if(document.height <= window.outerHeight + 10)
              {
                  document.body.style.height = (window.outerHeight + 50) +'px';
                  setTimeout( function(){ window.scrollTo(0, 1); }, 50 );
              }
              else
              {
                  setTimeout( function(){ window.scrollTo(0, 1); }, 0 ); 
              }
          }
      } 

      window.addEventListener("load", hideAddressBar );
      window.addEventListener("orientationchange", hideAddressBar );

Solusi di atas tampaknya berfungsi baik bagi saya di Android dan iOS, tetapi ada satu masalah lagi yang mungkin atau mungkin tidak relevan dengan proyek Anda: bagaimana jika pengguna telah menggulir ke bawah halaman secara signifikan sebelum mengubah orientasi perangkat? Dalam hal ini, mengatur ulang tampilan ke 0, 1 akan menyebabkan pengguna kehilangan tempat mereka dalam dokumen. Akuntansi untuk ini sangat spesifik implementasi, tetapi intinya adalah cukup menetapkan ambang y-axis dan kemudian hanya mereset gulir offset ke 0, 1 jika pengguna belum menggulir di luar ambang itu.

Mengunci Layar Address Bar

Beberapa frameworks, seperti SenchaTouch, benar-benar akan mengunci address bar dari layar dengan mencegah pengguna menggulir melampaui ambang y-axis yang diberikan. Ini tentu saja mungkin, tetapi saya tidak akan membahas bagaimana melakukannya di sini karena saya menemukan solusi ini menjadi masalah kegunaan yang signifikan, terutama di Android. Namun, jika Anda bertekad untuk mencapai efek ini, Anda mungkin perlu bereksperimen dengan atribut window.pageYOffset.

Bagaimana dengan Button Bar di iOS?

Sepengetahuan saya, saat ini tidak ada solusi untuk menghapus toolbar/button bar di iOS dari bagian bawah Mobile Safari dengan JavaScript saja. Satu-satunya cara saya sadar untuk mencapai efek ini adalah pendekatan meta tag yang dijelaskan di awal tutorial ini. Koreksi saya jika saya salah!

Membuatnya Bersyarat

Salah satu pertimbangan dengan pendekatan di atas yang belum dibahas adalah bagaimana menangani pengguna yang mengunjungi dari browser web yang bukan seluler atau tidak didukung. Ada sejumlah metode berbeda untuk menentukan browser mana yang saat ini mengakses situs Anda. Jika Anda bekerja dengan bahasa skrip sisi server, Anda mungkin ingin menentukan apakah pengguna menggunakan perangkat seluler pada saat halaman dibuat dan hanya menyediakan peretasan ini bila perlu. Mungkin pendekatan yang lebih kuat adalah melakukan pengujian secara dinamis dengan JavaScript. Menerapkan pertimbangan ini di luar cakupan tutorial ini, tetapi silakan tinggalkan saran Anda di komentar.

Caveat Emptor!

Browser hacks seperti yang saya jelaskan untuk menyembunyikan address bar tidak sesuai dengan praktik terbaik. Implementasi yang saya jelaskan dalam tutorial ini telah diuji pada Android Nexus S, iPhone 3GS, dan iPhone 4, tetapi sangat mungkin bahwa saya melewatkan case edge di suatu tempat. Saya juga sama sekali tidak yakin bahwa implementasi yang ditampilkan akan terus berfungsi seperti apa adanya di masa depan, itulah sebabnya saya cukup terkejut menemukan begitu banyak framework web utama (mis. IUI, jQuery Mobile, SenchaTouch) dan menonjol situs web (mis. Gmail, Yahoo, Apple) mengandalkan beberapa variasi custom hack ini. Alasannya, saya pikir, sederhana: solusi non-javascript yang lebih baik saat ini tidak ada.

Menyelesaikan

Saya memiliki tiga niat utama dalam menulis tutorial mendalam tentang apa yang mungkin tampak seperti masalah sepele.

Pertama, saya ingin memberikan cuplikan JavaScript murni untuk mencapai efek ini yang lebih kuat daripada kebanyakan yang saya temui. Saya harap saya telah mencapainya dengan mengakomodasi perubahan orientasi, tautan jangkar, dan masalah ketinggian konten.

Kedua, saya ingin menghilangkan beberapa keajaiban di balik bagaimana framework seperti SenchaTouch atau iUI telah memungkinkan efek ini. Ketika saya awalnya memutuskan untuk menggunakan SenchaTouch untuk proyek freelance beberapa waktu lalu, "keajaiban" framework untuk membuat aplikasi memenuhi layar adalah salah satu efek UX utama yang menarik bagi saya. Sangat penting untuk menyadari bahwa efek yang sama ini dapat dengan mudah diimplementasikan dalam JS murni terlepas dari apakah Anda memilih untuk menggunakan framework JavaScript dalam proyek Anda.

Akhirnya, alasan utama saya ingin membahas masalah ini dengan sangat terperinci adalah untuk meningkatkan kesadaran akan betapa tidak pastinya pendekatan ini. Terlepas dari kenyataan bahwa variasi trik ini telah menjadi diadopsi secara luas, saya percaya ini adalah yang terbaik dan tidak jujur dan paling buruk yang bergantung pada browser yang mungkin atau mungkin tidak terus bekerja di masa depan. Saya ingin mendorong mereka yang berada di bisnis browser dan komunitas development web / seluler secara keseluruhan untuk mendorong pendekatan independen JavaScript yang lebih berbasis standar untuk menangani pertimbangan UX ini. Saya pikir metode meta-tag yang diimplementasikan oleh Apple adalah langkah besar ke arah yang benar, tetapi, seperti disebutkan di atas, metode ini kurang memenuhi kebutuhan komunitas pengembangan.

Pertanyaan sebenarnya adalah: bagaimana menurut Anda? Mari kita bicarakan di bagian komentar di bawah ini.

Perbaiki Kode Ini

Saya tidak ragu bahwa beberapa pembaca kami mungkin dapat meningkatkan kode yang saya berikan dalam tutorial ini. Jika Anda melihat sesuatu di pos ini yang dapat dioptimalkan atau ditingkatkan, silakan tinggalkan feedback Anda di bawah ini! Anda juga dapat menghubungi saya melalui Twitter (@markhammonds), meskipun terkadang saya butuh waktu untuk menanggapi Tweet atau DM. Cara terbaik untuk menghubungi saya adalah melalui komentar di bawah ini atau dengan formulir kontak di Mobileuts+. Jika saya menerima salah satu saran Anda untuk perbaikan, saya akan memperbarui posting ini dan mengutip nama atau alamat Anda!

Referensi

Tidak ingin menerima kata-kata saya untuk hal-hal di atas?

Lihatlah sumber-sumber berikut yang saya temui saat meneliti posting ini:

Mengonfigurasi Aplikasi Web, Safari Developer Library
"Mobifying" Situs HTML5 Anda, Eric Bidelman
Sembunyikan Address Bar dalam Aplikasi Web Seluler, David Walsh
iPhone WebApps 101: Menghindari Safari, Niels Leenheer