Native Swing ... อุดจุดบอด ให้ Java Desktop

พอดีไปรับอาสา Coaching ให้กับเด็ก interns ฝั่ง London ของที่ออฟฟิศ
เลยได้ของเล่นมาเล่นเยอะแยะมากมาย ... ไม่ว่าจะเป็น JavaFX หรือแม้แต่ SWT ...

สิ่งที่ได้เห็นคือ ความแตกต่างกันในเรื่องของ ความกระตือรือร้น
รวมไปถึง ความใฝ่รู้ในเรื่องที่ฝึกงาน ...
ระหว่างเด็กไทยกับเด็กฝรั่ง ในปีนี้ นั้นเห็นได้ชัดเจนมาก...
อาจจะเพราะทางฝั่งฝรั่ง assign งานให้โหดมาก
(แต่ได้ข่าวว่าฝั่งไทยก็โหดพอกัน)
และด้วยความที่เป็น Master Degree ก็เป็นได้ ...

ขอออกตัวแรงๆ ก่อนเลยว่า ส่วนตัวแล้ว ไม่ได้มองว่า Java เร็วส์ หรือ Java ค้างส์
แต่มองว่า Java คือ เครื่องมือทำมาหากิน ... ถึงแม้มันจะแย่ หรือ จะดียังไง
ทุกวันนี้ก็ยังต้องนั่งเขียนมัน ... นั่งแก้บั๊กมัน ... นั่งออกแบบมัน ...
และยังต้องนั่งปวดหัวกับมัน ดังนั้นจึงให้ความใส่ใจในการทำงานกับมัน ... 
ที่ไม่ได้เกิดขึ้นเพราะความชอบส่วนตัว หรือ ความเป็น zealot กากๆ แต่อย่างใด ...

เข้าเรื่องเลยดีกว่า ...
ตั้งแต่ทำ java desktop มาจะเกือบ 3 ปีได้ ... ก็เจอจุด pain หลายๆ อย่าง ...
ไม่ว่าจะเป็น code เมพ ... design แหล่ม ... หรืออะไรก็แล้วแต่ ...
สิ่งที่เป็นจุดบอดสำคัญๆ ของ java desktop คือ ยังเป็น UI ยุคเก่า ....
ที่แม้ชาวบ้านจะทำ Graphic เป็นระดับ HD ไปแล้ว ... java ก็ยังวิ่งอยู่ระดับ pixel ต่อไป ...

แต่หลังจากได้ coaching เด็ก interns ก็พบว่ายังมีบาง Lib ที่ไม่เคยคิดจะเข้าไปยุ่งกับมัน ...
มีความสามารถพอที่จะช่วยให้ java คลานต่อไปได้อีกหน่อย นั่นคือ SWT ...


SWT คือ UI toolkit อีกชุดของ java ที่พัฒนาโดย .. IBM ...
หลักๆ ของ SWT ที่แตกต่างจาก AWT คือ SWT จะพยายามทำทุก component ของ Java
ให้เป็น Native Component ... โดยผ่าน JNI ... ข้อดีข้อเสียของมันเป็นดังเหมือนดาบสองคม
นั่นคือ .... ดีที่เร็วส์ ... แต่เสียที่ไม่ cross platform (หรือพูดง่ายๆว่าต้องมี for window , for linux )

จึงเป็น Lib ข้าวนอกนา ในสายตาของคนที่วิ่งอยู่บน Standard JDK มาก ....
ซึ่งการรัน SWT พร้อมกับ Swing นั้นค่อนข้างที่จะบาป ยิ่งกว่าการเขียน AWT ผสมกับ Swing ..
เพราะ Thread ที่ใช้ ในการ render component นั้น จะแยกกันทำงาน ทำให้ยากต่อการ debug มาก ...

แต่ทั้งหมดนั้น ... เป็นเรื่องที่เกิดขึ้นเมื่อ 10 ปีที่ผ่านมา ....
ในวันนี้ มีคนหัวใส เขียน Bridge ระหว่าง SWT และ Swing ขึ้นมา ชื่อว่า Native Swing

