iMacbaszii's Blog

Multi-threading และการทำงานแบบ Concurrency เป็นอีกเรื่องสำคัญในการเขียนโปรแกรมสมัยใหม่ และแน่นอนถ้าพูดถึงเรื่องนี้บน Apple Platform สิ่งแรกที่เรานึกถึงกันคงจะเป็น Grand Central Dispatch ซึ่งเป็น C-style API ที่อยู่กับเรามาช้านาน แค่อยู่บน Objective-C ก็ไม่สวยแล้ว พอยิ่งมาอยู่ภาษาสมัยใหม่อย่าง Swift ยิ่งรู้สึกไม่เป็นมิตรใหญ่ที่ต้องมาเขียน C-style แบบนี้ (จริงๆ ก็มี NSOperationQueue มาให้ตั้งนานแล้วนะ แต่ส่วนตัวก็ยังไม่ชินกับมันอยู่ดี) พอมาใน Swift 3 นั้น Apple ได้ยกเครื่อง libdispatch (อีกชื่อเรียกผ่าน Clang Foundation) หรือ Grand Central Dispatch ที่เราเคยรู้จักใหม่ทั้งหมด ซึ่งวันนี้จะมา Overview ให้ดูคร่าวๆ ว่าหน้าตาเปลี่ยนไปแค่ไหนบ้าง (ผมเคยกล่าวคร่าวๆ ไว้แล้วที่ ภาพรวมความเปลี่ยนแปลงของ Swift 3 ) dispatch_async สำหรับ API ตัวนี้ เมื่อก่อนเราต้องกำหนดวิธีการก่อนว่า เราจะสั่งให้งานที่เรากำลังจะทำเป็นแบบ synchronus หรือ asynchronus จากนั้นค่อยเลือกว่าจะให้ queue ตัวไหนเป็นคนจัดการ แต่ของใหม่จะกลับกระบวนการกัน โดยที่เราสร้าง queue ขึ้นมาก่อนแล้วค่อยจัดการเรื่องวิธีการ...

หลังจากงาน WWDC'16 ที่ผ่านมา Apple ก็ได้ขยับเวอร์ชั่นของภาษา Swift ไปอีกขั้นหนึ่ง นั่นคือ Swift 3 นั่นเอง ซึ่งหลังจากที่ Apple เปิด Open Source มาได้ประมาณครึ่งปี ก็มีคนช่วยกันพัฒนามากมาย ถึงขนาดที่ว่า การเปลี่ยนส่วนใหญ่ของ Swift 3 มาจาก Proposal ทั้งหลายที่เกิดขึ้นบน Swift Official Repository เลยทีเดียว โดยสามารดูการเปลี่ยนแปลงหลักๆ นอกเหนือจากที่ผมนำมายกตัวอย่างได้จาก ที่นี่ What's New in Swift ถ้าเกิดใครสนใจในรายละเอียดการเปลี่ยนแปลงและข้อเสนออื่นๆ  ได้ที่โครงการ Swift Evolution ที่นี่ครับ โดยใน Blog นี้จะบอกเพียงแค่การเปลี่ยนแปลงคร่าวๆ ที่เราจะต้องเจอก่อนที่จะเปลี่ยน Code ไปเป็น Swift 3 ในอนาคต ข่าวดีก็คือ เรายังคงใช้ Swift 2.3 ต่อไปได้เรื่อยๆ ครับ ไม่มีปัญหาใดๆ เปลี่ยนเมื่อเราพร้อมที่จะเปลี่ยน โดยในแต่ละหัวข้อจะสามารถคลิกเข้าไปดู Proposal ที่เกี่ยวข้อง ที่ผมทำไว้ให้ได้ด้วย ซึ่งโค้ดที่มาจาก Proposal ก็อาจจะมีบางส่วนที่ไม่เหมือนกันกับ Swift 3 จริงๆ ทั้งนี้ก็คงจะต้องตามอัพเดทจาก Official Language Reference ของ Apple เพื่อความถูกต้องอีกครั้งครับ Swift A...

วันนี้จะแบ่งปันอะไรที่ได้มาจากการลองเล่นของเล่นตัวหนึ่งจาก Facebook ถ้าใครคุ้นตา ลองเปิด Facebook App ขึ้นนะครับ (ควรจะ Kill Process ไปก่อน) ในขณะที่กำลังโหลด News Feed อยู่นั้น คุณจะเห็นหน้าจอประมาณนี้ พร้อม Effect ที่เรียกว่า Shimmering มาลองดูวิธีทำกันครับ ไม่ยากอย่างที่คิด เพราะ Facebook เตรียมของให้เราแล้วนั่นคือ https://github.com/facebook/Shimmer คราวนี้ผมจะลองสร้าง Toy Project ตัวหนึ่งที่เป็น UITableView-based ธรรมดาเลย โดยผลลัพธ์สุดท้ายก็จะมีแค่นี้แหละ แสดงชื่อและอีเมล์ ขั้นตอนแรกให้สร้าง Prototype Cell อีกตัวขึ้นมาก่อน โดยให้มีโครงสร้างเหมือนกับ Prototype Cell ที่มีข้อมูลของเรา แต่แทนที่ Object ต่างๆ ด้วย UIView และอย่าลืมตั้งค่า Custom Class เป็น FBShimmerView ด้วยแบบนี้ ในที่นี้ผมตั้งชื่อ Cell ตัวนี้ว่า PlaceholderCell ต่อมาเนื้อหาใน PlaceholderCell ของผมก็จะเป็นประมาณนี้ Wait for the Code .... โดยจัดการสร้างและใส่ Content View ตอน -awakeFromNib และให้เริ่มแสดง Shimmering effect หลังจากที่ Auto Layout ทำงานเสร็จแล้ว คราวนี้ผมจะข้ามไปในส่...

