Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. ActionScript

AS3 101: Event - Basix

by
Difficulty:BeginnerLength:LongLanguages:
This post is part of a series called AS3 101.
AS3 101: OOP - Introducing Design Patterns
AS3 101: Quick Tip - Dispatching Events Without Extending EventDispatcher

Indonesian (Bahasa Indonesia) translation by Suci Rohini (you can also view the original English article)

Untuk bab AS3 101 ini, kita akan terjun ke mekanisme sistem acara Flash. Jika Anda telah mengikuti sejauh ini, Anda akan melihat acara yang sedang digunakan, kembali ke episode pertama seri. Editor dan saya merasa sudah waktunya untuk menulis sesuatu untuk dimasukkan secara formal ke dalam kurikulum, jadi jika Anda pernah melihat baris kode tentang menambahkan pendengar acara atau mengirim acara, dan tidak cukup tertarik, maka ini adalah tutorial untuk Anda.

Di sana sudah ada tutorial Activetuts+ tentang dasar-dasar Acara, jadi fokus tutorial ini adalah pada pengiriman acara dari kelas Anda sendiri, termasuk membuat jenis dan objek acara khusus.

Agar berhasil dengan tutorial ini, Anda harus merasa nyaman dengan menulis dan menggunakan kelas Anda sendiri di ActionScript 3, serta merasa aman dengan menggunakan acara yang ada yang disediakan oleh Flash, seperti MouseEvent.CLICK atau Event.ENTER_FRAME. Kita akan fokus terutama pada pengiriman acara khusus dari kelas khusus.


Preview

Kita akan menghabiskan banyak waktu pada teori untuk tutorial ini, tetapi pada akhirnya kita akan membangun kontrol slider sederhana yang mengirimkan acara sendiri:


Langkah 1: Mengapa Menggunakan Pengiriman Acara?

Contoh ini sebenarnya adalah contoh yang agak sederhana mengapa Anda ingin mengirim acara Anda sendiri. Ketika Anda menulis kelas Anda sendiri, Anda idealnya menyimpannya di kotak hitam mereka sendiri dan dienkapsulasi. Tetapi Anda masih perlu memiliki berbagai objek yang saling beroperasi untuk membuat program yang bermanfaat.

Model acara yang disediakan oleh ActionScript 3 adalah cara yang agak baik dan nyaman untuk memfasilitasi komunikasi antara kelas Anda, sambil mempertahankan pemisahan tanggung jawab di kelas Anda. Jadi, jika kita menulis kelas khusus kita sendiri, seperti kelas ActiveSlider yang ditampilkan di atas, kita perlu mengaktifkan objek lain untuk mengetahui kapan slider mengubah nilainya. Jika slider dapat mengirimkan perubahan acara sendiri, maka objek lain yang perlu tahu bahwa informasi dapat dengan mudah berlangganan dan diberitahu.

Secara pribadi, saya menemukan kebutuhan untuk mengirimkan acara saya sendiri di kelas saya begitu umum sehingga template kelas saya mengatur setiap kelas baru dengan boilerplate yang dibutuhkan untuk dapat melakukannya. Saat Anda belajar untuk menjaga objek tetap terpisah, Anda akan beralih ke pengiriman peristiwa sebagai teknik yang paling umum untuk melakukannya.


Langkah 2: Cara Mengirim Acara Anda Sendiri

Saya punya kabar baik: mengirimkan acara Anda sendiri sebenarnya sangat sederhana. Ini adalah salah satu prinsip inti dari ActionScript 3, yang dibangun di dalam Flash Player, dan dengan demikian hanya ada satu hal yang perlu Anda lakukan untuk mendapatkan kemampuan untuk mengirim acara. Yang ini adalah:

Perpanjang EventDispatcher

Itu saja: saat menulis kelas Anda, gunakan baris:

Tentu saja, Anda perlu mengimpor EventDispatcher, yang ada dalam paket flash.events. Anda kemungkinan besar akan membutuhkan kelas-kelas lain dalam paket, jadi mungkin lebih mudah untuk hanya mengimpor paket dengan wildcard.


Langkah 3: Pengiriman

Sekarang Anda siap untuk mengirim acara. Yang perlu Anda lakukan sekarang adalah memanggil metode yang disediakan oleh EventDispatcher bernama dispatchEvent. Mudah dipahami, bukan?

Saat Anda memanggil dispatchEvent, Anda harus memberikan setidaknya satu argumen, sebuah objek Event. Semua objek Event bawaan ada dalam paket flash.events, jadi di sinilah impor wildcard berguna. Setiap jenis objek Event akan memiliki persyaratannya sendiri, tetapi paling sering Anda hanya perlu memberikan satu argumen saja. Argumen ini adalah jenis acara, yang merupakan String yang menamai acara tersebut, seperti "click" atau "complete". Ini lebih umum ditulis sebagai MouseEvent.CLICK atau Event.COMPLETE, tetapi hasil akhirnya sama; itu adalah pengidentifikasi yang memisahkan satu jenis acara dari yang lain, dan memungkinkan satu objek Event untuk mengelola beberapa jenis acara.

Jadi, selesaikan semuanya, jika Anda ingin mengirim acara "complete", Anda bisa melakukannya seperti ini:

Letakkan saja baris itu (atau yang seperti itu) di metode mana pun yang sesuai di kelas Anda. Kelas Anda kemudian akan menggunakan sistem pengiriman acara warisannya dan setiap pendengar akan diberi tahu untuk Anda. Berbicara tentang pendengar, mari kita melihat sekilas pada mereka juga.