คร่าวๆ เกี่ยวกับ Native Swing คือเป็น wrapper ที่ Bridge ระหว่าง Swing กับ SWT
และ SWT กับ Window Native โดยใช้ OLE Bridge อีกต่อนึง .... (เหมือนเขียน VB เรียก ActiveX)
ทำให้สามารถ integrate SWT Component ที่มีอยู่แล้ว ขึ้นมาใช้ได้ใน Swing App ปกติ ...
ที่น่าสนใจของ Library ตัวนี้ ก็คือ SWT Component อันได้แก่

JWebBrowser

ไว้สำหรับ embed Browser ลงใน Swing App ... ที่ครั้นจะรอ JavaFX ก็คงอีกนาน
(แม้ Beta version ออกมาก็ยังกาก เกินกว่าจะเทียบ native ได้ )
ข้อดีของ component ตัวนี้คือ เป็นการดึง Native Feature ของ IE มาใช้ ....
ดังนั้น หากเครื่องที่ลง IE9 ไว้จะพบกับความเร็วส์ ในการโหลด ตามประสิทธิภาพของ IE
พร้อมทั้งอาจจะเจอความห่วย ในรุ่นเก่าๆ ลงมาไปพร้อมกัน ..... ซึ่งหากไม่พอใจ
ก็สามารถใช้ XULRunner ของ Firefox มา embed แทนได้ ....
แต่ package application ก็จะมีขนาดใหญ่ขึ้น ตามขนาดของจิ้งจอกไฟ ...

 

ตัวต่อมาคือ

JFlashPlayer 

เป็น component ที่ดึง Flash ActiveX มาใช้ได้อย่าง ... เนียนมาก ... เนียนจนขนาดที่
สามารถทำ bridge กลับระหว่าง Java กับ Flash ได้ .... ซึ่งหากใครที่มองว่า Java Desktop
เป็น UI ล้าสมัย ... ก็สามารถทำ Flash มาต่อกับ API ที่มีอยู่เดิมให้มีลูกเล่นเพิ่มเติมได้มากขึ้น
ทั้งนี้ ก็ขึ้นอยู่กับ code ของ project นั้นๆ ว่ามีความ messy เพียงใด (ฮา)

มีหลาย component มากขี้เกียจรีวิวเยอะ เอาตัวสุดท้ายแล้วกัน ...

JMediaPlayer 

แทบน้ำตาไหลสำหรับ video player ที่สามารถเล่นบน java ได้ ...
ซึ่ง Lib นี้ก็มี bridge ให้ใช้กับ VLC ได้อีกเช่นกัน ...

สรุป
แม้ว่า SWT จะทำได้หลายอย่างโดยที่มี Native Swing เป็นตัวจัดการให้กับ Swing
แต่ทั้งนี้ก็ขึ้นอยู่กับว่า Feature ที่เป็น native นั้นๆ สามารถรองรับความต้องการของลูกค้า
รวมไปถึง time-to-market ได้ดีแค่ไหน .... และที่สำคัญคือ ...
License ในการ distribute เป็นอย่างไร ....
การทำ commercial app ที่มีลักษณะเป็น product ... ยากกว่าที่คุณคิดเยอะ ...

Vavar ปะทะ Java Swing #5 : Component Painting

จาก ตอนที่ 4 ที่ได้พูดถึง EDT และ Swing MVC ไปแล้ว

ในตอนที่ 5 นี้เลยจะพูดถึง Painting ครับ

ประกาศ : บทความเหล่านี้เขียนด้วยความคิดเห็นของตัวเองล้วนๆ ... 
ผิดถูกยังไง สามารถเสนอแนะโดย post comment ด้านล่างได้ครับ :)