ผมเห็นโค้ดหลายคน และโค้ดผมเอง เมื่อหลายเดือนก่อนที่เริ่มเอา Swift เข้ามาใช้อย่างจริงจังในออฟฟิศ พบว่า Memory Leak กระจายเลยครับ... ดีนะ ที่รู้ตัวทันก่อนจะส่งมอบโค้ดชุดนั้นให้ลูกค้าไป Delegation Pattern เป็นสิ่งที่เราใช้กันหลายจุด ใน iOS Development ในสมัยของการเขียน Objective-C ตามหลักการของ ARC นั้น เราควรประกาศตัวแปร delegate ใน class ที่ต้องการรับความช่วยเหลือเมื่อถึงเวลาใดๆ เป็น weak เนื่องจากปัญหา Retain Cycle ส่วนเกิดได้อย่างไร นั้นลองไปศึกษาดูเองนะครับ และเมื่อเราถูกสอนมาแบบนั้น ทำให้เรามาเขียนแบบนี้กับ Swift แล้วพบว่าโดน compiler ด่าแบบนี้ หลายคนก็เลยเอาออก เพราะว่าเอาออกแล้วมันใช้ได้... และคิดว่า Swift น่าจะฉลาดพอที่จะใส่ให้เราเอง แบบ @IBOutlet ซึ่งผิดถนัดครับ ไม่มีการใช้ให้อัตโนมัติใดๆ เนื่องจาก Protocol บน Swift จะใช้ในแนวทางของการทำ Type Sementics มากกว่า โดยธรรมชาติของมันเอง เลยทำตัวต่างจากคำว่า class นิดหน่อย และการประกาศ weak identifier ซึ่งต้องประกาศกับ object ใดๆ ที่เป็น class เท่านั้นตามที่โดนตักเตือน ในการใช้งาน Delegation Pattern ในรูปแ...

Selectors ใครหลายคนคงจะจำสิ่งนี้ได้ดี เพราะหลายๆ อย่างบน Cocoa Touch Framework ยังใช้สิ่งนี้อยู่ มาดูกันว่า ก่อนและหลัง Swift 2.2 ที่พึ่งออกมา มีอะไรเปลี่ยนแปลงไปบ้าง ในยุคก่อน Swift 2.2 และสมัย Objective-C  นั้น Selectors เป็นเพียง String สายหนึ่งซึ่งใช้อ้างถึง method ที่อยู่ใน File เดียวกันขะ Runtime ซึ่งข้อเสียของการใช้ String นั้นคือเกิด Error จากการพิมพ์ผิดพลาดได้ง่าย และไม่มี Autocomplete มาช่วยเหลือ เช่น Wait for the Code .... หนึ่งในการตั้งชื่อดีๆ ให้กับ Selectors นั่นคือการเขียนประเภทของ object ที่จะทำให้เกิด action ตามด้วย action ในกรณีด้านบน "ปุ่มถูกกด" นั่นเอง และอย่าลืมว่าเราควรส่ง object ดังกล่าวเป็น parameter ให้กับฟังก์ชั่นที่เขียนขึ้นมาด้วย จะเรียกว่าเป็นธรรมเนียมก็ได้ แม้เราไม่จำเป็นที่จะต้องใช้มันก็ตามที ลองดูตัวอย่างอื่นๆ กันบ้าง Wait for the Code .... ใน Swift 2.2 นั้น Apple ช่วยให้เราเขียน Selector ได้มั่นใจมากขึ้น ถึงแม้ syntax ที่ออกมาจะดูไม่ได้สวยมากเท่าไหร่นัก (บทความต้นฉบับใช้คำว่า Ugly เลยทีเดียว) และมันจะยิ่งหนักไปใหญ่เมื่อเร...

ถ้าบอกว่าคลาสใน UIKit ตัวไหน ที่เราใช้กันบ่อยมากที่สุด ก็คงจะหนีไม่พ้น UITableView และ UICollectionView นั่นแหละนะ และงานที่เราต้องทำกันบ่อยๆ นอกเหนือจากการ Custom Cell ให้เป็นรูปแบบที่เราต้องการ ถ้า Cell ที่เราสร้างขึ้นอาจจะมีการนำมาใช้ใหม่ สิ่งที่เราต้องทำคือ สร้าง XIB file ขึ้นมาและก็ต้อง Register ให้รู้ด้วยว่าจะมี Cell อีกรูปแบบเข้ามาในระบบ คราวนี้มาดูเวลาเราเขียนโค้ดแบบปกติกันก่อน ว่าที่ผ่านมา ผมและหลายๆ คนทำกันยังไง เริ่มจาก UITableView และ UICollectionView นั้นมี API ที่เอาไว้ให้เรา Register Cell ดังนี้ Wait for the Code .... และวิธีการเขียน Datasource โดยทั่วไปก็จะเขียนกันแบบนี้ โดยอ้างถึง Reuse Identifier ด้วยค่าคงที่ที่ประกาศไว้ด้านบน Wait for the Code .... คราวนี้เราจะมาลองดูกันว่า เราจะทำให้โค้ดชุดนี้เรียบง่าย และปลอดภัยขึ้นได้อย่างไร ด้วยการใช้ Feature ของ Swift นั่นคือ Generics และ Protocol Extension เริ่มจาก ปกติแล้วผมก็จะตั้ง Reuse Identifier ตามชื่อ Cell Class (Nib File) นั่นแหละ เช่น Class ชื่อ BookCell ก็ตั้งว่า BookCell  ในเ...