By: Blltz 
on 7 June 2012 - 18:26
Tags:
Topics:
ความยากลำบากในการพัฒนาแอพลงบนแอนดรอยด์เป็นเรื่องที่ทุกคนทราบกันดี เนื่องด้วยปัญหา fragmentation จากทั้งฮาร์ดแวร์ และซอฟต์แวร์ และมีข่าวจากนักพัฒนา บริษัทวิจัย ฯลฯ ออกมายืนยันเรื่องนี้อยู่เป็นระยะๆ
คราวนี้ลองมาฟังความเห็นจาก Max Weiner หัวหน้าฝ่ายทำแอพแอนดรอยด์ของ Pocket (ก่อนหน้านี้ชื่อ Read It Later) ที่เขียนบล็อกเบื้องหลังการทำแอพบนแอนดรอยด์ว่าไม่ได้ลำบากมากนัก และจริงๆ มันค่อนข้างจะน่าสนุกด้วยซ้ำ
Weiner เล่าเบื้องหลังการทำแอพไปตั้งแต่ช่วงเริ่มต้น เมื่อปี 2010 ตอนนั้นมีแอนดรอยด์อยู่ทั้งหมด 4 รุ่น (Cupcake, Donut, Eclair และ Froyo) ซึ่ง Eclair กินตลาดอยู่มากถึง 50% เขาจึงตัดสินใจซื้อมือถือรุ่น Samsung Fascinate (Galaxy S ของ Verizon) มาเพื่อใช้ทดสอบแอพ เพราะว่าอีมูเลเตอร์ของแอนดรอยด์ในตอนนั้นมันช้าจนแทบไร้ค่า ผ่านไปไม่กี่เดือนแอพตัวแรกจึงเสร็จออกมา โดยที่มีเครื่องทดสอบเพียงสองเครื่องเท่านั้น (ของ Weiner กับ Nate (พี่ชาย))
ก่อนจะเปิดตัวแอพจริงนั้น Weiner ตัดสินใจเปิดให้ทดลองแอพแบบจำกัดประมาณ 50 คน และหลังจากเปิดขายในเดือนมีนาคม 2011 แอพดังกล่าวก็ขึ้นไปเป็นอันดับหนึ่งของหมวดแอพเสียเงิน ด้วยเรทติ้งที่ 4.7/5 โดยรองรับการใช้งานอุปกรณ์ในขณะนั้นกว่า 90% แม้ว่าจะมีเครื่องทดสอบเพียงสองเครื่องเท่านั้น
ช่วงท้ายของบทความ Weiner พูดถึงระบบสนับสนุนนักพัฒนาของกูเกิลที่ดีขึ้นตามการเติบโตของแอนดรอยด์ ทั้งแนวทางการออกแบบ และอีมูเลเตอร์ที่ดีขึ้นมาก รวมถึงฟีเจอร์ของแอนดรอยด์นั้นเอื้อต่อการพัฒนาแอพให้มีความหลากหลายในการใช้งาน หลักๆ คือ ระบบพุช การทำงานเบื้องหลัง ระบบแชร์ และวิตเจ็ด
แผนต่อไปของ Pocket คือเพิ่มเครื่องทดสอบอีก จากปัจจุบันมีอยู่ 13 เครื่องเท่านั้น
ที่มา - Pocket
Get latest news from Blognone
Follow @twitterapi
Comments
ตกลง android มันดีหรือคนเขียนมันเทพ
I need healing.
อย่างหลัง
ยิ่งลำบากยิ่งมันส์สินะ
ผมว่าคนเขียนเทพมากกว่า
Coder | Designer | Thinker | Blogger
คำพูดที่ใช้กันในทีมคงเป็น
แน่จริงก็เขียนให้ใช้ได้ทุกเครื่องสิ
ท้ากันไปมา ทำงานก็เลยมัน
อาจจะเพราะว่า Pocket วางเลย์เอาท์ของ Content แบบ Responsive อยู่แล้วเลยไม่ค่อยเจอปัญหาเรื่องความแตกต่างของหน้าจอมั้ง
มีแต่แอปพวก Game เท่านั้นแหละที่ซวยเพราะต้องเจอปัยหาเรื่องความแตกต่างระหว่าง HW เยอะที่สุด ข้อแนะนำคือ ซื้อ UE3 ซะ !
ปล. ฮาตรงนี้
ตอนผมอ่านจบก็ฮาเหมือนกัน
พูดถึงเรื่องขนาดหน้าจอ (ซึ่งเป็นเรื่องหลักเรื่องนึง ที่มีคนบ่นถึงมาก) ในกรณีของ iOS ซึ่งปัจจุบันมีความละเอียดสองกลุ่ม (iPhone กับ iPad) โดยแต่ละกลุ่มมีความละเอียดสองชุด (ชุดเล็ก และชุดใหญ่ที่ใหญ่กว่าชุดเล็กสองเท่าทั้งกว้างและยาว) App ที่ทำมาคงจะต้องออกแบบหน้าจอโดยเป็นสองกลุ่ม (ผมเลิกอ่าน iOS SDK ไปเมื่อนานมากแล้วไม่รู้ตอนนี้เป็นไง 555)
ในอนาคตถ้าเกิดอยู่ดี ๆ Apple อยากเปิด AppStore บน AppleTV ด้วย ... ผมว่าก็น่าสนุกนะเพราะว่าทีวีตอนนี้มีหลายความละเอียดเหมือนกัน (มาตรฐานหน่อยก็ 720p, 1080p ที่ไม่ค่อยก็พวก 1366*768 แค่นี้ก็สามชุดละนะ) ซึ่งเป็นสิ่งที่ Apple ควบคุมไม่ได้ซะด้วย ถ้า iOS ไม่รองรับการออกแบบหน้าจอแบบไม่ขึ้นอยู่กับขนาดจอแล้วก็คงเป็นเรื่องลำบาก
คิดว่านี่เป็นเหตุผลหนึ่งที่ Apple อยากจะทำ iTV ล่ะมั้ง เพื่อที่จะได้สามารถควบคุมความละเอียดของหน้าจอได้ แล้วจะได้เปิด AppStore บนทีวีได้ซะที 555
ทีวี LG ผม 1360x768 ครับ ผมสงสัยว่าทำไมไม่ทำให้ 720p พอดีก็ไม่รู้ แต่ ratio หน้าจอใกล้ๆ กับจำนวนพิกเซลหน้าจอใกล้ๆ กันไม่ค่อยหน้ามีผลต่อการออกแบบเท่าไรนะ แค่ขยายนิดหน่อย คงไม่เสียหายอะไรมากละมั้ง
ผมเคยใช้ cocos2d ทำเกม เรื่องความละเอียด 2 ชุด มันจัดการให้เราเลยครับ อย่างมากก็เพิ่มรูป 2X อีกชุดนึง ส่วน 2 กลุ่ม ก็ต้องเขียนเงื่อนไขสำหรับแต่ละกลุ่มตามปกติ หรือถ้าขี้เกียจก็เลือกเป็น for iPhone only ก็ได้ รันบน iPad ได้ด้วย(แต่ภาพก็แตกไปตามระเบียบ 555) คิดว่า tool ตัวอื่นๆมันก็ช่วยจัดการเรื่องความละเอียด 2 ชุดแบบนี้ด้วยเหมือนกัน fragment ฝั่ง IOS ก็เลยไม่ใช่ปัญหาเท่าไรมังครับ
จริงๆคือ นอกจากเกมแล้วจะถ้าคิดจะทำลง iPad ด้วย ส่วนใหญ่มักจะออกแบบ UI กันใหม่หมดเลย มันก็เลยเหมือนกับทำ app ใหม่มากกว่า
ผมว่า ios ปัญหาเยอะกว่านะ ยุ่งยากไม่รู้จะอาร์ทไปไหน แต่ไม่มีปัญหาเรื่องขนาดหน้าจอ ค่อยดีหน่อบ =_=
อีกเรื่องของ Android คือการเตรียมข้อมูลซึ่งน่าเบื่อและใช้เวลาเยอะมาก เพราะมันไม่มี ORM เป็นของตัวเอง โค้ดที่ต้องเขียนมีเยอะเนื่องจากต้องทำ wrapper ก่อนเพื่อความสะดวกในการใช้งาน นอกจากนั้นยังจำเป็นต้องลงไปซัด SQL ตรงๆ สำหรับในส่วนการสร้างตารางอีกด้วย
จะใช้ ORMLite หรือ GreenDAO ก็จะต้องใช้ท่ายากตอนเอาไปบวกกับ ContentProvider อีก เลยจำเป็นต้องใช้ท่ามาตรฐานต่อไป
นอกจากนั้นการเอาฐานข้อมูลไป bind กับ ListView ถ้าจะไม่ให้มัน block UI thread ตอน refresh ข้อมูล ก็จำเป็นต้องใช้ Loader ซึ่งมันเป็น API 11 ดังนั้นถ้าจะให้รองรับรุ่นเก่าๆ ก็ต้องใช้ compatibility library ปัญหาก็ตามมาอีกคือมันไม่มี Unit Test สำหรับ compatibility library (หากจะทำจริงๆ ก็ต้อง mock การทำงานของ Loader เอง)
สิ่งที่แย่อีกอย่างหนึ่ง คือการทำ migration เพราะ Android ไม่มีอะไรช่วยเลย ต้องทำมือเองทั้งหมด
ถ้ามีการเปลี่ยนแปลง 2 ครั้ง เช่น 1->2->3 ก็ต้องมีโค้ด อยู่ 3 ชุด สำหรับ 1->2, 2->3 และ 1->3
ส่วน iOS การเตรียมและการใช้งานฐานข้อมูลดีกว่ามากๆ โดยเฉพาะ iOS 5 ที่ใช้ UIManagedDocument แทนแบบเก่า (หากลืมเรื่อง bug สำหรับการสร้าง NSManagedObject Subclass ที่ Apple ไม่ยอมแก้ซักที)