Swing Component หรือแม้แต่  AWT Component ใน Java นั้นสิ่งที่จำเป็นมากๆ
ในการออกแบบ UI ก็คือการทำ Custom Paint ที่ให้ LookAndFeel  ของตัว Component นั้น
เป็นอย่างที่เราได้ออกแบบไว้ ... โชคร้ายของ AWT Component ที่ ​Java ไม่ได้ออกแบบตรงจุดนี้มาให้
โดยให้เหตุผลว่า AWT เป็น Heavy Weight Class ที่ออกแบบมาให้เป็น Native Component ของ OS นั้นๆ
การจะปรับเปลี่ยน LookAndFeel สำหรับ AWT จึงไม่ใช่ทางออกนัก ....

แต่ก็เป็นโชคดีสำหรับ ​Swing Component ที่ Sun ทำ LookAndFeel Architecture มาให้ใช้
โดยตัว Swing เองอย่างที่เป็น Sequence Diagram ในตอนที่ 4 จะเห็นว่า
JComponent ทั้งหลายเปรียบเสมือน Controller เท่านั้น ส่วนที่เป็น View คือส่วนที่เป็น UI Class
ที่ฝังอยู่ใน LookAndFeel ....

ข้อดีของการแยก Class ดังกล่าวทำให้เราสามารถปรับเปลี่ยนหน้าตาของ UI
โดยไม่กระทบกับ Behavior ที่มีของ Component นั้นๆ ได้ ....
ยกตัวอย่างเช่น

ปุุ่ม .....
หน้าที่ของปุ่มคือรอรับ event การ click โดยจะ click ซ้าย หรือ ขวา ก็ขึ้นอยู่กับ
manage code ที่ทำการตอบรับ action นั้น

แน่นอนว่าหากการเปลี่ยน UI แล้วกระทบกับ Behavior ดังกล่าวดูจะแปลกๆ
ตั้งแต่ลักษณะการ Design ของ Behavior ก่อนหน้านี้แล้ว ....

การ Paint บน Swing Component จึงได้เปลี่ยนการทำงานใหม่ที่แตกต่างไปจาก AWT Component
ที่มีการเรียก paint() method แล้วทำการวาด Component ทั้งหมด

ใน Best Practice ของ Swing Component แนะนำว่าหากต้องการทำ Custom Paint ที่ไม่ขึ้นกับ
LookAndFeel ก็สามารถทำได้โดยการ override paintComponent() (ไม่มี s) method เพื่อให้สามารถ
แสดงผลได้อย่างที่เราต้องการ .....

สิ่งที่สำคัญสำหรับการ paint ใน Swing Component คงจะหนีไม่พ้น 3 สิ่งดังต่อไปนี้

1. Opaque - การแสดงผลแบบ Transparent Background.
2. Border - ขอบของ Component ที่ต้องการให้แสดงผล
3. Inset -  ขอบช่องว่างที่ต้องการให้แสดงผล มักจะถูก set จาก Border

ซึ่งหากเปรียบเทียบกับการเขียน CSS ทั้งสามส่วนนี้คงหนีไม่พ้น คำสั่งดังต่อไปนี้

1. background:
2. border:
3. padding:

จะเห็นได้ว่าจริงๆ แล้ว Component ของ Swing นั้นก็ไม่ได้แตกต่างจาก
การเขียน HTML เท่าไหร่นัก เพียงแต่การใช้งานจะต้องมีการจัด layout
เพื่อให้ได้รูปแบบตามที่เราต้องการ ได้ยากกว่าเท่านั้นเอง ...
แต่โชคร้ายของ Swing Component ที่ Sun ออกแบบมาไม่ดีนัก
ที่ระบุให้ Border เป็น Component ที่ถูกวาดหลังสุด ทำให้การที่เราจะทำ
Component ที่มีขอบ ตามประเภท Border ที่เรา assign ให้กับ Component นั้น ยากมาก
ซึ่งจะต้องหาวิธีมาประยุกต์ใช้เพื่อทำงานในลักษณะดังกล่าว ...

