ข้อจำกัดใน iOS ที่มีผลต่อ UX ของ Notification

ผมใช้มือถือ Android มาโดยตลอด แต่ตอนตัดสินใจซื้อ tablet ได้ไปลองเล่น iPad 2 กับ Galaxy Tab 10 เทียบกันดู ปรากฏว่าความลื่นไหลของ iPad 2 นี่มันสุดยอดจริงๆ (ณ เวลานั้นน่ะนะ ตอนนี้เปลี่ยนมาใช้ Nexus 7 ละ :P)

ระหว่างใช้ iPad ก็นึกสงสัย ว่าทำไมแอพดังๆ หลายตัวมันถึงมี User Experience (UX) แบบนี้เนี่ย ถ้าปรับปรุงอีกหน่อย ผู้ใช้จะสะดวกขึ้นอีกเยอะเลย

วันนึงผมมีโอกาสได้เขียนโปรแกรมบน iOS แล้วได้พบกับข้อจำกัดหลายๆ อย่างของ Apple Push Notification (APN) ซึ่งมีทั้งข้อดี/ข้อเสีย และก่อให้เกิดข้อจำกัดกับ UX ของแอพใน iOS เอง

วันนี้เลยอยากแชร์ข้อจำกัดนั้น (“ทำไมแอพมัน…ฟระ”), ข้อดีข้อเสียของ APN, และท่า Compromise เทพๆของแอพ Facebook เพื่อปรับปรุง UX ครับ

คำถาม

1. เวลา Twitter เตือนว่ามี Direct Message ใหม่
   ทำไมเรากดเข้าไปแล้วไม่เจอข้อความทันที?
   ทำไมต้องรอโหลด message อีกรอบ รอให้โหลด message เสร็จแล้วค่อยเตือนไม่ได้เหรอ? จะได้กดเข้าไปเจอ message ทันทีไม่ต้องรอ
2. เวลา LINE เตือนว่ามีข้อความใหม่ ทำไมบางทีกดเข้าไปแล้วไม่เจอข้อความ?

ตอนแรกผมก็โทษโปรแกรมเมอร์ครับ… ทำไมแกไม่ออกแบบแอพให้ดีกว่าเน้!
พอได้เขียนโปรแกรมกับ APN แล้วเริ่มเข้าใจหัวอกคนทำแอพมากขึ้น

ใครรู้จักระบบ APN ดีอยู่แล้ว ข้ามไปอ่าน คำตอบได้เลยครับ

Apple Push notification ทำงานยังไง

ระบบปฏิบัติการ iOS ที่ใช้ใน iPhone และ iPad นั้นมีข้อจำกัดสำคัญอย่างนึง คือ ไม่ยอมให้แอพทั่วไปทำงานใน background ครับ แอพทั่วๆ ไป เช่น เกมส์, social network, หรือ email client ไม่สามารถรันอยู่ในเบื้องหลังเพื่อติดต่อกับ server และคอยแจ้งเตือนผู้ใช้ได้

ด้วยข้อจำกัดนี้เอง Apple จึงพัฒนาระบบ Push Notification ขึ้นมา โดยระบบปฏิบัติการจะเปิดท่อ TCP ไปหาเซิร์ฟเวอร์ของ Apple ทิ้งไว้เพื่อรับ push notification ให้อัตโนมัติครับ

โปรแกรมเมอร์เลยต้องพัฒนาโปรแกรมฝั่งเซิร์ฟเวอร์ (3rd Party App Server) เพื่อส่ง notification ไปหา APN Server ของ Apple, แล้ว Apple จะส่ง notification ไปหา device ให้

ข้อดีของระบบ APN

• ประหยัดแบตเตอรี่ เพราะไม่ต้องมี background app เยอะๆ
• ประหยัด bandwidth เพราะไม่มีแอพรันอยู่ใน background มาคอยเปิดท่อคุยกับ server หรือ poll เอง หลายๆ แอพพร้อมกัน
• แอพที่รันเป็น foreground สามารถใช้งานทรัพยากรได้เต็มที่ (ทั้ง CPU Time, Memory, และ Network) ต่างกับ Android ที่ยอมให้มี background app

บางครั้งผมยังรู้สึกเลยด้วยซ้ำว่าเวลาใช้มือถือ Android กับเน็ต EDGE ช้าๆ แล้วมี background app คอย sync นู่น sync นี่ตลอดเวลา น่าจะทำให้แอพบราวเซอร์ที่ผมใช้อยู่โหลดเว็บช้าลง (เพราะมีแอพที่มาแย่งใช้เน็ตพร้อมกันเยอะเหลือเกิน)

ข้อจำกัด