Langkah 4: Dengarkan

Objek lain di aplikasi Anda dapat mendengarkan acara khusus Anda sekarang. Berita bagus lainnya: ini tidak berbeda dengan mendaftar untuk acara untuk kelas bawaan. Pada langkah sebelumnya, kita mengatur kelas hipotetis untuk mengirimkan acara COMPLETE. Untuk mendengarkan acara itu, kita dapat menulis baris ini di tempat lain di program:

Dan itu saja. Ini seharusnya terlihat familier bagi siapa saja yang menghubungkan pendengar COMPLETE ke Loader, misalnya, jadi saya tidak akan membahas lebih jauh tentang ini.


Langkah 5: Tempat Pengiriman

Di mana Anda benar-benar menempatkan baris kode dispatchEvent memerlukan beberapa pertimbangan. Biasanya, ini harus menjadi baris kode terakhir dari metode yang ditulisnya. Ini agar setiap kode lain yang juga berjalan dalam metode itu dapat mengatur properti atau memperbarui keadaan internal objek. Dengan mengirimkan setelah pembaruan internal ini selesai, objek dalam keadaan "bersih" pada saat pengiriman.

Pertimbangkan, misalnya, contoh kerja kita. Katakanlah acara COMPLETE adalah tentang pemrosesan beberapa data; sekelompok data yang sangat besar sehingga akan membutuhkan beberapa detik untuk sepenuhnya diproses, sehingga tujuan objek adalah untuk menangani pemrosesan secara tidak sinkron agar tidak memblokir UI. Dan kita mengirimkan acara COMPLETE sebagai cara untuk mengatakan bahwa data telah diproses.

Sekarang anggaplah bahwa metode utama yang dimaksud terlihat seperti ini:

OK, tidak terlalu realistis, tetapi menggambarkan intinya. Kita terus membangun data internal sampai beberapa logika internal lainnya menentukan kita selesai, pada titik mana kita kemudian menulis beberapa bit data akhir untuk menutup operasi.

Sekarang, mari tambahkan panggilan dispatchEvent:

Apa masalah dengan pendekatan ini? Kode apa pun yang dijalankan di dalam pendengar untuk acara COMPLETE akan berjalan sebelum metode closeData dipanggil. Oleh karena itu, keadaan operator berubah lebih dari sekali dalam rentang metode processDataChunk, dan tidak "stabil" sampai setelah panggilan closeData. Namun, kita memberi tahu semua pendengar bahwa kita sudah lengkap sebelum panggilan itu. Ini dapat menyebabkan beberapa bug yang sulit dilacak di mana satu objek mengklaim sebagai COMPLETE tetapi sebenarnya tidak. Solusi yang jelas adalah mengganti beberapa jalur:


Langkah 6: Acara Kustom

Anda siap untuk mengirimkan acara Anda sendiri. Sekarang, apa yang harus Anda kirim? Ada beberapa opsi untuk dipertimbangkan:

  1. Cukup gunakan kembali objek acara dan jenis acara yang sudah disediakan oleh Flash Player
  2. Menggunakan kembali objek acara yang ada, tetapi memberikan jenis acara khusus
  3. Kirim ulang acara yang sudah ada
  4. Buat objek acara khusus
  5. Push vs. pull

Opsi pertama ini sudah kita lihat dalam contoh sebelumnya. Kita memiliki kebutuhan untuk mengirimkan acara yang terkait dengan penyelesaian beberapa proses, dan saat itu Flash menyediakan jenis acara (COMPLETE) yang terkait dengan objek acara (Event) yang sesuai dengan kriteria. Kita tidak perlu memberikan data tambahan dengan acara tersebut. Yang dibutuhkan adalah acara Event.COMPLETE.

Kita akan menjelajahi opsi-opsi lain ini di langkah yang akan datang.


Langkah 7: Jenis Acara Kustom

Seperti ditunjukkan di belakang pada langkah "Dispatch", jenis acara hanyalah pengidentifikasi String. Secara teknis mereka dapat berupa String apa pun yang Anda suka. Biasanya cukup untuk membuatnya menjadi satu kata (seperti "complete" atau "click") atau frasa yang sangat singkat (seperti "ioError" atau "keyFocusChange"); itu hanya harus unik dalam bidang peristiwa yang diberikan dispatcher peristiwa yang tersedia.

Selain itu, objek Event (termasuk subclass, seperti MouseEvent atau ProgressEvent) tidak terlalu peduli jenis acara apa yang diberikan saat instantiated. EventDispatcher akan dengan senang hati mengirimkan acara pengenal tipe apa pun dan kelas apa pun (asalkan itu kelas Event atau subkelas).

Hasilnya adalah Anda dapat membuat String jenis event Anda sendiri, mengirimkannya, dan mengatur pendengar dengannya, dan semuanya akan baik-baik saja. Ini sangat membantu ketika Anda ingin mengirim acara tetapi tidak selalu dapat menemukan representasi yang baik dari sifat acara di kelas bawaan.

Sebagai contoh, Anda mungkin memiliki kelas yang bertindak sebagai koordinator untuk beberapa hal sekaligus: memuat XML, memuat beberapa gambar berdasarkan data XML, dan membuat tata letak berdasarkan ukuran gambar yang dimuat, siap untuk animasi awal , pada titik mana Anda ingin mengirim acara. Meskipun acara COMPLETE mungkin cocok, Anda mungkin merasa bahwa acara "siap" lebih tepat merangkum maknanya.