ทำให้มี trick มากมายในการประยุกต์ใช้เพื่อให้ได้รูปแบบตามที่เราต้องการ ....

โดยส่วนตัวคิดว่าไม่ค่อยดีนักสำหรับ การ open ให้ implement เยอะขนาดนี้ เพราะหาก
Developer ไม่สนใจที่จะอ่าน Architect ของ Swing จะทำให้การ ​Manage sourcecode นั้นลำบากมาก
ด้วยอายุของ Swing Toolkit ก็ปาไปเกือบ 10 ปี แล้วจึงคิดว่า javaFX น่าจะมีอะไรเปลี่ยนแปลง
ในจุดนี้ไม่มาก ... ก็น้อย ....

แต่ชีวิตก็ยังต้องดำเนินต่อไป  .... ไปเขียน silverlight ดีกว่า ๕๕๕

Vavar ปะทะ Java Swing #4 : EDT + MVC

มาถึงตอนที่ 4 ขอแอบบ่นขั้นเวลาหน่อยครับ ...

เป็นธรรมดาที่เวลาเขียน Application ใดๆ ก็ตามที่ต้องมี User Input  ...
สิ่งที่ต้องตามมาก็คือ User Interface ... แน่นอนว่า คงไม่มีใครอยากเขียน code เยอะๆ ...
เพื่อแสดง power แน่นอน ... แต่สิ่งที่ต้องมาคู่กับการ Design User Interface นั้น ...
จำเป็นที่จะต้องสนใจ input + output ของ process นั้นๆ ด้วย ....
เพราะหากเราคำนึงถึงเพียงแค่การแสดงผล ให้กับ user บนหน้าจอ คงจะไม่ถูกต้องนัก ...

มีตลกร้ายอยู่เรื่องนึง สมัยทำ Web Application เมื่อนานมาแล้ว
ด้วยความที่ Web Application นั้น เป็นการทำ Document Management System...
สิ่งที่สำคัญในระบบนั้นคือ

การเก็บเอกสารที่สามารถค้นหาให้ได้ง่ายที่สุดเท่าที่จะทำได้ ...

ไม่ว่าจะเป็น คำพ้องรูป หรือคำพ้องเสียง หรือแม้แต่
ค้นหาจาก "เนื้อข้อมูล" ภายในเอกสาร ก็จะต้องพึงกระทำได้ ...
สิ่งที่เกิดขึ้นจาก Output ที่กล่าวไปเบื้องต้น นั้น ... คือ กระบวนการ Indexing ...
ซึ่งถ้าหาก Design มาไม่ดี ... ระบบโดยรวมก็จะช้าทั้งหมด .....

และสิ่งที่ไม่คาดฝันก็เกิดขึ้น ... อาจจะเพราะด้วย Design ที่ไม่คำนึงถึง Concurrent ที่เกิดจาก
การ input มาจากหลายช่องทาง ( Multi-User ) จึงทำให้ Index Repository ... ล่มสลาย ...
ต้อง ทำการสร้าง index ให้กับเอกสารที่นำเข้าไปแล้วใหม่ทั้งระบบ ... เจ็บกันไป ...

นี่คือตัวอย่างของการคิดแบบง่ายๆ ที่เกิดขึ้นจากการออกแบบ ที่ไม่ได้คำนึงถึง concurrent
ที่เกิดขึ้นในระบบ ... วิธีแก้ มีหลายวิธี ไม่ว่าจะเป็นการทำ Thread Queue หรือแม้แต่การแยก
Indexing Service ไปไว้ในการทำงานทีหลัง ... เท่านี้ก็จะสามารถทำให้ระบบมีประสิทธิภาพมากขึ้นได้ ...

ในการทำ UI ใน Java ก็เช่นกัน ... ใน Java Desktop จะมี Thread อยู่ตัวหนึ่่งที่ชื่อว่า

Event Dispatcher Thread 

