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