Ini sesederhana memutuskan String untuk digunakan, dan kemudian menggunakannya. Gunakan keduanya saat menambahkan pendengar, dan saat mengirim acara. Jika String cocok, acara akan sampai ke tempat yang diinginkan. Sebagai contoh, ini adalah sebagian daftar kelas hipotetis:

Dan kode dari tempat lain dalam program yang sama:

Dan itu akan berhasil.

Namun, perlu disebutkan saat kita di sini bahwa mengetikkan String yang cocok di semua tempat bukanlah praktik yang baik. Kemungkinan untuk kesalahan tinggi, dan sistem acara tidak akan memberi tahu Anda bahwa Anda mengetik "raedy" alih-alih "ready". Fakta bahwa sistem acara fleksibel dan mudah digunakan - cukup berikan String lama apa pun untuk jenis acara - juga merupakan kelemahan. Operator Anda akan dengan senang hati menerima pendengar untuk apa pun, bahkan acara yang "raedy". Itu tidak benar-benar merekonsiliasi jenis acara apa yang terdaftar dengan jenis acara apa yang sebenarnya dikirim.

Untuk membantu mencegah hal ini, pendekatan standar adalah dengan hanya meletakkan String yang ingin Anda gunakan dalam konstanta statis di suatu tempat, dan kemudian tidak pernah menggunakan String literal itu lagi. Gunakan konstanta saja. Tentu saja, kemungkinan kesalahan ketik hanya hebat seperti sebelumnya, tetapi jika Anda menggunakan konstanta READY dan bukan String literal "ready", kesalahan ketik akan memicu peringatan kompiler. Anda dapat memperbaiki kesalahan Anda dengan cepat dan mudah. Kesalahan ketik dengan String literal tidak menghasilkan kesalahan kompilator, juga tidak menghasilkan kesalahan run-time. Satu-satunya hal yang terjadi adalah bahwa SWF tampaknya tidak berfungsi dengan baik, karena pendengar acara tidak menyala.

Dengan mengingat hal ini, paling umum untuk menyimpan konstanta ini di kelas Event terkait. Kita akan sampai ke kelas Event khusus hanya dalam beberapa langkah. Namun dalam situasi yang diuraikan dalam langkah ini (mis., Kami menggunakan kembali kelas Event tetapi bukan jenis acara), saya merasa lebih nyaman untuk hanya menyimpan konstanta pada kelas operator. Jadi kita dapat memilih untuk melakukan ini:

Dan:

Ini memberi kita keamanan menyimpan tipe acara dalam konstanta, sementara tidak memaksakan ketidaknyamanan membuat seluruh kelas Event yang tidak dibutuhkan. Saya harus menekankan bahwa ini adalah pilihan gaya, dan Anda mungkin merasa bebas untuk menggunakan teknik ini atau tidak. Saya merasa itu membutuhkan penjelasan, sehingga Anda dapat membuat keputusan sendiri berdasarkan informasi. Dalam hal apa pun, Anda harus menyimpan String jenis acara kustom Anda dalam konstanta statis. Di mana konstanta statis itu ditentukan, terserah Anda.


Langkah 8: Acara Pengiriman Ulang

Ada beberapa kali ketika satu kelas (sebut saja ClassX) memiliki properti yang diketik sebagai kelas lain (kami akan menyebutnya satu ClassY), sementara itu sendiri dimiliki oleh kelas ketiga (bagaimana dengan ClassZ?). ClassX mendengarkan acara dari ClassY, tetapi tidak hanya ingin agar ClassX merespons acara tersebut, kita juga ingin mempertimbangkan bahwa ClassX harus mengirimkan acara yang serupa (atau bahkan sama) sehingga ClassZ juga dapat mengambil tindakan lebih lanjut.

Sebagai contoh yang lebih konkret, kita memiliki kelas (ini akan menjadi "ClassX") yang merupakan semacam pengelola data. Itu memuat dokumen XML, mem-parsingnya, dan menyimpan data dari XML dalam propertinya sendiri. Jadi ia memiliki objek URLLoader (ini akan menjadi "ClassY"), dan mendengarkan acara Event.COMPLETE ketika dokumen XML dimuat.

Kemudian kita memiliki kelas dokumen utama yang memiliki pengelola data (kelas dokumen adalah "ClassZ"). Ini mengoordinasikan pemuatan data dengan elemen UI lainnya, sehingga ingin tahu kapan data dimuat dan siap, sehingga dapat melanjutkan untuk membuat dan tata letak elemen UI berdasarkan data.

Kita bisa melakukan ini:

Tetapi kita juga bisa melakukan ini:

Di sini kita mengirim ulang acara yang sudah ada. Kita tidak hanya menggunakan kembali jenis acara dan kelas Event, tetapi kita juga menggunakan kembali seluruh objek Event seperti yang diteruskan ke pendengar sendiri.

Ini bukan ilmu roket, tetapi ini adalah teknik kecil yang berguna yang secara mengejutkan tidak begitu jelas.

"Tapi tunggu," Anda pasti berpikir, "jika kita mengirim ulang acara yang berasal dari objek URLLoader, bukankah target acara tersebut tetap _xmlLoader saat kembali ke kelas dokumen?" Dan Anda akan memiliki poin yang sangat bagus dan bijaksana, dan saya akan bangga dengan Anda karena berpikir begitu rajin, tetapi Anda akan salah.