หรือที่เรียกสั้นๆ ว่า EDT .... ในส่วนของ EDT นี้ จะเกิดขึ้นทุกครั้งที่มีการส่ง
Event ที่เกิดขึ้นจาก User Input ที่เกิดขึ้นกับ UI ไปหา Listener ที่เราทำการ Add ไว้อยู่ทั้งหมด ...
ซึ่งการเขียน Listener จึงต้องมีความระมัดระวังในการเขียนค่อนข้างมาก เนื่องจากว่าเราจะต้องรู้
"พฤติกรรม" ที่ Listener นั้นๆ จะได้รับ เมื่อเกิดเหตุการณ์ XX , YY , หรือ ZZ เพราะไม่เช่นนั้น
การใส่ Listener เยอะๆ ไป จะทำให้เราไม่สามารถ กำหนดต้นทางของข้อมูลได้เลยว่า มาจากจุดไหน
หรือแม้แต่กำหนด "พฤติกรรม" ที่เราต้องการจะทำได้

ยกตัวอย่างเช่น

ItemListener กับ ActionListener

สิ่งที่แตกต่างกัน ระหว่าง Listener 2 ตัวนี้คือ ...

ItemListener จะทำการ detect ทุึกครั้งเมื่อ Item State นั้นมีการเปลี่ยน  ....
การเปลี่ยนในที่นี้หาก Component ที่ต้องการเพิ่ม Listener นั้น มีเพียง 1 Item ..
เราก็สามารถ trigger Event นั้นได้อย่างง่ายดาย เช่นเดียวกับ ActionListener ที่มีการ "กระทำ"
กับ Component นั้นๆ แต่เมื่อ Component นั้นมี Item มากกว่า 1 items ... สิ่งที่เกิดขึ้นตามมาก็คือ

Item State Event จะถูกส่งมา 2 ครั้ง นั่นคือ

1. Item เก่า ถูก Deselect
2. Item ใหม่ ถูก Select

ซึ่งถ้าเราเขียน code ตรงจุดดนี้ไม่ดี ... หรือการส่งค่า input บางอย่างไปยัง ฐานข้อมูล
ก็จะทำให้เกิด Duplicate Record ได้ง่าย .... ซึ่งจะแตกต่างจาก ActionListener ที่
เราต้อง Handle เพียง 1 Event วิธีแก้ไขง่ายที่สุดคือ
"เลือก implement Listener เฉพาะพฤติกรรมที่เราต้องการ"

การทำงาน ใน EDT ก็ยังมีความต้องระวังอีกจุดหนึ่งนั่นคือ
การนำ "Long-Session Process" ไปประมวลผลใน EDT .... ยกตัวอย่างเช่น
การที่ user กดปุ่ม Save แล้วทำการ Commit ข้อมูลลง Database บนสภาวะ เนตเวิร์คกากๆ
สิ่งที่เกิดขึ้นก็คือเมื่อเราทำการประมวลผลอะไรนานๆ บน EDT จะทำให้ ...

จาวาค้างส์

ดังนั้นสิ่งที่ทำให้ค้างส์ ไม่ใช่ จาวา แต่เป็นเพราะคนเขียน นะจ๊ะ ... จุบุ จุบุ ...
แต่ก็ไม่ต้องแปลกใจว่าทำไม ไม่มีใครคอยบอก / แนะนำ ว่าไม่ควรทำบน EDT ....
ความรู้นี้ก็ได้มากจาก Best Practices ต่างๆ ช่วงหลังๆ ที่ SUN มาเอาจริงเอาจัง
กับ Java-Desktop แล้ว ... ซึ่ง App เก่าๆ ไม่ต้องพูดถึง .... วิ่งอยู่บน EDT ซะเยอะ ... ก็ค้างส์กันไป ...

วิธีแก้แบบง่ายที่สุดในการลด Long-Session Process บน EDT คือการ "แตก" Thread
ให้มาทำงานนอก EDT แล้วหากต้องการ Update Event ใดๆ ที่เกี่ยวกับ UI ให้ใช้

