RxJava Android Samples
1.0.0
นี่คือพื้นที่เก็บข้อมูลที่มีตัวอย่างการใช้งาน RxJava กับ Android ที่เป็นประโยชน์ในโลกแห่งความเป็นจริง โดยปกติจะอยู่ในสถานะ "งานระหว่างดำเนินการ" (WIP) คงที่
ฉันยังได้พูดคุยเกี่ยวกับการเรียนรู้ Rx โดยใช้ตัวอย่างมากมายที่ระบุไว้ใน repo นี้
using )ข้อกำหนดทั่วไปคือการถ่ายข้อมูลการดำเนินการ I/O จำนวนมากที่ใช้เวลานานไปยังเธรดพื้นหลัง (เธรดที่ไม่ใช่ UI) และป้อนผลลัพธ์กลับไปยัง UI/เธรดหลักเมื่อเสร็จสิ้น นี่คือการสาธิตวิธีการออฟโหลดการดำเนินการที่ใช้เวลานานไปยังเธรดเบื้องหลัง หลังจากการดำเนินการเสร็จสิ้น เราก็กลับมาที่เธรดหลักอีกครั้ง ทั้งหมดใช้ RxJava! คิดว่านี่เป็นการแทนที่ AsyncTasks
การดำเนินการที่ยาวนานนั้นจำลองโดยการบล็อกการเรียก Thread.sleep (เนื่องจากการดำเนินการนี้ทำในเธรดพื้นหลัง UI ของเราจึงไม่ถูกขัดจังหวะ)
เพื่อให้เห็นตัวอย่างนี้เปล่งประกายจริงๆ กดปุ่มหลายครั้งและดูว่าการคลิกปุ่ม (ซึ่งเป็นการทำงานของ UI) จะไม่ถูกบล็อกอย่างไร เนื่องจากการดำเนินการแบบยาวจะทำงานในพื้นหลังเท่านั้น
นี่คือการสาธิตวิธีการสะสมเหตุการณ์โดยใช้การดำเนินการ "บัฟเฟอร์"
มีการจัดเตรียมปุ่มไว้และเราสะสมจำนวนการคลิกปุ่มนั้น ในช่วงเวลาหนึ่ง จากนั้นจึงแยกผลลัพธ์สุดท้ายออก
หากคุณกดปุ่มหนึ่งครั้ง คุณจะได้รับข้อความแจ้งว่ากดปุ่มครั้งเดียว หากคุณกดปุ่มดังกล่าว 5 ครั้งติดต่อกันภายในระยะเวลา 2 วินาที คุณจะได้รับบันทึกรายการเดียว โดยบอกว่าคุณกดปุ่มนั้น 5 ครั้ง (เทียบกับบันทึกแต่ละรายการ 5 รายการว่า "กดปุ่มครั้งเดียว")
บันทึก:
หากคุณกำลังมองหาโซลูชันที่ป้องกันความผิดพลาดได้มากกว่าซึ่งสะสมการแตะ "ต่อเนื่อง" เทียบกับจำนวนการแตะภายในช่วงเวลาหนึ่ง ให้ดูที่ EventBus Demo ซึ่งมีการใช้คำสั่งผสมของตัว publish และ buffer สำหรับคำอธิบายโดยละเอียดเพิ่มเติม คุณสามารถดูได้ที่โพสต์ในบล็อกนี้
นี่คือการสาธิตวิธีการกลืนเหตุการณ์ต่างๆ ในลักษณะที่เคารพเฉพาะเหตุการณ์สุดท้ายเท่านั้น ตัวอย่างทั่วไปของกรณีนี้คือช่องผลการค้นหาทันที เมื่อคุณพิมพ์คำว่า "Bruce Lee" คุณคงไม่ต้องการค้นหา B, Br, Bru, Bruce, Bruce, Bruce L ... ฯลฯ แต่ควรรอสักครู่อย่างชาญฉลาด ตรวจสอบให้แน่ใจว่าผู้ใช้ พิมพ์หมดทั้งคำก็ตะโกนเรียก “บรูซ ลี” ออกมาคำเดียว
เมื่อคุณพิมพ์ลงในช่องป้อนข้อมูล มันจะไม่บันทึกข้อความบันทึกเมื่อมีการเปลี่ยนอักขระอินพุตทุกครั้ง แต่จะเลือกเฉพาะเหตุการณ์ที่ปล่อยออกมาครั้งล่าสุด (เช่น อินพุต) และบันทึกสิ่งนั้น
นี่คือวิธี debounce/throttleWithTimeout ใน RxJava
Retrofit from Square เป็นไลบรารีที่น่าทึ่งที่ช่วยในเรื่องการเชื่อมต่อเครือข่ายที่ง่ายดาย (แม้ว่าคุณจะยังไม่ได้เปลี่ยนไปใช้ RxJava แต่คุณก็ควรลองใช้ดู) มันทำงานได้ดียิ่งขึ้นกับ RxJava และนี่คือตัวอย่างที่กระทบกับ GitHub API ซึ่งนำมาจากคำพูดของ Jake Wharton ผู้พัฒนาครึ่งเทพ Android ที่ Netflix สามารถรับชมเสวนาได้ที่ลิงค์นี้ บังเอิญว่าแรงจูงใจในการใช้ RxJava ของฉันมาจากการเข้าร่วมการบรรยายที่ Netflix
(หมายเหตุ: คุณมีแนวโน้มที่จะเข้าถึงโควต้า GitHub API อย่างรวดเร็ว ดังนั้นให้ส่งโทเค็น OAuth เป็นพารามิเตอร์ หากคุณต้องการเรียกใช้ตัวอย่างเหล่านี้ต่อไป)
การอัปเดตมุมมองอัตโนมัติเป็นสิ่งที่ดีทีเดียว หากคุณเคยจัดการกับ Angular JS มาก่อน พวกเขามีแนวคิดที่ดีที่เรียกว่า "การเชื่อมโยงข้อมูลแบบสองทาง" ดังนั้นเมื่อองค์ประกอบ HTML ถูกผูกไว้กับโมเดล/ออบเจ็กต์เอนทิตี มันจะ "รับฟัง" การเปลี่ยนแปลงในเอนทิตีนั้นอย่างต่อเนื่องและ อัปเดตสถานะอัตโนมัติตามโมเดล การใช้เทคนิคในตัวอย่างนี้ คุณอาจใช้รูปแบบเช่นรูปแบบมุมมองการนำเสนอได้อย่างง่ายดาย
แม้ว่าตัวอย่างที่นี่จะค่อนข้างเป็นพื้นฐาน แต่เทคนิคที่ใช้ในการบรรลุการเชื่อมโยงสองครั้งโดยใช้ Publish Subject นั้นน่าสนใจกว่ามาก
นี่คือตัวอย่างการโพลโดยใช้ RxJava Schedulers สิ่งนี้มีประโยชน์ในกรณีที่คุณต้องการสำรวจเซิร์ฟเวอร์อย่างต่อเนื่องและอาจได้รับข้อมูลใหม่ การโทรผ่านเครือข่ายเป็นแบบ "จำลอง" ดังนั้นจึงบังคับให้มีการหน่วงเวลาก่อนที่จะส่งคืนสตริงผลลัพธ์
มีสองสายพันธุ์สำหรับสิ่งนี้:
ตัวอย่างที่สองโดยพื้นฐานแล้วเป็นตัวแปรหนึ่งของ Exponential Backoff
แทนที่จะใช้ RetryWithDelay เราใช้ RepeatWithDelay ที่นี่ เพื่อให้เข้าใจถึงความแตกต่างระหว่างลองใหม่ (เมื่อ) และทำซ้ำ (เมื่อ) ฉันขอแนะนำโพสต์ที่ยอดเยี่ยมของ Dan ในหัวข้อนี้
อีกทางเลือกหนึ่งในการโพลล่าช้าโดยไม่ต้องใช้ repeatWhen เมื่อจะใช้การสังเกตความล่าช้าแบบซ้อนกันที่ถูกล่ามโซ่ ดู startExecutingWithExponentialBackoffDelay ในตัวอย่าง ExponentialBackOffFragment
Exponential Backoff เป็นกลยุทธ์ที่เราจะเปลี่ยนแปลงอัตราของกระบวนการตามผลตอบรับจากเอาต์พุตบางอย่าง (โดยปกติจะเป็นการลดจำนวนการลองใหม่หรือเพิ่มเวลารอก่อนที่จะลองอีกครั้งหรือดำเนินการกระบวนการบางอย่างอีกครั้ง)
แนวคิดนี้สมเหตุสมผลมากขึ้นด้วยตัวอย่าง RxJava ทำให้การใช้กลยุทธ์ดังกล่าวเป็นเรื่องง่าย (ค่อนข้าง) ฉันขอขอบคุณไมค์ที่แนะนำแนวคิดนี้
สมมติว่าคุณมีความล้มเหลวของเครือข่าย กลยุทธ์ที่สมเหตุสมผลคืออย่าลองโทรผ่านเครือข่ายของคุณซ้ำทุกๆ 1 วินาที คงจะฉลาดแทน (เปล่าเลย... สง่างาม!) หากลองอีกครั้งโดยเพิ่มความล่าช้ามากขึ้น ดังนั้นคุณลองที่ 1 วินาทีเพื่อดำเนินการโทรผ่านเครือข่าย ไม่มีลูกเต๋าใช่ไหม ลองหลังจากผ่านไป 10 วินาที... เชิงลบใช่ไหม ลองหลังจาก 20 วินาที ไม่มีคุกกี้ใช่ไหม ลองหลังจากผ่านไป 1 นาที หากสิ่งนี้ยังคงล้มเหลว คุณจะต้องยอมแพ้บนเครือข่าย โย่!
เราจำลองพฤติกรรมนี้โดยใช้ RxJava พร้อมด้วยตัวดำเนินการ retryWhen
ข้อมูลโค้ด RetryWithDelay ได้รับความอนุเคราะห์:
ดูตัวอย่างการสำรวจที่เราใช้กลไกการถอยกลับแบบเอ็กซ์โปเนนเชียลที่คล้ายกันมาก
กลยุทธ์การถอยกลับแบบเอ็กซ์โปเนนเชียลอีกรูปแบบหนึ่งคือการดำเนินการตามจำนวนครั้งที่กำหนดแต่มีช่วงเวลาที่ล่าช้า ดังนั้นคุณจึงดำเนินการบางอย่าง 1 วินาทีต่อจากนี้ จากนั้นคุณดำเนินการอีกครั้งใน 10 วินาทีต่อจากนี้ จากนั้นคุณจึงดำเนินการใน 20 วินาทีต่อจากนี้ หลังจากรวมทั้งหมด 3 ครั้ง คุณจะหยุดดำเนินการ
จริงๆ แล้วการจำลองพฤติกรรมนี้ง่ายกว่ากลไกการลองซ้ำครั้งก่อนๆ มาก คุณสามารถใช้ตัวดำเนินการ delay ที่แตกต่างกันเพื่อให้บรรลุเป้าหมายนี้ได้
.combineLatest )ขอบคุณ Dan Lew ที่ให้แนวคิดนี้แก่ฉันในพอดแคสต์แบบแยกส่วน - ตอนที่ # 4 (ประมาณนาทีที่ 4:30)
.combineLatest ช่วยให้คุณสามารถตรวจสอบสถานะของสิ่งที่สังเกตได้หลายรายการพร้อมกันในที่เดียวแบบกะทัดรัด ตัวอย่างที่สาธิตนี้แสดงให้เห็นว่าคุณสามารถใช้ .combineLatest เพื่อตรวจสอบความถูกต้องของแบบฟอร์มพื้นฐานได้อย่างไร มีอินพุตหลัก 3 รายการสำหรับแบบฟอร์มนี้ที่จะถือว่า "ถูกต้อง" (อีเมล รหัสผ่าน และตัวเลข) แบบฟอร์มจะเปลี่ยนใช้ได้ (ข้อความด้านล่างเปลี่ยนเป็นสีน้ำเงิน :P) เมื่ออินพุตทั้งหมดถูกต้อง หากไม่เป็นเช่นนั้น ระบบจะแสดงข้อผิดพลาดกับอินพุตที่ไม่ถูกต้อง
เรามีสิ่งที่สังเกตได้อิสระ 3 รายการซึ่งติดตามการเปลี่ยนแปลงข้อความ/อินพุตสำหรับแต่ละฟิลด์แบบฟอร์ม ( WidgetObservable ของ RxAndroid มีประโยชน์ในการตรวจสอบการเปลี่ยนแปลงข้อความ) หลังจากสังเกตการเปลี่ยนแปลงเหตุการณ์จากอินพุต ทั้ง 3 รายการ ผลลัพธ์จะถูก "รวม" และแบบฟอร์มจะได้รับการประเมินความถูกต้อง
โปรดทราบว่าฟังก์ชัน Func3 ที่ตรวจสอบความถูกต้อง จะเริ่มทำงานหลังจากอินพุตทั้ง 3 รายการได้รับเหตุการณ์การเปลี่ยนแปลงข้อความเท่านั้น
ค่าของเทคนิคนี้จะชัดเจนมากขึ้นเมื่อคุณมีจำนวนช่องป้อนข้อมูลในแบบฟอร์มมากขึ้น การจัดการกับบูลีนเป็นอย่างอื่นจะทำให้โค้ดยุ่งเหยิงและยากต่อการติดตาม แต่การใช้ .combineLatest ตรรกะทั้งหมดนั้นรวมอยู่ในบล็อกโค้ดขนาดเล็กที่ดี (ฉันยังคงใช้บูลีน แต่นั่นก็เพื่อทำให้ตัวอย่างอ่านง่ายขึ้น)
เรามีแหล่งที่สังเกตได้สองแหล่ง: แคชของดิสก์ (เร็ว) และการโทรผ่านเครือข่าย (ใหม่) โดยทั่วไปแล้วดิสก์ Observable จะเร็วกว่าเครือข่าย Observable มาก แต่เพื่อสาธิตการทำงาน เรายังใช้ดิสก์แคชปลอม "ช้ากว่า" เพื่อดูว่าผู้ปฏิบัติงานทำงานอย่างไร
สิ่งนี้แสดงให้เห็นโดยใช้ 4 เทคนิค:
.concat.concatEager.merge.publish + รวม + takeUntilเทคนิคที่ 4 อาจเป็นสิ่งที่คุณต้องการใช้ในที่สุด แต่ก็น่าสนใจที่จะศึกษาความก้าวหน้าของเทคนิคต่างๆ เพื่อทำความเข้าใจว่าทำไม
concat เยี่ยมมาก จะดึงข้อมูลจาก Observable แรก (ดิสก์แคชในกรณีของเรา) จากนั้นเครือข่าย Observable ต่อมา เนื่องจากแคชของดิสก์น่าจะเร็วกว่า ทุกอย่างจึงดูดีและดิสก์แคชก็ถูกโหลดอย่างรวดเร็ว และเมื่อการโทรผ่านเครือข่ายเสร็จสิ้น เราจะสลับผลลัพธ์ "ใหม่"
ปัญหาของ concat คือสิ่งที่สังเกตได้ในภายหลังจะไม่เริ่มด้วยซ้ำจนกว่าสิ่งที่สังเกตได้แรกจะเสร็จสมบูรณ์ นั่นอาจเป็นปัญหาได้ เราต้องการให้สิ่งที่สังเกตได้ทั้งหมดเริ่มต้นพร้อมกัน แต่ให้ผลลัพธ์ในแบบที่เราคาดหวัง โชคดีที่ RxJava แนะนำ concatEager ซึ่งทำอย่างนั้นจริงๆ มันเริ่มต้นทั้งสิ่งที่สังเกตได้ แต่จะบัฟเฟอร์ผลลัพธ์จากอันหลังจนกว่าสิ่งที่สังเกตได้ในอดีตจะเสร็จสิ้น นี่เป็นตัวเลือกที่ทำงานได้อย่างสมบูรณ์
บางครั้งคุณเพียงต้องการเริ่มแสดงผลลัพธ์ทันที สมมติว่ารายการแรกที่สามารถสังเกตได้ (ด้วยเหตุผลแปลก ๆ บางอย่าง) ใช้เวลานานมากในการรันผ่านรายการทั้งหมด แม้ว่ารายการแรก ๆ จากการสังเกตรายการที่สองลงมาตามสายแล้วก็ตาม ก็จะถูกจัดคิวโดยบังคับ คุณไม่จำเป็นต้อง "รอ" กับสิ่งที่สังเกตได้ใดๆ ในสถานการณ์เหล่านี้ เราสามารถใช้ตัวดำเนิน merge โดยจะแทรกรายการต่างๆ เมื่อมีการปล่อยออกมา วิธีนี้ใช้ได้ผลดีและเริ่มแสดงผลลัพธ์ทันทีที่ปรากฏขึ้น
เช่นเดียวกับโอเปอเรเตอร์ concat หาก Observable ตัวแรกของคุณเร็วกว่า Observable ตัวที่สองเสมอ คุณจะไม่พบปัญหาใดๆ อย่างไรก็ตาม ปัญหาของ merge คือ: หากแคชปล่อยรายการด้วยเหตุผลแปลก ๆ หรือสังเกตได้ช้ากว่า หลังจากที่ สังเกตได้ใหม่กว่า/ใหม่กว่า รายการนั้นจะเขียนทับเนื้อหาที่ใหม่กว่า คลิกปุ่ม "MERGE (SLOWER DISK)" ในตัวอย่างเพื่อดูว่าปัญหานี้เกิดขึ้นจริง @JakeWharton และ @swankjesse มีส่วนร่วมไปที่ 0! ในโลกแห่งความเป็นจริง สิ่งนี้อาจไม่ดี เนื่องจากหมายความว่าข้อมูลใหม่จะถูกแทนที่โดยข้อมูลดิสก์เก่า
เพื่อแก้ไขปัญหานี้ คุณสามารถใช้การผสานร่วมกับตัวดำเนิน publish ที่ยอดเยี่ยมซึ่งใช้ "ตัวเลือก" ฉันเขียนเกี่ยวกับการใช้งานนี้ในบล็อกโพสต์ แต่ฉันต้องขอบคุณ Jedi JW สำหรับการเตือนเทคนิคนี้ เรา publish เครือข่ายที่สังเกตได้และจัดเตรียมตัวเลือกที่จะเริ่มเปล่งแสงจากแคชของดิสก์ จนถึงจุดที่เครือข่ายที่สังเกตได้เริ่มเปล่งแสง เมื่อเครือข่ายที่สังเกตได้เริ่มส่งสัญญาณ จะไม่สนใจผลลัพธ์ทั้งหมดจากดิสก์ที่สังเกตได้ นี่เป็นสิ่งที่สมบูรณ์แบบและจัดการกับปัญหาใด ๆ ที่เราอาจมี
ก่อนหน้านี้ ฉันใช้ตัวดำเนิน merge แต่สามารถเอาชนะปัญหาผลลัพธ์ที่จะถูกเขียนทับโดยการตรวจสอบ "resultAge" ดูตัวอย่าง PseudoCacheMergeFragment แบบเก่า หากคุณอยากเห็นการใช้งานแบบเก่านี้
นี่เป็นตัวอย่างที่เรียบง่ายและตรงไปตรงมาสุด ๆ ซึ่งแสดงให้คุณเห็นถึงวิธีการใช้ตัวดำเนินการตัว timer interval และ delay ของ RxJava เพื่อจัดการกับกรณีต่างๆ ที่คุณต้องการรันงานในช่วงเวลาที่กำหนด โดยพื้นฐานแล้วบอกว่า NO กับ Android TimerTask
กรณีที่แสดงให้เห็นที่นี่:
มีโพสต์บล็อกประกอบที่อธิบายรายละเอียดในการสาธิตนี้ได้ดีกว่ามาก:
คำถามทั่วไปที่ถูกถามเมื่อใช้ RxJava ใน Android คือ "ฉันจะทำงานต่อที่สังเกตได้ต่อไปได้อย่างไร หากมีการเปลี่ยนแปลงการกำหนดค่าเกิดขึ้น (การหมุนเวียนกิจกรรม การเปลี่ยนภาษา ฯลฯ )"
ตัวอย่างนี้แสดงกลยุทธ์หนึ่งให้คุณเห็น ได้แก่ โดยใช้เศษที่สะสมไว้ ฉันเริ่มใช้ชิ้นส่วนที่เก็บไว้เป็น "ชิ้นส่วนคนงาน" หลังจากอ่านโพสต์ที่ยอดเยี่ยมนี้โดย Alex Lockwood เมื่อไม่นานมานี้
กดปุ่มเริ่มต้นแล้วหมุนหน้าจอตามที่คุณต้องการ คุณจะเห็นการดำเนินการที่สังเกตได้ต่อจากจุดที่ค้างไว้
มีนิสัยแปลกๆ บางอย่างเกี่ยวกับ "ความร้อนแรง" ของแหล่งที่มาที่สังเกตได้ซึ่งใช้ในตัวอย่างนี้ ตรวจสอบโพสต์บล็อกของฉันที่ฉันอธิบายข้อมูลเฉพาะ
ตั้งแต่นั้นมาฉันได้เขียนตัวอย่างนี้ใหม่โดยใช้แนวทางอื่น ในขณะที่แนวทาง ConnectedObservable ได้ผล แต่ก็เข้าสู่ดินแดนของ "มัลติคาสต์" ซึ่งอาจยุ่งยาก (ความปลอดภัยของเธรด, .refcount ฯลฯ ) ในทางกลับกัน วิชานั้นเรียบง่ายกว่ามาก คุณสามารถดูว่ามันเขียนใหม่โดยใช้ Subject ที่นี่
ฉันเขียนโพสต์ในบล็อกอีกฉบับเกี่ยวกับวิธีการคิดเกี่ยวกับหัวข้อต่างๆ ที่ฉันพูดถึงเฉพาะเจาะจงบางอย่าง
Volley เป็นอีกหนึ่งห้องสมุดเครือข่ายที่นำเสนอโดย Google ที่ IO '13 พลเมืองใจดีของ GitHub มีส่วนสนับสนุนตัวอย่างนี้ ดังนั้นเราจึงรู้วิธีผสานรวม Volley เข้ากับ RxJava
ฉันใช้ประโยชน์จากการใช้หัวเรื่องอย่างเรียบง่ายที่นี่ จริงๆ แล้ว หากคุณไม่มีไอเท็มของคุณลงมาผ่านทาง Observable อยู่แล้ว (เช่น ผ่านชุดติดตั้งเพิ่มเติมหรือคำขอเครือข่าย) ก็ไม่มีเหตุผลที่ดีที่จะใช้ Rx และทำให้สิ่งต่าง ๆ ซับซ้อน
ตัวอย่างนี้โดยทั่วไปแล้วจะส่งหมายเลขหน้าไปที่หัวเรื่อง และหัวเรื่องจะจัดการกับการเพิ่มรายการ สังเกตการใช้ concatMap และการส่งคืน Observable<List> จาก _itemsFromNetworkCall
สำหรับการเตะ ฉันได้รวมตัวอย่าง PaginationAutoFragment ไว้ด้วย ซึ่งเป็น "การแบ่งหน้าอัตโนมัติ" โดยที่เราไม่จำเป็นต้องกดปุ่ม ควรจะปฏิบัติตามได้ง่ายหากคุณเข้าใจวิธีการทำงานของตัวอย่างก่อนหน้านี้
ต่อไปนี้เป็นการใช้งานแฟนซีอื่นๆ (ในขณะที่ฉันสนุกกับการอ่าน แต่ฉันไม่ได้ใช้มันกับแอปในโลกแห่งความเป็นจริง เพราะโดยส่วนตัวแล้วฉันไม่คิดว่ามันจำเป็น):
แผนภาพ ASCII ด้านล่างแสดงถึงความตั้งใจของตัวอย่างต่อไปของเราด้วยการแต่งตัวสวย f1,f2,f3,f4,f5 เป็นการเรียกผ่านเครือข่ายโดยพื้นฐานแล้วเมื่อทำไปแล้ว ให้ผลลัพธ์ที่จำเป็นสำหรับการคำนวณในอนาคต
(flatmap)
f1 ___________________ f3 _______
(flatmap) | (zip)
f2 ___________________ f4 _______| ___________ final output
|
____________ f5 _______|
โค้ดสำหรับตัวอย่างนี้เขียนโดย Mr.skehlet คนหนึ่งแล้วในเว็บ ตรงไปที่ส่วนสำคัญสำหรับรหัส มันเขียนด้วย Java ล้วนๆ (6) ดังนั้นจึงค่อนข้างเข้าใจได้หากคุณเข้าใจตัวอย่างก่อนหน้านี้ ฉันจะล้างออกที่นี่อีกครั้งเมื่อเวลาเอื้ออำนวย ไม่เช่นนั้นฉันจะหมดตัวอย่างที่น่าสนใจอื่นๆ
นี่เป็นตัวอย่างง่ายๆ ที่สาธิตการใช้ตัวดำเนินการ . .timeout ปุ่ม 1 จะทำงานให้เสร็จสิ้นก่อนข้อจำกัดการหมดเวลา ในขณะที่ปุ่ม 2 จะบังคับให้เกิดข้อผิดพลาดการหมดเวลา
สังเกตว่าเราสามารถจัดเตรียม Observable แบบกำหนดเองซึ่งระบุวิธีตอบสนองภายใต้ข้อยกเว้นการหมดเวลาได้อย่างไร
using ) โอเปอเรเตอร์ using ค่อนข้างเป็นที่รู้จักน้อยและยากต่อ Google อย่างฉาวโฉ่ เป็น API ที่สวยงามที่ช่วยตั้งค่าทรัพยากร (ราคาแพง) ใช้งานแล้วกำจัดทิ้งด้วยวิธีที่สะอาด
ข้อดีของโอเปอเรเตอร์นี้คือ มีกลไกในการใช้ทรัพยากรที่อาจมีราคาแพงในลักษณะที่มีขอบเขตจำกัด การใช้ -> ตั้งค่า ใช้งาน และกำจัด คิดว่าการเชื่อมต่อ DB (เช่นอินสแตนซ์ Realm), การเชื่อมต่อซ็อกเก็ต, การล็อคเธรด ฯลฯ
Multicasting ใน Rx เปรียบเสมือนศิลปะแห่งความมืด มีคนไม่มากนักที่รู้วิธีดึงมันออกมาโดยไม่ต้องกังวล ตัวอย่างนี้มีสมาชิกสองคน (ในรูปแบบของปุ่ม) และอนุญาตให้คุณเพิ่ม/ลบสมาชิก ณ เวลาที่ต่างกัน และดูว่าตัวดำเนินการที่แตกต่างกันมีพฤติกรรมอย่างไรภายใต้สถานการณ์เหล่านั้น
การสังเกตแหล่งที่มาเป็นตัวจับเวลา ( interval ) ที่สามารถสังเกตได้ และเหตุผลที่เลือกสิ่งนี้คือตั้งใจเลือกสิ่งที่สังเกตได้แบบไม่สิ้นสุด ดังนั้นคุณจึงสามารถทดสอบ/ยืนยันว่าการทดสอบแบบหลายผู้รับของคุณจะรั่วไหลหรือไม่
ฉันยังได้พูดคุยเกี่ยวกับ Multicasting อย่างละเอียดที่ 360|Andev หากคุณมีความชอบและเวลา ฉันขอแนะนำให้ดูการพูดคุยนั้นก่อน (โดยเฉพาะส่วนการเรียงสับเปลี่ยนของตัวดำเนินการ Multicast) จากนั้นลองศึกษาตัวอย่างที่นี่
ตัวอย่างทั้งหมดที่นี่ได้รับการโยกย้ายเพื่อใช้ RxJava 2.X
เราใช้ไลบรารี Interop ของ David Karnok ในบางกรณี เนื่องจากไลบรารีบางตัว เช่น RxBindings, RxRelays, RxJava-Math ฯลฯ ยังไม่ได้ถูกย้ายไปยัง 2.x
ฉันพยายามตรวจสอบให้แน่ใจว่าตัวอย่างไม่ได้ถูกสร้างขึ้นมามากเกินไป แต่สะท้อนถึงกรณีการใช้งานจริง หากคุณมีตัวอย่างที่เป็นประโยชน์ที่คล้ายกันซึ่งสาธิตการใช้ RxJava โปรดส่งคำขอดึงมาได้เลย
ฉันกำลังคิดเรื่อง RxJava เหมือนกัน ดังนั้นหากคุณรู้สึกว่ามีวิธีที่ดีกว่าในการทำตัวอย่างที่กล่าวมาข้างต้น ให้เปิดประเด็นเพื่ออธิบายว่าทำอย่างไร ยิ่งไปกว่านั้น ให้ส่งคำขอดึงข้อมูล
การทำเกลียว Rx เป็นธุรกิจที่ยุ่งวุ่นวาย เพื่อช่วยโปรเจ็กต์นี้ใช้เครื่องมือ YourKit ในการวิเคราะห์
YourKit สนับสนุนโครงการโอเพ่นซอร์สด้วยเครื่องมือที่เป็นนวัตกรรมและชาญฉลาดสำหรับการตรวจสอบและจัดทำโปรไฟล์แอปพลิเคชัน Java YourKit เป็นผู้สร้าง YourKit Java Profiler
ได้รับอนุญาตภายใต้ Apache License เวอร์ชัน 2.0 ("ใบอนุญาต") คุณสามารถขอรับสำเนาใบอนุญาตได้ที่
http://www.apache.org/licenses/LICENSE-2.0
เว้นแต่กฎหมายที่ใช้บังคับกำหนดหรือตกลงเป็นลายลักษณ์อักษร ซอฟต์แวร์ที่เผยแพร่ภายใต้ใบอนุญาตนี้จะถูกแจกจ่าย "ตามที่เป็น" โดยไม่มีการรับประกันหรือเงื่อนไขใดๆ ทั้งโดยชัดแจ้งหรือโดยนัย ดูใบอนุญาตสำหรับภาษาเฉพาะที่ควบคุมการอนุญาตและข้อจำกัดภายใต้ใบอนุญาต
คุณยอมรับว่าการสนับสนุนทั้งหมดในพื้นที่เก็บข้อมูลนี้ ในรูปแบบของการแก้ไข คำขอดึง ตัวอย่างใหม่ ฯลฯ เป็นไปตามใบอนุญาตที่กล่าวถึงข้างต้น