Suatu hal yang agak ajaib terjadi ketika penempatan ulang acara. Properti target diatur ke operator saat ini. Anda dapat menemukan contoh kode yang berfungsi pada langkah ini dalam paket unduhan yang berjudul redispatch.

Sebenarnya, itu tidak begitu ajaib. Saat memanggil dispatchEvent, jika objek Event yang dilewati sudah memiliki target yang ditetapkan, maka metode clone dipanggil pada Event tersebut, membuat salinan identik tapi diam-diam dari Event asli, kecuali untuk nilai yang terkandung dalam target.


Langkah 9: Objek Acara Kustom

Semua yang disebutkan sejauh ini adalah sesuatu yang Anda ingin tahu. Tetapi akan tiba saatnya ketika hal terbaik untuk dilakukan adalah mengirimkan acara adat Anda sendiri. Bukan hanya tipe acara khusus, tetapi seluruh kelas Event khusus.

Proses untuk melakukan ini sangat mudah, Anda hanya perlu mengikuti beberapa langkah. Kita akan membahas ini pada waktunya. Perhatikan bahwa sebagian besar dari ini adalah kode boilerplate, dan Anda dapat dengan mudah membuat templat untuk subkelas Event dan mengubah hanya beberapa buah kunci dan mematikan dan menjalankannya. Langkah-langkah umum, dalam bentuk yang disingkat-seolah-jika-Anda-tahu-apa-yang-saya-bicarakan:

  1. Subclass Event
  2. Panggil super(...)
  3. Menyimpan tipe acara dalam konstanta statis publik
  4. Nyatakan properti pribadi untuk menyimpan data khusus
  5. Buat getter publik untuk memberikan akses hanya baca ke info khusus
  6. (Opsional) Mengganti metode clone
  7. (Opsional) Ganti metode toString

Untuk menjelaskan proses ini lebih dalam, kita akan memulai proyek slider dan membuat SliderEvent yang kami perlukan untuk itu. Jadi perlu memulai proyek sebelum kita dapat menulis beberapa kode, jadi pengalihan cepat pada langkah selanjutnya, maka kita akan mulai menulis kelas Event kustom.


Langkah 10: Buat Struktur Proyek

Kita akan menjaga hal-hal yang cukup sederhana untuk yang satu ini, tetapi kita akan tetap membuat paket untuk kelas.

Mulailah dengan membuat folder untuk seluruh proyek. Milik saya akan disebut slider.

Di dalamnya, buat folder com, dan di dalamnya, folder activetuts.

Sekarang buat dua folder di dalam activetuts: events dan ui. Struktur folder terakhir Anda akan terlihat seperti ini:

  • slider
    • com
      • activetuts
        • events
        • slider

Sekarang kembali ke kelas Event kita.


Langkah 11: Subclass Event

Pertama, buat file teks baru di folder slider/com/activetuts/events, dan beri nama SliderEvent.as. Kita akan muncul di boilerplate untuk kelas apa saja terlebih dahulu:

Seharusnya tidak ada yang mengejutkan di sini, dan jika Anda memiliki template ActionScript untuk editor teks Anda, Anda bahkan tidak perlu mengetik banyak.

Sekarang, kita akan memodifikasi ini sehingga memperpanjang Event.

Seperti yang Anda lihat, kita cukup mengimpor kelas Event, tambahkan extends Event ke definisi kelas.


Langkah 12: Panggil super

Superclass kita dapat menangani banyak hal untuk, yang hebat, tetapi perlu pastikan bahwa kita menginisialisasi superclass dengan benar ketika menginisialisasi subclass. Kita perlu menyiapkan konstruktor dengan argumen yang cocok dengan yang ditemukan pada konstruktor Event, dan meneruskannya bersama panggilan ke super.

Sejauh ini, ini adalah teknik subclassing dasar. Bahkan, tergantung pada kecakapan editor Anda dengan templat, Anda mungkin dapat menentukan kelas super ketika Anda membuat file dan semua ini dilakukan untuk Anda. Flash Builder, misalnya, dapat melakukan ini.


Langkah 13: Simpan Jenis Acara di Konstanta Statis Publik

Agaknya, akan ada satu atau lebih jenis acara yang terkait dengan kelas acara ini. Sama seperti acara COMPLETE dikaitkan dengan kelas Event, dan CLICK bahkan dengan kelas MouseEvent, kelas acara khusus kita kemungkinan akan memiliki jenis acara khusus.

Ini sesederhana menulis baris seperti berikut untuk setiap jenis acara yang ingin Anda tambahkan:

Ayo lakukan itu sekarang untuk kelas SliderEvent.

Kita secara teoritis bisa menggunakan kelas kita sekarang. Kita dapat menggunakan SliderEvent di dispatchEvent, dan mendengarkan serta membuat acara dengan tipe acara SliderEvent.CHANGE.

Tapi kita tidak akan berhenti di situ. Ada lagi yang perlu dipertimbangkan. Tetapi sebelum kita melakukan lebih banyak penulisan kode, kita perlu mengambil jalan memutar lain ke dalam teori.


Step 14: Push vs. Pull