SwingUtilities.invokeLater ( Runable runable )

สิ่งที่ขัดใจจอร์จอีกอย่างเวลาทำการแก้ code ที่เป็น Legacy นั่นคือ
การใช้ UI มาทำการ Handle Process ที่เกี่ยวข้องกับการประมวลผล ...
ยกตัวอย่างเช่น

เอา State ของ Checkbox มากำหนดเงื่อนไขของ Boolean แบบ True / False ซึ่งดูๆ
ไปแล้วอาจจะ Common มากในการที่จะบอกว่า "ก็ disabled ไปสิ เค้าก็แก้ไม่ได้แล้ว"
แต่การ Disabled เป็นเพียงการแก้ปัญหาที่ปลายเหตุเอามากๆ ถ้าเกิดเจอ User เกรียนๆ
ที่ Trigger UI ไปมา แล้วใน Trigger นั้นเป็น การ Query Data 10k Record พร้อมกับต่อ Database ....
ซึ่งถ้าเรามีการ Handle ข้อมูลโดยแบ่งเป็น MVC ที่ดีแล้ว ... ปัญหาดังกล่าวจะขี้เล็บมากๆ
เมื่อเทียบกับการปล่อยมันเอาไว้ แล้วเกิดปัญหาที่รับมือได้ยากทีหลังนั้น
มันค่อนข้างจะคุ้มค่ามากกว่าไม่ใช่เหรอ ?

Vavar ปะทะ Java Swing #3 : Why Swing ?

UI สุดเมพ สมัย ป.โท ..

ประกาศ : บทความเหล่านี้เขียนด้วยความคิดเห็นของตัวเองล้วนๆ ... 
ผิดถูกยังไง สามารถเสนอแนะโดย post comment ด้านล่างได้ครับ :)

ตลอดเวลาที่นั่ง code มา 2-3 เดือน คอยถามตัวเองเสมอว่า
"ทำไมต้อง Swing ?"
"เขียน AWT อย่างเดิมไม่ดีกว่าเหรอ ?"

ก็เหมือนยังเป็นคำถามมาตลอดเวลาภายในหัวสมอง...
เหมือน ตัวมาร กะ ตัวดี ปะทะกันจนปวดหัวไปหลายๆ รอบ ...
แต่พอได้ ลงมือ เขียนจริงๆจังๆ พบว่า ...

ถ้าจะทำ Client GUI ... โดย Java ... ในขณะนี้ ...
คงมีเพียง Swing ที่เป็นคำตอบสุดท้าย ...

จริงๆ แล้วการทำ GUI ด้วย java
ก็ไม่ใช่เรื่องเลวร้ายซักเท่าไหร่ ...
แต่ต้องยอมรับอย่างนึงว่าช่วงตั้งแต่ JRE 1.4 - 1.5 ...
SUN ไปเน้นหนักทาง J2EE มากเกินไป ...
จน Java Desktop มันย่ำแย่ซะจน Developer หลายๆ คน
ตั้งเป็น slogan ให้ว่า

"จาวาค้างส์" 

กันเลยทีเดียว ...

ถ้าอยากรู้ว่ามัน "แย่" ขนาดไหนแนะนำให้รัน app
ที่เป็น JRE 1.5 กับ JRE 1.6 ครับ ... จะเห็นความแตกต่างอย่างรู้สึกได้ :)

อ้อ อีกอย่าง ... ไม่ได้สนับสนุนว่า "จาวาเร็วส์" นะครับ
และก็ไม่ได้เป็น zealot ด้วย .... กลับมาดู Swing ของเรากันต่อดีกว่า ...

ด้วยอายุของ Java Swing แล้ว ... คงปฎิเสธ ไม่ได้ว่าเป็น Techonology ที่ค่อนข้าง "เก่า"
เพราะมัน 10 ปี มาแล้ว ... แต่ยังแก่น้อยกว่าอย่าง MFC
ที่เป็น lib ของ Microsoft อยู่เยอะหน่อย :)