APN มีข้อจำกัดสำคัญ คือ Notification 1 อันต้องมีความยาวไม่เกิน 256 ไบต์ (Notification Payload)
ฟังดูตอนแรก 256 ไบต์นี้ก็ดูไม่น่าจะมีปัญหาอะไร Push Notification น่าจะทำงานได้เร็วด้วย เพราะไม่มี latency ที่เกิดจาก notification ใหญ่ๆ บางอันขวาง notification อื่นๆ ที่กำลังตามมา

ต.ต.. แต่… ปัญหาคือ APN กำหนดให้ใช้ JSON เป็น format ของข้อมูล notification ครับ

{
  "aps": { "alert": "Message to be displayed in notification center goes here" },
  "extra_info": [ "goes",  "here" ]
}

สำหรับภาษาอังกฤษก็คงไม่เป็นไรส่งได้หลายตัวอักษรอยู่… แต่ลองนึกถึงข้อความภาษาไทยสิครับ 70 ตัวอักษร เข้ารหัสเป็น UTF-8 ก็ใช้ไป 205 ไบต์แล้ว ดังนั้นไม่ต้องแปลกใจที่ข้อความภาษาไทยมักจะโดนตัดให้สั้นลง+มีจุดจุดจุดต่อท้ายตลอด เช่น

“ไปประตูน้ำมา เราเลิกกินข้าวขาหมูแล้วนะจ๊ะ” กลายเป็น “ไปประตูน้ำมา เราเลิก…” ก็อาจทำให้คู่รักทะเลาะกันได้

เมื่อ notification push ไปถึงผู้ใช้แล้ว ถ้าผู้ใช้กด notification ระบบปฏิบัติการก็จะเปิดแอพขึ้นมา และส่งต่อ payload ให้แอพเอาไปใช้ครับ

คำตอบ

ผมก็ได้เล่านู่น เล่านี้เกี่ยวกับ APN มาพอสมควรแล้ว ตอนนี้มาฟังคำตอบกันว่าทำไม Twitter กับ LINE ถึงไม่ทำอย่างนั้นทำอย่างนี้:

Q: ทำไมแอพ Twitter ถึงเตือนว่ามี direct message แต่พอกดเข้าไปยังต้องรอโหลด message อีกรอบ?
A: แอพ Twitter มันรู้ช้ากว่าผู้ใช้อีกครับ ว่ามี direct message ใหม่เข้ามา

ตาม Flow ของ APN:

1. แอพ Twitter หลับอยู่ในเบื้องหลัง
2. มี push notification ใหม่เข้ามา ผู้ใช้อยากอ่านข้อความเต็มๆ ก็กด notification นั้น
3. แอพ Twitter โดนปลุกให้ตื่นและรู้ว่ามี direct message มาใหม่
4. ผู้ใช้นั่งรอ direct message โหลดเสร็จ (และบ่นว่าทำไมต้องรอ แบบผม)

ใครอยากเห็นปัญหานี้ชัดๆ ให้ลองปิด Wifi ก่อนจะกด notification ดูครับ

Q: ทำไม LINE มี notification เข้ามา แต่พอกดเข้าไปถึงไม่เจอข้อความ
A: แอพ LINE ในเครื่องได้รับข้อความที่อาจยังไม่ครบจาก APN server (2)
มันเลยต้องติดต่อเซิร์ฟเวอร์ LINE อีกครั้งเพื่อโหลดข้อความฉบับเต็ม (3)

ทีนี้ถ้าแอพมันโหลดไม่ได้ ก็จะเกิดปัญหาอย่างที่เราเจอกันครับ มี notification มา แต่กดเข้าไปแล้วหาข้อความไม่เจอ

ท่า Compromise ของ Facebook Chat

มีแอพ Facebook บน iOS นี่หละที่ผมว่าเลี่ยงปัญหานี้ได้เท่ดี

Facebook บน iOS

(1) มันเอา payload ของข้อความที่ยังไม่ครบมาโชว์ก่อน
(2) พอโหลดข้อความเต็มเสร็จค่อยเอามาแสดงผลอีกรอบครับ

Edit: ใน iOS 7 มีการปรับปรุงเรื่องนี้แล้วครับ

ใน iOS 7 มีการปรับปรุงเกี่ยวกับ Multitasking เพิ่มเติม 2 ข้อ คือ

1. แอพสามารถระบุขอ fetch ข้อมูลเบื้องหลังได้ (ถึงแม้ว่าจะไม่ได้ถูกรันโดยผู้ใช้) โดยสามารถกำหนด interval ของการ fetch ข้อมูลได้
2. แอพสามารถ fetch ข้อมูลในเบื้องหลังเมื่อมี Push notification ได้ครับ

หวังว่าเมื่อผู้ใช้อัพเดทเป็น iOS7 และนักพัฒนาได้ใช้ API ใหม่แล้ว น่าจะช่วยปรับปรุงประสบการณ์การใช้งานให้ดีขึ้นได้ (แต่แบตก็น่าจะหมดเร็วขึ้นเมื่อมีแอพแบบนี้เยอะขึ้นๆ)