Ketika suatu acara dikirim, kadang-kadang cukup mengetahui bahwa peristiwa itu telah terjadi. Misalnya, sebagian besar waktu yang Anda minati dalam Event.ENTER_FRAME, Event.COMPLETE, atau TimeEvent.TIMER, Anda mungkin hanya ingin tahu bahwa peristiwa itu terjadi. Namun, ada saat-saat lain ketika Anda mungkin ingin tahu lebih banyak. Saat mendengarkan MouseEvent.CLICK, Anda mungkin tertarik pada apakah tombol Shift ditekan, atau koordinat mouse pada saat klik. Jika Anda mendengarkan ProgressEvent.PROGRESS, kemungkinan besar Anda ingin mengetahui perkembangan aktual dari muatan tersebut; yaitu, berapa banyak byte yang dimuat dan berapa banyak yang ada untuk memuat secara total.

Perbedaan antara kedua metodologi ini kadang-kadang dikenal sebagai "push" dan "pull." Istilah-istilah itu merujuk pada bagaimana pendengar acara mendapatkan data yang terkait dengan acara tersebut. Jika data "didorong" maka ada data yang disimpan dalam objek acara, dan untuk mendapatkan data pendengar hanya perlu menggunakan properti pada objek acara. Namun, jika data "ditarik", umumnya objek acara memiliki sangat sedikit informasi yang terkandung di dalamnya - hanya kebutuhan: jenis, target, dll. Target ini, bagaimanapun, sangat diperlukan, karena menyediakan akses ke pengirim acara. ke pendengar acara, memungkinkan pendengar untuk mendapatkan data yang dibutuhkan dari operator.

Dengan kata lain, Anda bisa mendorong sekelompok data ke pendengar di dalam objek acara, atau Anda dapat meminta pendengar untuk menarik data keluar dari operator sesuai kebutuhan.

Pro dan kontra dari masing-masing teknik agak seimbang, menurut saya, dan jalur yang Anda pilih untuk objek acara Anda tergantung pada situasi yang dihadapi, dan tidak sedikit pada preferensi pribadi.

Exhibit A:

Pros Cons
Push
  • Data mudah diakses di objek acara
  • Anda mungkin mendorong data yang tidak dibutuhkan. Menggembungkan objek acara dengan banyak data yang jarang digunakan dapat menyebabkan masalah memori dan/atau kinerja.
Pull
  • Sangat mudah untuk ditulis. Anda mungkin tidak perlu kelas Event khusus untuk menjalankan acara tarik.
  • Sangat mudah digunakan. Jika ini hanya kelas Event, satu-satunya argumen yang diperlukan adalah tipe event.
  • Jika data yang biasanya ditarik keluar dari operator mahal untuk dihitung dan dikembalikan, Anda mungkin terpukul kinerja dengan mengharuskan operator untuk terus membagikan informasi itu.
  • Beberapa data mungkin sulit untuk ditarik, mis. KeyboardEvent memiliki properti keyCode untuk merinci tombol yang ditekan untuk memicu acara.

Ini mungkin diskusi yang bagus untuk komentar; Saya yakin banyak dari Anda membaca memiliki perasaan bersemangat tentang metodologi mana yang lebih baik. Secara pribadi, saya mencoba mencari metode yang paling sesuai untuk situasi ini.

Karena itu, perlu dicatat bahwa sampai saat ini kelas SliderEvent agak "menarik-ish." Demi ilustrasi, dan karena itu bukan ide yang buruk (meskipun saya memang datang dengan beberapa di antaranya), kita akan melanjutkan dengan menjadikan ini sebagai peristiwa yang mendorong data bersamanya; yaitu nilai slider ketika diubah.


Langkah 15: Nyatakan Properti Pribadi untuk Memegang Data Khusus

Untuk mengimplementasikan acara push, kita perlu memiliki tempat untuk menyimpan data yang didorong. Kita akan menambahkan properti pribadi untuk tujuan itu.

Anda harus tetap membuka SliderEvent (jika tidak... tunggu apa lagi?). Tambahkan baris yang disorot:

Selanjutnya kita akan memodifikasi konstruktor sehingga kita dapat menerima parameter nilai, dan mengatur properti pribadi dengan itu:

Dengan cara ini kita dapat dengan mudah membuat SliderEvent dan mengatur data push-nya dalam satu baris.

Mengapa menggunakan properti pribadi? Dalam hal ini, kita ingin melindungi data. Menurut pendapat saya, data yang terkait dengan suatu acara tidak dapat diubah, asalkan itu terkait dengan acara tersebut. Mampu mengubah data objek acara seperti mengedit buku teks sejarah. Agar adil, ini adalah pendapat saya dan standar yang digunakan oleh Adobe dengan kelas bawaannya adalah dengan menggunakan properti yang dapat ditulis (secara teknis mereka menggunakan properti pribadi dan getter dan setter publik, tetapi hasil akhirnya adalah sama).


Langkah 16: Buat Getters Publik untuk Data Kustom

Jadi langkah selanjutnya adalah memastikan kita dapat mengakses data yang didorong. Properti pribadi dengan sendirinya tidak berguna untuk tujuan ini. Oleh karena itu, kita perlu menulis pengambil publik untuk properti _sliderValue. Kita akan memilih untuk tidak menulis setter, sehingga properti menjadi read-only (seperti yang dibahas pada langkah terakhir).

Tambahkan metode ini ke kelas:

Ini menambahkan pengambil agar kami dapat mengakses sliderValue dengan cara seperti properti. Saya memilih untuk tidak menambahkan penyetel yang cocok. Anda dapat menambahkan satu jika Anda merasa itu berharga.