Firewall App บ้านๆ ที่เคยเขียนสมัย ป.ตรี (MFC + C++)

แต่หากด้วยใครเคยเขียน MFC มาบ้าง ก็จะรู้สึกทันทีว่าการเขียน GUI บน Java นั้น ...
ไม่ได้ยากเท่า MFC แต่อาจจะต้องใช้จินตนาการ นิดหน่อย
เพราะหากเขียน code แบบ AWT มันไม่มี Visual Tool ให้ดูขณะที่กำลังเขียน code อยู่ ...
ซึ่งใน Swing ก็มีให้อยู่พอสมควร ดังเช่น netbean หรือ window builder pro ...

โดยตัว Swing เองมีการใช้ MVC Framework เป็น Core Architect
อยู่ตรงกลางโดยแบ่งออกเป็น 3 ส่วนหลักๆ คือ

1. Model
   ใช้ในการเก็บข้อมูลต่างๆ ไม่ว่าจะเป็น การ enabled / disabled
   หรือพูดง่ายๆ ว่า Attribute ทุกอย่างของ Component นั้นจะถูกเก็บอยู่ที่ Model ....
   อย่าง ปุ่ม ( JButton ) ก็จะมี ButtonModel ที่เก็บข้อมูลของปุ่มที่เราสร้างขึ้นนั้นไว้ ...
   เราสามารถเรียกข้อมูลจาก Model มาเพื่ออ่านค่า หรือเปลี่ยนแปลงค่าได้ ...
   ซึ่งการเรียกค่าต่างๆ นั้น จะต้องทำมาจาก Controller หากเราต้องการเปลี่ยนค่าภายใน Model โดยไม่ผ่าน Controller เราจำเป็นที่จะต้อง "Fire" หรือบอกให้ Controller รู้ด้วยว่า ...
   ค่าใน Model มีการเปลี่ยนแปลง ... Controller เองก็จะทำการดึงข้อมูลเพื่อให้
   View ทำการแสดงผลข้อมูลใหม่ให้ถูกต้อง ...  
2. Controller
   หรือเรียกง่ายๆ ว่า Component ... ตัว Controller จะทำหน้าที่จัดการ
   "Behavior" หรือ User Input ต่างๆ ที่ สามารถกระทำกับ Component นั้นให้ได้ถูกต้องตามลักษณะ
   ยกตัวอย่างเช่น setEnabled หรือ setVisible จะเป็น "Behavior" ของ Component ทุกอันที่จะต้องมี ...
3. View
   หรือที่เรียกอีกอย่างว่า UI ... การที่ Component จะทำงานได้ ไม่ได้ขึ้นอยู่กับว่าหน้าตาของ
   Component นั้น มีหน้าตาเป็นอย่างไร ... ตัวอย่างง่ายๆคือ ปุ่มแบบ Turn On/Off  ...
   เราอาจจะใช้ RadioButton แทนการใช้ Button ธรรมดาที่จะต้องมานั่งเขียน Code
   ในการเปลี่ยนสถานะปุ่มอื่นๆ ที่อยู่ภายใต้เงื่อนไขเดียวกันแทนก็ได้ ...

ซึ่งในการเปลี่ยน View หรือ UI นั้น ใน Swing เรียกว่า UI Delegate โดยมีลักษณะตาม
Sequence Diagram ข้างล่างนี้

จะเห็นได้ว่า แต่ละ Component จะมีการไปเรียกใช้ UIManager ซึ่งเป็น class กลางของ Swing ...
จึงทำให้เกิด Concept ที่เรียกว่า LookAndFeel ขึ้นมา ... ทำให้เราสามารถปรับเปลี่ยน UI
ได้อย่างที่เราต้องการ

