การถกเถียงเรื่องแอปบนอุปกรณ์เคลื่อนที่
บทนำ
แอปบนอุปกรณ์เคลื่อนที่และ HTML5 เป็นเทคโนโลยีที่ได้รับความนิยมมากที่สุด 2 รายการในขณะนี้ และมีส่วนที่ทับซ้อนกันอยู่มาก เว็บแอปทำงานในเบราว์เซอร์บนมือถือ และยังสามารถจัดแพ็กเกจใหม่เป็นแอปที่มาพร้อมเครื่องในแพลตฟอร์มบนมือถือต่างๆ ได้ด้วย ด้วยแพลตฟอร์มที่หลากหลายที่ต้องรองรับ ประกอบกับประสิทธิภาพที่สูงมากของเบราว์เซอร์บนอุปกรณ์เคลื่อนที่ นักพัฒนาซอฟต์แวร์จึงหันมาใช้ HTML5 เป็นโซลูชัน "เขียนครั้งเดียว รันได้หลายแพลตฟอร์ม" แต่แนวทางนี้ใช้ได้จริงไหม ยังมีเหตุผลที่น่าสนใจอีกมากมายในการใช้แอปที่มาพร้อมเครื่อง และเห็นได้ชัดว่านักพัฒนาแอปจำนวนมากเลือกใช้แนวทางนั้น บทความนี้เป็นการถกเถียงกันระหว่างแอปที่มากับเครื่องกับเว็บ
ความหลากหลายของฟีเจอร์
ประเด็น: โฆษณาเนทีฟทำอะไรได้มากกว่า
เราสามารถแบ่งฟังก์ชันการทำงานบนอุปกรณ์เคลื่อนที่ออกเป็น 2 มิติ ได้แก่ ประสบการณ์การใช้งานแอป และวิธีที่แอปเชื่อมต่อกับระบบนิเวศของอุปกรณ์ เช่น สำหรับ Android จะเป็นฟีเจอร์ต่างๆ เช่น วิดเจ็ตและการแจ้งเตือน โฆษณาเนทีฟมีความโดดเด่นในทั้ง 2 ด้าน
ในแง่ของประสบการณ์การใช้งานแอป แอปที่มาพร้อมเครื่องสามารถทำสิ่งต่างๆ ได้มากกว่า โดยสามารถรับเหตุการณ์การปัด เหตุการณ์การแตะหลายจุดพร้อมกันได้อย่างง่ายดายสำหรับแพลตฟอร์มที่รองรับ โดยปกติแล้ว แป้นพิมพ์เสมือนจะทำงานเมื่อมีการกดแป้นจริง เช่น ปุ่มค้นหาและตัวควบคุมระดับเสียงของ Android นอกจากนี้ยังเข้าถึงฮาร์ดแวร์ได้ด้วย เช่น GPS และกล้อง และเมื่อได้รับอนุญาตจากผู้ใช้ บางแพลตฟอร์มจะให้สิทธิ์เข้าถึงระบบปฏิบัติการโดยไม่มีข้อจำกัด ลองตรวจดูว่าแบตเตอรี่เหลืออยู่เท่าใดด้วย HTML5
แต่ก็มีมากกว่าประสบการณ์การใช้งานแอป ระบบปฏิบัติการอย่าง Android มีวิธีต่างๆ ให้แอปโต้ตอบกับผู้ใช้และแอปอื่นๆ คุณมีวิดเจ็ตที่ใช้งานอยู่ในหน้าแรก คุณมีการแจ้งเตือน ซึ่งจะปรากฏในแถบสถานะของอุปกรณ์ และคุณมี Intent ซึ่งช่วยให้แอปประกาศตัวเองว่าให้บริการทั่วไปที่แอปอื่นๆ อาจต้องใช้เป็นครั้งคราว
ข้อโต้แย้ง: ฟีเจอร์ที่มาพร้อมเครื่องสามารถเพิ่มประสิทธิภาพได้ และเว็บก็กำลังตามทันอยู่แล้ว
เป็นความจริงที่ฟีเจอร์ในแอปจำนวนมากนั้นเกินขอบเขตของแอป HTML5 ไม่ว่าทักษะการเขียนเว็บของคุณจะยอดเยี่ยมเพียงใด หากแอปของคุณติดอยู่ในแซนด์บ็อกซ์ที่ไม่มี API กล้อง แอปนั้นก็จะไม่สามารถถ่ายภาพได้ในเร็วๆ นี้ โชคดีที่คุณไม่จำเป็นต้องอยู่ในแซนด์บ็อกซ์นั้น หากต้องการให้เว็บแอปถ่ายรูปจริงๆ คุณสามารถสร้างแอปที่มาพร้อมเครื่องซึ่งมี WebView แบบฝังที่แสดงอินเทอร์เฟซผู้ใช้ส่วนใหญ่ได้ เฟรมเวิร์ก PhoneGap แบบโอเพนซอร์สทำงานโดยเติมเต็มช่องว่างด้วยการแสดงฟีเจอร์แบบเนทีฟเป็นบริการบนเว็บ ซึ่งมุมมองเว็บจะเรียกใช้โดยใช้ API เครือข่ายมาตรฐาน เมื่อสร้างแอปแบบไฮบริดเช่นนี้ คุณยังสามารถเชื่อมต่อกับฟีเจอร์ของแพลตฟอร์มเหล่านั้นได้ด้วย เช่น วิดเจ็ต การแจ้งเตือน และ Intent
การสร้างแอปแบบผสม (เนทีฟและเว็บ) ไม่ใช่โซลูชันที่เหมาะสมที่สุด ซึ่งจะเพิ่มความซับซ้อนและใช้ได้กับเว็บแอปที่รวมเป็นแอปที่มาพร้อมเครื่องเท่านั้น ไม่ใช่เว็บไซต์แบบเดิมที่เข้าถึงจากเบราว์เซอร์บนมือถือ แต่ก็อาจไม่จำเป็นต้องใช้ไปอีกนาน มาตรฐานของเว็บมีการพัฒนาอย่างรวดเร็ว และเบราว์เซอร์บนมือถือที่ทันสมัยก็พัฒนาตามทัน ตัวอย่างเช่น พื้นที่เก็บข้อมูลออฟไลน์ ตำแหน่งทางภูมิศาสตร์ กราฟิก Canvas และการเล่นวิดีโอ/เสียงล้วนได้รับการสนับสนุนอย่างกว้างขวางในสมาร์ทโฟนสมัยใหม่ แม้แต่กล้องก็เริ่มได้รับการรองรับแล้ว โดยตั้งแต่ Android 3.1 เป็นต้นมา คุณสามารถถ่ายภาพและวิดีโอโดยใช้มาตรฐานเว็บได้ และเบราว์เซอร์ iOS เวอร์ชันล่าสุดรองรับ WebSocket สำหรับการสตรีมแบบ 2 ทาง รวมถึงการตรวจจับการวางแนวอุปกรณ์
โดยรวมแล้ว อุปกรณ์เคลื่อนที่มีการพัฒนาอย่างต่อเนื่อง แต่เว็บก็มีการพัฒนาอย่างรวดเร็วเช่นกัน เฉพาะเบราว์เซอร์ในเดสก์ท็อปเพียงอย่างเดียวก็มีผู้ให้บริการเบราว์เซอร์รายใหญ่ 5 รายที่พัฒนามาตรฐานและเพิ่มฟีเจอร์ต่างๆ อย่างรวดเร็ว แม้ว่าการพอร์ตฟีเจอร์เหล่านี้ไปยังอุปกรณ์เคลื่อนที่จะไม่ใช่กระบวนการที่ง่าย แต่ฟีเจอร์หลายอย่างก็มีให้บริการในเบราว์เซอร์บนมือถือแล้ว
แอปที่มากับเครื่องมีการเปลี่ยนแปลงอย่างรวดเร็ว แต่เว็บก็กำลังลดช่องว่างนั้นลง
ประสิทธิภาพ
ประเด็น: แอปที่มาพร้อมเครื่องทำงานได้เร็วกว่า
แอปที่มาพร้อมเครื่องไม่มีอุปสรรคด้านรันไทม์ของเว็บที่ต้องจัดการ โดยจะทำงานใกล้กับฮาร์ดแวร์และใช้ประโยชน์จากตัวเพิ่มประสิทธิภาพ เช่น การเร่ง GPU และมัลติเธรดได้
ข้อโต้แย้ง: ปัจจุบันรันไทม์ของเว็บทำงานได้เร็วขึ้นมาก และแอปส่วนใหญ่ก็ไม่จำเป็นต้องใช้ความเร็วอยู่แล้ว
การบอกว่าเว็บเร็วขึ้นในช่วงไม่กี่ปีที่ผ่านมาอาจเป็นการพูดที่น้อยเกินไป V8 ซึ่งเป็นเครื่องมือ JavaScript ที่มาพร้อมกับ Chrome เป็นการพัฒนาที่สำคัญในด้านประสิทธิภาพของเว็บเมื่อเปิดตัว และตั้งแต่นั้นมาก็มีแต่จะเร็วขึ้นเรื่อยๆ
เครื่องมือแสดงผลกราฟิกยังช่วยให้เว็บทำงานเร็วขึ้นด้วย และตอนนี้การเร่งฮาร์ดแวร์ก็เริ่มเกิดขึ้นแล้ว ลองดูความเร็วที่เพิ่มขึ้นจาก Canvas ที่เร่งด้วยฮาร์ดแวร์
นอกจากนี้ Web Workers API ใหม่ยังช่วยให้สามารถทำมัลติเธรดได้ และนักพัฒนาเว็บสมัยใหม่ยังสามารถเรียกใช้ไลบรารีที่เพิ่มประสิทธิภาพได้หลากหลาย รวมถึงเทคนิคการเพิ่มประสิทธิภาพที่ได้รับการวิจัยมาอย่างดี แม้ว่าเครื่องมือส่วนใหญ่จะเริ่มต้นใช้งานบนเว็บบนเดสก์ท็อป แต่ก็ยังคงเกี่ยวข้องกับอุปกรณ์เคลื่อนที่ และมีการให้ความสำคัญกับอุปกรณ์เคลื่อนที่มากขึ้น เช่น Steve Souders ผู้เชี่ยวชาญด้านประสิทธิภาพมีหน้าที่จัดทำขึ้นสำหรับเครื่องมือวัดประสิทธิภาพบนอุปกรณ์เคลื่อนที่โดยเฉพาะ
ความก้าวหน้าของเดสก์ท็อปบางอย่างยังไม่ปรากฏในแพลตฟอร์มอุปกรณ์เคลื่อนที่ทุกแพลตฟอร์ม แต่แนวโน้มก็บ่งชี้ว่ากำลังจะเกิดขึ้น นอกจากนี้ สิ่งสำคัญที่ควรทราบคือแอปบนอุปกรณ์เคลื่อนที่ส่วนใหญ่ไม่ใช่เกม 3 มิติที่ล้ำสมัย แต่เป็นแอปที่เน้นข้อมูลเป็นหลัก เช่น ข่าวสาร อีเมล ตารางเวลา โซเชียลเน็ตเวิร์ก ฯลฯ ลองเข้าชมเว็บไซต์บางแห่งจากอุปกรณ์เคลื่อนที่ เช่น GMail, Amazon, Twitter แล้วคุณจะเห็นว่าประสิทธิภาพของเว็บบนอุปกรณ์เคลื่อนที่นั้นเพียงพอแล้ว สำหรับเกม เกมพื้นฐานสามารถเล่นได้แล้วด้วย Canvas 2 มิติ และ WebGL เริ่มปรากฏบนอุปกรณ์เคลื่อนที่แล้ว เช่น Firefox 4 จนกว่าจะมีการใช้งานอย่างแพร่หลาย เฟรมเวิร์กที่คอมไพล์แอป WebGL เป็นแอปที่มาพร้อมเครื่องซึ่งใช้ประโยชน์จาก OpenGL ได้ก็มีจำนวนเพิ่มขึ้นเรื่อยๆ เช่น ImpactJS
ประสบการณ์ของนักพัฒนาแอป
ประเด็น: แอปที่มาพร้อมเครื่องพัฒนาได้ง่ายกว่า
แอปที่มาพร้อมเครื่องใช้ภาษาโปรแกรมที่มีประสิทธิภาพ (เช่น Java, Objective C, C++) ซึ่งออกแบบมาเพื่อการพัฒนาแอปพลิเคชันที่ซับซ้อนและมีประวัติการใช้งานที่ได้รับการพิสูจน์แล้ว API ได้รับการออกแบบตั้งแต่ต้นเพื่อรองรับแพลตฟอร์มที่มีอยู่ คุณสามารถแก้ไขข้อบกพร่องของแอปได้อย่างง่ายดายในโปรแกรมจำลองเดสก์ท็อปซึ่งแสดงภาพที่ใกล้เคียงกับอุปกรณ์เป้าหมาย
สิ่งที่ทำให้การพัฒนาเว็บเป็นเรื่องที่ยุ่งยากเป็นพิเศษคือความหลากหลายของเบราว์เซอร์และรันไทม์ เมื่อแอปทำงาน จะไม่มีการรับประกันว่าฟีเจอร์ X จะพร้อมใช้งาน และถึงแม้จะทำได้ เบราว์เซอร์จะนำไปใช้ได้อย่างไร มาตรฐานต่างๆ อาจมีการตีความที่แตกต่างกันไป
ข้อโต้แย้ง: เว็บมักจะพัฒนาได้ง่ายกว่า โดยเฉพาะอย่างยิ่งหากกำหนดเป้าหมายเป็นอุปกรณ์หลายเครื่อง
มาเริ่มที่เทคโนโลยีหลักกันก่อน เป็นความจริงที่ว่ามาตรฐานเว็บได้รับการคิดค้นขึ้นในยุคที่เว็บเป็นเรื่องเกี่ยวกับเอกสารเป็นหลัก ไม่ใช่แอป โดยมีการสร้างและติดตั้งใช้งาน JavaScript ในเวลาเพียง 10 วัน แต่กลับกลายเป็นว่ามีประสิทธิภาพมากกว่าที่คิดไว้มาก นักพัฒนาเว็บได้เรียนรู้ที่จะใช้ประโยชน์จากส่วนที่ดีและควบคุมส่วนที่ไม่ดี โดยตอนนี้มีรูปแบบที่เข้าใจได้สำหรับการออกแบบที่ปรับขนาดได้ นอกจากนี้ มาตรฐานต่างๆ ยังไม่หยุดนิ่ง และความพยายามอย่าง HTML5, CSS3 และ EcmaScript Harmony ล้วนช่วยปรับปรุงประสบการณ์ของนักพัฒนาซอฟต์แวร์ การที่คุณจะเลือกใช้ C++, Java หรือ JavaScript นั้นเป็นเรื่องที่ถกเถียงกันอย่างมาก และยังขึ้นอยู่กับฐานของโค้ดเดิมด้วย แต่เราสามารถรวม JavaScript เป็นคู่แข่งที่สำคัญในปัจจุบันได้อย่างแน่นอน
ข้อดีของการกระจาย Fragment ของเบราว์เซอร์/รันไทม์คือสภาพแวดล้อมทั้งหมดเหล่านี้มีอยู่ตั้งแต่แรก พัฒนาแอป Android ใน Java และคุณจะต้องเผชิญกับการพอร์ตไปยัง Objective C อย่างเต็มรูปแบบเพื่อรองรับ iOS พัฒนาเว็บแอปเพียงครั้งเดียวและแอปจะทำงานได้ทั้งใน Android และ iOS รวมถึง WebOS, BlackBerry, Windows Mobile และ… นั่นเป็นเพียงทฤษฎีเท่านั้น ในทางปฏิบัติ คุณจะต้องปรับแต่งสิ่งต่างๆ สำหรับแต่ละแพลตฟอร์มหากต้องการให้ผู้ใช้ได้รับประสบการณ์ที่เหมาะสมจริงๆ แต่คุณก็ต้องทำแบบนั้นในแอปที่มากับเครื่องด้วยสำหรับระบบปฏิบัติการบนมือถือส่วนใหญ่ เนื่องจากมีเวอร์ชันและอุปกรณ์ที่แตกต่างกัน
ข่าวดีก็คือ "การกระจาย Fragment" เป็นแบบนี้มาโดยตลอดบนเว็บ และมีเทคนิคที่รู้จักกันดีในการจัดการกับปัญหานี้ ที่สำคัญที่สุดคือ หลักการของการเพิ่มประสิทธิภาพแบบต่อเนื่องจะกระตุ้นให้นักพัฒนาซอฟต์แวร์กำหนดเป้าหมายอุปกรณ์พื้นฐานก่อน แล้วจึงเพิ่มชั้นของความยอดเยี่ยมเฉพาะแพลตฟอร์มเมื่อพร้อมใช้งาน หลักการของการตรวจหาฟีเจอร์ก็ช่วยได้เช่นกัน และในปัจจุบันเรามีการรองรับไลบรารีจาก Modernizr เพื่อรองรับการออกแบบเว็บที่ปรับเปลี่ยนตามอุปกรณ์ การใช้เทคนิคเหล่านี้อย่างรอบคอบจะช่วยให้คุณขยายการเข้าถึงไปยังอุปกรณ์ส่วนใหญ่ได้ แม้กระทั่ง "ฟีเจอร์โฟน" รุ่นเก่า หรือแม้แต่รูปแบบต่างๆ เช่น นาฬิกาและทีวี ไม่ว่าจะผลิตจากแบรนด์ใดและใช้ระบบปฏิบัติการใดก็ตาม ดูการสาธิต UI แบบหลายหน้าจอที่ Google IO 2011 ซึ่งเรากำหนดเป้าหมายรูปแบบของอุปกรณ์ที่แตกต่างกัน (ฟีเจอร์โฟน สมาร์ทโฟน แท็บเล็ต เดสก์ท็อป ทีวี) ด้วยฐานของโค้ดทั่วไปของตรรกะและมาร์กอัป
รูปลักษณ์
ประเด็น: โฆษณาเนทีฟเข้ากับรูปลักษณ์ของแพลตฟอร์ม
หนึ่งในฟีเจอร์ที่กำหนดลักษณะของแพลตฟอร์มคือรูปลักษณ์และความรู้สึก ผู้ใช้คาดหวังว่าการควบคุมจะแสดงอย่างสอดคล้องกันและจัดการในลักษณะเดียวกัน สำนวนบางอย่างจะแตกต่างกันไปในแต่ละแพลตฟอร์ม เช่น จะเกิดอะไรขึ้นเมื่อผู้ใช้ "กดค้าง" (แตะองค์ประกอบค้างไว้หลายวินาที) แพลตฟอร์มต่างๆ มีสำนวนมาตรฐานสำหรับสิ่งต่างๆ เหล่านี้ และคุณไม่สามารถตอบสนองความต้องการทั้งหมดได้ด้วยแอป HTML5 เพียงแอปเดียว
นอกจากนี้ รูปลักษณ์ของแพลตฟอร์มยังได้รับการจัดการโดยไลบรารีซอฟต์แวร์แบบเนทีฟของแพลตฟอร์ม ซึ่งวิดเจ็ตจะรวมรูปลักษณ์ที่ผู้ใช้คาดหวังไว้ คุณจะได้รับรูปลักษณ์ที่คาดหวังไว้มากมาย "ฟรี" เพียงแค่ใช้ชุดเครื่องมือแบบเนทีฟ
ข้อโต้แย้ง: เว็บมีรูปลักษณ์และความรู้สึกเป็นของตัวเอง และคุณยังปรับแต่งอินเทอร์เฟซเว็บสำหรับแพลตฟอร์มที่คุณสนใจมากที่สุดได้ด้วย
ตามที่อธิบายไว้ในส่วนก่อนหน้า วิธีการพัฒนาเว็บคือการเขียนเวอร์ชัน "ขนาดเดียวเหมาะกับทุกคน" พื้นฐาน แล้วค่อยๆ ปรับปรุงให้ดีขึ้น แม้ว่าการปรับปรุงมักจะอิงตามฟีเจอร์ แต่คุณก็สามารถปรับปรุงได้โดยการกำหนดเป้าหมายไปยังแพลตฟอร์มที่คุณให้ความสำคัญมากที่สุด ซึ่งเป็น "การตรวจหาเบราว์เซอร์" ประเภทหนึ่งที่บางครั้งชุมชนเว็บไม่เห็นด้วย เนื่องจากมีเบราว์เซอร์ที่เป็นไปได้มากมาย แต่หากคุณมองว่าแพลตฟอร์ม 2 หรือ 3 แพลตฟอร์มมีความสำคัญสูงมาก และคุณยินดีที่จะพยายามมากขึ้นเพื่อแข่งขันกับทางเลือกแบบเนทีฟ วิธีนี้อาจเป็นทางเลือกที่เหมาะสม
ในส่วนของเวอร์ชันพื้นฐาน เว็บมีรูปลักษณ์ของตัวเอง และเรายังพูดได้ว่าแพลตฟอร์มอุปกรณ์เคลื่อนที่แต่ละแพลตฟอร์มมี "รูปลักษณ์ของเว็บ" ของตัวเองซึ่งกำหนดโดยเบราว์เซอร์เริ่มต้นและรันไทม์ของเว็บ "รูปลักษณ์ของเว็บ" อาจเหมาะกับผู้ใช้ และช่วยให้คุณสร้างความสอดคล้องกับประสบการณ์การท่องเว็บในเบราว์เซอร์ในเดสก์ท็อปได้มากขึ้น รวมถึงอุปกรณ์อื่นๆ ที่ผู้ใช้อาจใช้งานอยู่ นอกจากนี้ ยังมีแอปที่ประสบความสำเร็จจำนวนมากที่ไม่ได้รองรับรูปลักษณ์และความรู้สึกแบบเนทีฟมากนัก ซึ่งเป็นเรื่องจริงสำหรับเกม (เกมมือถือที่คุณชื่นชอบมีรูปลักษณ์และความรู้สึกเหมือนระบบปฏิบัติการบนมือถือของคุณไหม) และยังเป็นเรื่องจริงสำหรับแอปทั่วไปด้วย เช่น ลองดูไคลเอ็นต์ Twitter แบบเนทีฟที่ได้รับความนิยมมากกว่าในแพลตฟอร์มที่คุณเลือก แล้วคุณจะเห็นกลไกอินเทอร์เฟซผู้ใช้ที่หลากหลายในการทำงาน
การค้นพบได้
ประเด็น: แอปที่มาพร้อมเครื่องค้นพบได้ง่ายกว่า
กลไก App Distribution เช่น Android Market และ App Store ของ Apple ได้รับความนิยมอย่างล้นหลามในช่วงไม่กี่ปีที่ผ่านมา และเป็นแรงขับเคลื่อนสำคัญสำหรับอุตสาหกรรมอุปกรณ์เคลื่อนที่ทั้งหมด นักพัฒนาแอปทุกคนสามารถส่งแอปที่มาพร้อมเครื่องไปยังมาร์เก็ตเพลส ซึ่งผู้ใช้จะค้นพบแอปได้ผ่านการเรียกดู การค้นหา และการรับวิดีโอแนะนำ ไม่เพียงเท่านั้น หากคุณทำงานได้ดี คะแนนและความคิดเห็นที่ยอดเยี่ยมจะช่วยโน้มน้าวให้ผู้ใช้กดปุ่มติดตั้งที่สำคัญที่สุด
ข้อโต้แย้ง: จริงๆ แล้วเว็บแอปค้นพบได้ง่ายกว่า
เว็บอาจเป็นสื่อที่ค้นพบได้ง่ายที่สุดเท่าที่เคยมีมา ใน URL ที่เรียบง่าย เรามี (อย่างน้อยก็ในทางทฤษฎี) ตัวระบุที่ไม่ซ้ำกันสำหรับทุกสิ่งที่เคยเผยแพร่บนเว็บ ซึ่งรวมถึงแอปที่เผยแพร่บนเว็บไซต์มาตรฐานด้วย เครื่องมือค้นหาช่วยให้ค้นพบเนื้อหาดังกล่าวได้ง่าย และเว็บไซต์อื่นๆ สามารถลิงก์ไปยังเนื้อหานั้นได้ รวมถึงแคตตาล็อกของเว็บแอปที่คล้ายกับมาร์เก็ตเพลสบนอุปกรณ์เคลื่อนที่ อันที่จริงแล้ว ทุกคนสามารถแชร์เว็บแอปกับเพื่อนๆ ได้โดยเพียงแค่ลิงก์ไปยังเว็บแอปนั้นในอีเมลและข้อความบนโซเชียลเน็ตเวิร์ก นอกจากนี้ คุณยังส่งลิงก์ใน SMS ได้ด้วย ซึ่งผู้ใช้มือถือจะคลิกลิงก์และเปิดแอปในเบราว์เซอร์ของอุปกรณ์ได้
เรายังไม่มีมาร์เก็ตเพลสแบบเดียวกันที่ผู้ใช้สามารถให้คะแนนและแสดงความคิดเห็นเกี่ยวกับแอปได้ แต่สิ่งนี้ก็กำลังเปลี่ยนแปลงเช่นกัน อ่านต่อ…
การสร้างรายได้
ประเด็น: โฆษณาเนทีฟสามารถสร้างรายได้
"เด็ก 6 ขวบสร้างแอปในช่วงพักกลางวัน ขายได้เป็นล้านๆ ชุดในราคาชุดละ 3 ดอลลาร์" คุณคงเห็นพาดหัวข่าวแบบนี้บ่อยๆ ในช่วงนี้ จึงไม่น่าแปลกใจที่นักพัฒนาแอปทั้งรายใหญ่และรายเล็กต่างมองหาตลาดแอปบนอุปกรณ์เคลื่อนที่เพื่อสร้างรายได้ แพลตฟอร์มอุปกรณ์เคลื่อนที่เสนอช่องทางต่างๆ ให้นักพัฒนาแอปเรียกเก็บเงินจากแอปของตนได้โดยตรง วิธีที่ง่ายที่สุดคือการชำระเงินแบบครั้งเดียวเพื่อปลดล็อกแอปตลอดไป นอกจากนี้ยังมีกลไกระบบชำระเงินในแอปพลิเคชันและการสมัครใช้บริการที่ให้บริการในบางแพลตฟอร์ม ซึ่งผสานรวมอย่างใกล้ชิดในกลไกที่สอดคล้องและปลอดภัย รูปแบบการชำระเงินที่ใหม่กว่าเหล่านี้ช่วยให้นักพัฒนาแอปเปลี่ยนแอปที่ได้รับความนิยมอย่างมากให้เป็นแหล่งรายได้ระยะยาว
นอกจากการชำระเงินในแอปแล้ว คุณยังสร้างรายได้ด้วยโมเดลเว็บแบบดั้งเดิม เช่น การโฆษณาและการสนับสนุน
ข้อโต้แย้ง: การสร้างรายได้บนเว็บเป็นไปได้เสมอ และโอกาสก็เพิ่มขึ้นเรื่อยๆ
เว็บคงจะไม่ใช่กลไกของอุตสาหกรรมสมัยใหม่หากไม่มีโอกาสมากมายในการสร้างรายได้ แม้ว่ากลไก "จ่ายตามการใช้งาน" โดยตรงจะยังไม่แพร่หลาย แต่ก็มีกลุ่มเฉพาะต่างๆ ที่โซลูชัน "ซอฟต์แวร์เป็นบริการ" แบบสมัครใช้บริการกลายเป็นโซลูชันที่ใช้งานได้จริง ตัวอย่างเช่น แอป Google, ผลิตภัณฑ์ต่างๆ ของ 37Signals และบริการอีเมลเวอร์ชันพรีเมียมต่างๆ นอกจากนี้ การชำระเงินโดยตรงยังไม่ใช่วิธีเดียวในการสร้างรายได้จากเว็บแอป ไม่ว่าจะเป็นการโฆษณาออนไลน์ ลิงก์แอฟฟิลิเอต การสนับสนุน การโปรโมตผลิตภัณฑ์และบริการอื่นๆ หลายช่องทาง
อย่างไรก็ตาม เป็นเรื่องที่สมเหตุสมผลอย่างยิ่งที่นักพัฒนาเว็บจะอ่านพาดหัวข่าวและรู้สึกอิจฉาเล็กน้อยเกี่ยวกับเรื่องการชำระเงิน คุณไม่สามารถส่ง URL ของเว็บไปยังมาร์เก็ตเพลสแบบเนทีฟได้ แล้วนักพัฒนาเว็บจะทำอย่างไร สิ่งที่คุณต้องทำคือสร้าง "แอป Wrapper" แบบเนทีฟ โดยสร้างแอปที่มาพร้อมเครื่องเปล่าๆ ที่มีเพียงมุมมองเว็บสำหรับแต่ละแพลตฟอร์มที่คุณต้องการกำหนดเป้าหมาย มุมมองเว็บคือที่ที่คุณฝังแอปจริง จากนั้นคุณก็แค่ส่งแอปเหล่านี้ไปยังมาร์เก็ตเพลสต่างๆ (และหวังว่าจะได้เห็นเงินไหลเข้ามา!) ปัจจุบันมีแอปที่ทำงานบนเว็บหลายร้อยหรืออาจจะหลายพันแอปในมาร์เก็ตเพลสหลักๆ บางแอปก็กลมกลืนจนเราไม่รู้เลยว่าเป็นเว็บแอป
ข้อเสียคือภาระในการคอมไพล์แบบข้ามระบบไปยังแต่ละแพลตฟอร์ม นี่คือจุดที่เฟรมเวิร์กที่มีอยู่ เช่น PhoneGap สามารถช่วยได้ ยิ่งไปกว่านั้น ยังมีบริการบนเว็บอย่าง PhoneGap Build และ Apparatio ที่อยู่ระหว่างการพัฒนา เพียงชี้เว็บไซต์เหล่านี้ไปยังที่เก็บโค้ดของคุณ แล้วแอป Android, แอป iOS และอื่นๆ ก็จะปรากฏขึ้นมา… พร้อมให้คุณส่งไปยัง Store ที่เกี่ยวข้อง โดยไม่ต้องติดตั้ง SDK แบบเนทีฟในเครื่องของคุณ สิ่งที่คุณต้องมีในการสร้างแอปที่มาพร้อมเครื่องทั้งหมดนี้มีเพียงตัวแก้ไขโค้ดและเว็บเบราว์เซอร์เท่านั้น
มาร์เก็ตเพลสจะรองรับเว็บแอปโดยตรงไหม โดยไม่ต้องมีค่าใช้จ่ายเพิ่มเติมในการรวมแอปแบบเนทีฟ ยังไม่ชัดเจน เราทราบว่า Google เปิดตัว Chrome เว็บสโตร์เมื่อปีที่แล้ว และแม้ว่าจะใช้ได้กับเดสก์ท็อปเท่านั้น แต่ร้านค้าก็กระตุ้นความสนใจจากผู้ให้บริการเบราว์เซอร์รายอื่นๆ และเป็นส่วนหนึ่งของแนวโน้มโดยรวมที่มีต่อแคตตาล็อกเว็บแอป รวมถึงความพยายามบางอย่างที่เจาะจงสำหรับอุปกรณ์เคลื่อนที่ แนวคิดเรื่องเว็บสโตร์ยังอยู่ในช่วงเริ่มต้น แต่ก็มีสัญญาณที่ดี
บทสรุป
เราอยากจะประกาศผู้ชนะที่นี่ แต่ตอนนี้ยังไม่มีผู้ชนะที่ชัดเจน บางแอปเหมาะกับแอปที่มากับเครื่องมากที่สุด และบางแอปเหมาะกับเว็บมากที่สุด สแต็กเว็บอาจมีแรงผลักดันมากกว่า แต่ในแง่ของความสามารถและคุณภาพการดำเนินการ แอปที่มาพร้อมเครื่องก็พัฒนาไปอย่างรวดเร็วเช่นกัน และหากยังไม่มีช่วงเวลาที่เทคโนโลยีเว็บเป็นพลเมืองชั้นหนึ่งในระบบปฏิบัติการบนมือถือส่วนใหญ่ เนทีฟก็จะเป็นข้อพิจารณาที่สำคัญเสมอ
เทคนิคหนึ่งที่กล่าวถึงในบทความนี้คือแอปแบบไฮบริด ซึ่งอาจเป็นวิธีที่เหมาะสมที่สุดสำหรับนักพัฒนาแอปบางราย โดยใช้ WebView ในกรณีที่ทำได้ และใช้คอมโพเนนต์แบบเนทีฟเฉพาะแพลตฟอร์มในกรณีที่ทำไม่ได้
หากเลือกเส้นทางเว็บ ให้คำนึงถึงมาตรฐานเว็บและหลักการของการเพิ่มประสิทธิภาพแบบต่อเนื่อง เว็บเป็นเทคโนโลยีที่รู้วิธีกำหนดเป้าหมายอุปกรณ์และระบบปฏิบัติการจำนวนมากที่มีอยู่ ไม่ว่าคุณจะเลือกเรียกว่า "การกระจาย Fragment" หรือ "ความหลากหลาย" เว็บก็รองรับสิ่งนี้ และนักพัฒนาซอฟต์แวร์จะได้รับประโยชน์จากงานที่ปรากฏอยู่ก่อนทั้งหมดที่มีอยู่