Langkah 17: Ganti metode clone

Saya menyebutkan metode clone beberapa saat yang lalu. Anda mungkin tidak akan terlalu sering memanggil clone, tetapi bukan ide yang buruk untuk menimpa metode clone sehingga acara khusus Anda dapat dimainkan dengan baik dengan sistem acara.

Tambahkan metode ini ke kelas Anda:

Pertama, perhatikan tanda tangan dari metode ini. Kita menggunakan override karena metode ini dideklarasikan di Event, dan mewarisinya. Itu juga mengembalikan objek bertipe Event. Pastikan, saat menulis override clone Anda, bahwa Anda memasukkan tipe return yang benar. Sangat mudah untuk melupakan dan memasukkan tipe kelas Anda di sana, tetapi itu akan menyebabkan kesalahan override yang tidak kompatibel, karena tipe return perlu cocok.

Semua yang benar-benar kita lakukan di daging acara adalah membuat SliderEvent baru dan meneruskan nilai yang sama dengan yang disimpan di objek acara saat ini. Ini menciptakan salinan yang identik tetapi tersembunyi: sebuah klon.

Ini adalah langkah opsional, tetapi ini adalah kemenangan cepat dan memastikan bahwa acara khusus Anda berjalan baik dengan sistem acara lainnya.


Langkah 18: Ganti metode toString

Satu hal terakhir, dan sekali lagi ini adalah opsional. Tapi itu juga sangat berguna sebagai alat debug, jadi biasanya membayar sendiri dalam beberapa penggunaan.

Jika Anda belum diberi tahu, metode toString ada pada semua objek (dideklarasikan dan didefinisikan dalam Object, kelas über dari mana semua kelas lain mewarisi, apakah Anda suka atau tidak). Itu dapat dipanggil secara eksplisit, tetapi hal praktisnya adalah ia dipanggil secara otomatis dalam sejumlah kasus. Misalnya, ketika Anda meneruskan objek ke fungsi trace, objek apa pun yang belum menjadi String harus memanggil toString untuk memastikannya diformat dengan baik untuk panel Output. Bahkan dipanggil ketika bekerja dengan Object bersama dengan Strings, seperti dengan concatenation. Misalnya, jika Anda menulis ini:

ActionScript cukup pintar untuk mengubah 42 menjadi representasi String dari Number sebelum merangkai String. Mencoba untuk menambahkan sebuah String dan sebuah Number adalah berita buruk, tetapi mengubah sebuah Number menjadi sebuah String lalu menggabungkannya dengan sebuah String yang lain baik-baik saja.

Jadi ketika Anda menulis kelas Anda sendiri, Anda bisa menyediakan metode toString, yang tidak membutuhkan argumen dan mengembalikan sebuah String, dan mengembalikan String apa pun yang Anda suka.

Dalam kasus objek Event, Adobe membantu menyediakan metode formatToString untuk membantu semua Event terlihat serupa ketika ditelusuri. Kita akan menggunakannya dalam metode yang akan ditambahkan ke kelas:

Pertama, perhatikan tanda tangan metode. Sekali lagi, ini override sehingga kita memiliki kata kunci itu. Ini public, tidak memerlukan parameter, dan mengembalikan sebuah String (yang seharusnya jelas).

Selanjutnya, perhatikan baris tunggal di badan metode. Kita memanggil formatToString, yang didefinisikan dalam Event, sehingga mudah digunakan. Argumen pertama yang kita berikan adalah nama String dari kelas. Setelah itu, argumennya terbuka. Anda dapat memasukkan satu, 15, atau tidak sama sekali. Kita melewati dua. Tidak peduli berapa banyak yang Anda lewati, semuanya haruslah Strings, dan mereka harus cocok dengan nama properti di kelas Anda. "type" didefinisikan oleh Event, tetapi "sliderValue" didefinisikan oleh kelas kita sendiri. Maksudnya, apa yang terjadi adalah bahwa nama properti dicetak, diikuti oleh tanda sama dengan, yang diikuti oleh nilai aktual properti itu. Singkatnya, pada akhirnya akan terlihat seperti ini:

Ini sepenuhnya non-fungsional tetapi sangat bermanfaat. Ini dapat memberikan pandangan sekilas ke peristiwa ketika hal-hal tidak bekerja seperti yang Anda pikirkan seharusnya.


Langkah 19: Membangun Slider

Pada titik ini, kita telah melalui konsep utama tutorial ini: menulis kelas Event kustom. Tapi kita benar-benar harus mengujinya. Kita akan menghabiskan sisa waktu kita membangun aplikasi penggeser sederhana yang dipratinjau pada awal tutorial.

Kita sudah memiliki struktur folder proyek; kita hanya perlu beberapa file lagi. Kita akan mulai dengan file FLA.

Buat file Flash baru (ActionScript 3.0, tentu saja) dan simpan sebagai ActiveSlider.fla di root folder proyek Anda. Saya akan berasumsi bahwa Anda tidak perlu detail langkah-demi-langkah tentang cara menyatukan FLA sederhana ini, dan sebagai gantinya saya akan menjelaskan elemen-elemen kunci. Anda dapat menggunakan file FLA yang ditemukan di folder mulai paket unduhan untuk referensi, juga, atau bahkan hanya menyalin FLA itu ke folder proyek Anda dan menyebut langkah ini selesai.