สรุปแล้วโดย Architect ของ Swing เองก็ออกแบบ มาได้ค่อนข้างมีประสิทธิภาพมาก
มีความเป็น "Mature" UI ToolKit ที่เหมาะในการทำ Application พอสมควร ....

ซึ่งเนื่องจาก Application เดิม เป็น AWT Component ทั้งหมด จึงต้องมีภารกิจในการเปลี่ยน
ให้เป็น Swing เพื่อใช้ Architect ที่ว่านี้ ....
แล้วจะทำได้ยังไงบ้าง ? เจอกันตอนหน้าครับ :)

Renew Vs Renovation

**คำเตือน : บทความนี้ เหมาะสำหรับ Geek

หลายๆ ครั้ง การพัฒนาโปรแกรม ก็มีความยากในการพัฒนา ...
เหตุผลหลักๆ ของการพัฒนาที่ยากนั้น ไม่ใช่เพราะความยากของงาน
แต่เป็นเพราะ solution ที่จะใช้สำหรับงานนั้นๆ มันยากที่จะตัดสินใจ ....
ด้วยโครงสร้าง ของโปรแกรม ที่เป็นลักษณะ Product 
โดยไม่ใช้ 3rd party software มาช่วยทุ่นแรง นั้น ...
สิ่งที่ challenge มากที่สุด คือ การสร้าง compatibility ให้กับตัว Product นั้นๆ 
เพราะเมื่อการที่พัฒนา application ในรูปแบบ Product จะมีข้อจำกัดมากมายที่
Developer ไม่สามารถ control ให้ลูกค้่า(เก่า)ให้ปฎิบัติตามได้ ... 
การเลือก technology  จึงจำเป็นที่จะต้อง คำนึงถึงจุดนี้เช่นกัน ...


การที่ โปรแกรม มีอายุการใช้งานมามากกว่า 3-4 ปี 
โดยพัฒนาตาม Requirement ของ ลูกค้า
จะเป็นสิ่งที่ค่อนข้างขาด Innovation มากพอสมควร ... 
User Interface เป็นอีกจุดนึง ที่มีความคล้างคลึงเช่นเดียวกับ technology .. 
วันนี้ ใ้ช้ง่าย ... พรุ่งนี้อาจจะมี Interface แบบใหม่ที่ใช้งานได้ง่ายกว่าแล้วก็ได้ ...  
ความ challenge จึงอยู่ที่ว่า ผู้พัฒนา จะทำอย่างไรให้ โปรแกรมของตัวเองนั้น 
มี UI ที่ UP-TO-DATE อยู่เสมอ ?? 


การเขียนใหม่ทั้งหมด ( re-new ) เป็นทางออกแบบนึงแต่ไม่สามารถ การันตีได้ว่า 
ของที่ทำใหม่ จะดี / เทียบเท่าของที่มีอยู่เดิม ....

ทางออกที่เลือกสำหรับงานในบางครั้ง จึงจำเป็นที่จะต้องเปลี่ยนจากการคิด
ที่จะ re-new เป็น renovation แทน ดังนั้นด้วย legacy code ต่างๆ 
ยกตัวอย่างเช่น Java AWT ก็ค่อนข้างเป็น Challenge ที่จะคิดว่า 
เราจะเอาอะไรมาเป็น replacement แต่ต้องได้ productivity เท่าเดิม ???


ไม่ว่าจะทำอะไรก็ควรที่จะศึกษาความเป็นไปได้ ก่อนที่จะทำเสมอ ...
เลยไปแอบอ่านเจอ บทความ เกี่ยวกับ Swing ขึ้นมา


 http://www.jroller.com/phidias/entry/is_swing_dead

เค้าก็เขียนได้ดีอะนะ ๕๕
โดยสรุปก็คือ ... ถ้า technology มันยังพอไปต่อได้ 
ถ้าเสีย effort ในการ renovate อย่างน้อย ก็ยังใช้น้อยกว่า renew อยู่ดี ...