Ada tiga objek utama di atas panggung.

  1. slider track. Ini adalah strip panjang dan sempit yang menunjukkan ke mana slider dapat dipindahkan. Slider bergerak "di" trek.
    • Perlu menjadi Klip Film
    • Untuk matematika termudah, harus memiliki karya seni yang diatur sehingga titik pendaftaran ada di sudut kiri atas
    • Nama itu track_mc
    • Tempatkan di tengah atas; itu harus mengambil sebagian besar lebar panggung dan memiliki ruang di bawahnya.
  2. slide grip. Ini adalah elemen berukuran tombol yang menunjukkan posisi slider saat ini. Bagian yang bergerak di sepanjang trek dan merespons mouse.
    • Perlu menjadi Klip Film.
    • Sekali lagi, untuk matematika, harus memiliki titik registrasi di kiri atas
    • Beri nama grip_mc
    • Letakkan di atas lintasan, sehingga secara vertikal berada di tengah lintasan, dan di suatu tempat di ujung kiri dan kanan lintasan
    • Itu harus ditumpuk di atas trek, sehingga pegangan mengaburkan trek (letakkan di atas lapisan yang lebih tinggi)
  3. Bidang output. Ini adalah bidang teks yang, untuk tujuan demonstrasi kita sendiri, menampilkan nilai slider saat ini.
    • Harus berupa Bidang Teks dinamis.
    • Beri nama itu output_tf
    • Font tidak penting; atur sesuai keinginan dan embed jika diperlukan
    • Tempatkan di bagian bawah panggung, sehingga tidak bertentangan dengan ruang yang dibutuhkan oleh slider.
The stage of our FLA

Selain menghubungkan kelas dokumen, yang akan ditulis dalam dua langkah, FLA siap untuk bisnis.


Langkah 20: Kelas ActiveSlider

Kelas UI utama yang akan digunakan adalah kelas ActiveSlider. Ini akan memperluas EventDispatcher, menargetkan dua Klip Video di atas panggung, dan mengatur interaktivitas mouse untuk perilaku slider. Paling menarik dari semuanya, itu akan mengirimkan SliderEvent.

Mulailah dengan membuat file kelas baru yang disebut ActiveSlider.as di folder com/activetuts/slider dari proyek Anda. Kelas ini tidak terlalu intens (setidaknya, bukan untuk tujuan kita di sini. Kelas slider bisa lebih terlibat), dan saya hanya akan menyajikan kode secara penuh dan berdiskusi saat kita mulai:

Tidak ada yang menarik, hanya menyiapkan paket dan impor.

Kita membutuhkan tiga properti ini. Dua yang pertama melacak Sprite (atau MovieClips) yang membentuk bilah geser. Yang ketiga digunakan sambil menyeret pegangan slider; ini membantu menjaga posisi genggaman diimbangi dari mouse dengan jumlah yang relatif terhadap tempat genggaman diklik di tempat pertama.

Ini adalah konstruktornya. Ia menerima dua argumen Sprite, yang diteruskan ke dua properti pertama untuk penyimpanan. Kemudian melakukan pemeriksaan sederhana untuk memastikan dua Sprite berada di ruang koordinat yang sama dengan memeriksa bahwa properti parent merujuk objek yang sama. Jika tidak, maka matematika kita untuk menempatkan pegangan mungkin tidak dapat diandalkan, jadi lemparkan kesalahan sebagai cara untuk memperingatkan pengembang. Sisa konstruktor dikhususkan untuk menambahkan dua pendengar acara. Yang pertama adalah acara MOUSE_DOWN dan langsung. Tetapi yang kedua sedang mencoba untuk menambahkan acara MOUSE_UP ke stage, yang mungkin ada atau tidak ada tergantung pada apakah grip Sprite ada di daftar tampilan atau tidak. Dua metode selanjutnya mungkin membuat ini sedikit lebih jelas:

Metode onAddedToStage adalah pendengar acara untuk acara ADDED_TO_STAGE, yang didirikan di konstruktor, tetapi hanya jika pegangan Sprite belum memiliki referensi ke stage. Metode addStageListener cukup menambahkan pendengar acara MOUSE_UP ke stage. Jadi, jika ada referensi stage dalam konstruktor, kita memanggil addStageListener secara langsung. Jika tidak ada referensi stage, kita siapkan event ADDED_TO_STAGE, dan ketika pegangan ditambahkan ke daftar tampilan, dan dengan demikian memiliki referensi stage, metode onAddedToStage menyala yang kemudian memanggil addStageListener. Itu juga menghapus pendengar acara ADDED_TO_STAGE, karena kita hanya perlu melakukan ini satu kali.

Selanjutnya kita memiliki dua pendengar acara mouse kita. Di onDown, kuncinya adalah menambahkan pendengar acara ENTER_FRAME. onUp, kita menghapus pendengar itu. Juga di onDown, kita mencatat di mana pada genggaman klik mouse yang sebenarnya terjadi, dan menyimpannya di _grabOffset. Ini akan memainkan metode onFrame kita selanjutnya.

Ini adalah daging utama dari logika slider. Metode ini diulang pada acara ENTER_FRAME, tetapi hanya ketika mouse ditekan pada pegangan, dan hanya selama mouse tetap ditekan.

Pertama, kita mengatur properti x grip agar sesuai dengan posisi mouse, hanya saja kita perlu mengimbanginya berdasarkan posisi mouse asli, sehingga bergerak dengan lancar dan tidak melompat sehingga ujung kirinya berada di mouse.

Dua baris berikutnya menghitung persegi panjang pembatas dari grip dan track Sprite. Kita akan menggunakan persegi panjang ini dalam matematika mendatang, jadi kita akan menjaga hal-hal lebih rapi dengan pra-menghitung persegi panjang dan menyimpannya dalam variabel.

Lalu ada blok if. Ini hanya membatasi slider kita ke dalam trek. Ini adalah pemeriksaan sederhana untuk melihat apakah x genggaman, seperti yang dihitung pada baris pertama metode, lebih rendah dari (di sebelah kiri) x lintasan. Jika ya, itu akan terlalu jauh, jadi kita perlu memindahkan pegangan ke nilai minimum itu. Demikian pula, kita memeriksa untuk melihat apakah tepi kanan genggaman lebih besar dari (ke kanan) tepi kanan lintasan, dan jika demikian kita perlu menggulungnya kembali ke nilai maksimum.

Akhirnya, kita memiliki posisi pegangan yang dapat diandalkan, dan untuk saat ini hanya melacak nilai slider saat ini, yang dihitung dalam bit kode terakhir untuk kelas:

Ini adalah pengambil sederhana, meskipun matematika yang digunakan untuk nilai pengembalian mungkin sedikit membingungkan. Ini menentukan posisi pegangan saat ini sebagai persentase dari rentang gerakan pegangan. Akan lebih jelas jika hanya ini:

...yang masuk akal tetapi tidak memperhitungkan bahwa genggaman tidak benar-benar melewati seluruh lebar trek. Ini berjalan jauh ke tepi kiri, tetapi hanya sejauh ujung kanan trek dikurangi lebar genggaman. Jadi ini lebih akurat:

Ini membuat lebar dimana kita membagi rentang gerak. Namun, mungkin masih ada gotcha di mana trek mungkin diimbangi ke kiri atau kanan dari wadahnya, yang berarti bahwa nilai yang diperoleh tidak sepenuhnya benar. Kita perlu menetralkannya dengan mengurangi posisi x trek dari x grip, dan kita berakhir dengan ini:

Untuk referensi, inilah kelas lengkapnya, dengan rambling saya ditinggalkan:

Kita belum menambahkan di kelas SliderEvent; kita akan mengambil langkah terpisah untuk melakukan itu. Tetapi pertama-tama, kita membutuhkan kelas dokumen sehingga dapat benar-benar menggunakan ActiveSlider.


Langkah 21: Kelas Dokumen

Kita membutuhkan satu file lagi untuk membuatnya berfungsi: kelas dokumen. Buat file kelas baru bernama SliderDemo di folder root proyek. Tambahkan kode berikut:

Ini jauh lebih sederhana daripada kelas ActiveSlider. Ini benar-benar hanya membuat ActiveSlider ke properti bernama _slider.

Kembali ke file FLA, dan masukkan SliderDemo ke dalam bidang kelas dokumen, dan Anda harus dapat mencobanya. Slider harus dapat bergerak bolak-balik, dan membatasi dirinya sendiri ke lebar trek.

Sekarang untuk satu tugas terakhir. Kita perlu mengirim, dan mendengarkan, acara SliderEvent.CHANGE. Kita akan melakukannya nanti.


Langkah 22: Pengiriman SliderEvent

Kembali ke kelas ActiveSlider, dan buat perubahan satu baris ke metode onFrame:

Kita telah menghapus jejak dan menggantinya dengan pengiriman acara langsung yang nyata. Agar ini berfungsi, kita perlu mengimpor kelas SliderEvent:


Langkah 23: Mendengarkan SliderEvent

Akhirnya, kembali ke kelas SliderDemo, dan ubahlah agar ia mendengarkan dan bereaksi terhadap SliderEvent:

Kita lagi mengimpor kelas SliderEvent, dan setelah membuat ActiveSlider, menambahkan pendengar bernama onSliderChange ke slider. Metode itu adalah tambahan terbesar, tetapi masih merupakan pendengar acara reguler. Ini seperti pendengar acara lainnya, hanya kita memastikan untuk mengetikkan argumen acara sebagai SliderEvent, karena itulah yang didapatkan.

Baris pertama kode agak berlebihan, tetapi saya ingin melihat apa yang terjadi ketika Anda melacak objek SliderEvent. Anda akan melihat, ketika Anda menjalankan ini, pemformatan khas untuk Flash dari objek acara.

The event object represented as a String

Baris kedua melakukan apa yang kita cari sejak awal. Ini hanya mengambil properti sliderValue, mengubahnya menjadi sebuah String, kemudian menempelkan String itu ke dalam TextField di atas panggung, sehingga kita dapat melihat nilai slider dalam film.


Langkah 24: Perangkuman

Ketika Anda mulai menjalankan acara kustom Anda sendiri, Anda mulai bekerja dengan ActionScript 3 seperti yang seharusnya digunakan. Acara membantu Anda memisahkan kelas dari satu sama lain, dan aliran acara yang terstruktur dengan baik dalam aplikasi Anda benar-benar dapat membuat perbedaan antara sesuatu yang mudah untuk dikerjakan dan sesuatu yang buggy dan temperamental. Dengan cicilan terakhir (secara teoritis) AS3 101 ini, Anda harus berada di jalur yang tepat untuk menjadi seorang ninja.

Terima kasih telah membaca, dan sampai jumpa di Activetuts+ sebelum Anda menyadarinya!

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.