การมาของ iOS 7 หลายๆ แอพอาจงานเข้า!

นั่งอ่าน iOS 7 UI Transition Guide, Designing for iOS 7 และ UIKit User Interface Catalog ของ iOS 7 แล้วต้องบอกสั้นๆ ว่า “ทำเอพใหม่อาจง่ายกว่ามั้ง” จริงๆ ผมถืองานพัฒนาตัว iOS App ไว้อยู่ตัวนึง และที่กำลังคิดว่าจะออกอีกหลายตัว (ผมมี account ตัว iOS Developer และเป็นคนสั่งเค้าทำอีกทีมากกว่า) แต่ดูท่าคงต้องได้รื้อทำหน้าตาใหม่ให้สอดคล้องกับแบบนี้ด้วย แต่ดีว่าไม่มากนัก เพราะใช้ Native UI เป็นหลัก ><~

สำหรับหน้าตาคงไม่เอามาโพสซ้ำ หาได้ทั่วไปตามเว็บข่าวต่างๆ ค้น Google หน้าจะเจอ

โดยผมขอขยายความของปัญหาจริงๆ นั้นแบ่งเป็น 3 ส่วนหลักๆ

  1. การเปลี่ยนตัวควบคุม (Control UI) เป็นปัญหาในการออกแบบหน้าตาให้สอดคล้องกับ iOS 7 ในแอพตัวเก่าๆ โดยปัญหามักจะเป็นพวกแอพที่สร้างตัวควบคุมและหน้าตาของ UI ที่ไม่ได้ใช้ชุด UI แบบ Native หรือใช้ปนๆ กัน จะมีปัญหาด้านความต่อเนื่องสูงมาก
  2. แนวทางออกแบบในการใช้ตัวอักษร (font) ปัญหาเรื่องของ system font ที่มีการเปลี่ยนแปลง โดยปัญหาหลักคือ spacing ระหว่างตัวอักษรของ system font ใน iOS 7 ที่อาจจะมีปัญหากับแอพเก่าๆ ทุกตัวที่ใช้การแสดงผลชุด label ที่ใส่ข้อมูลพอดีกับขอบของแอพ ซึ่งอาจทำให้แอพต่างๆ ต้องทำ auto switch theme (layout) เพื่อทำให้การแสดงผลสอดคล้องกับ iOS 7 และตัวก่อน iOS 7 ไม่งั้นงานเข้ากันทั่วหน้าแน่ เพราะคำและกลุ่มคำจะตกขอบตัว label ซึ่งแน่นอนว่าคนจะด่าแอพเหล่านั้นกันทั่วหน้าแน่ๆ (ไม่ด่า Apple หรอก ลอยตัวเหนือปัญหาแน่ๆ)
  3. ในส่วนของ transition และ motion design อาจต้องเลี่ยงการใช้ gesture ชุดเดียวกับ system gesture บางส่วน เช่น ปัดนิ้วจากล่างขึ้นบนเพื่อเรียก Control Center หรือปัดในทิศทางอื่นๆ ที่เป็น system gesture ตัวใหม่ๆ ในอนาคต การพลิบและการเลื่อนเปลี่ยน App Page ไปมา อาจต้องไล่กำหนดใหม่เพื่อให้สอดคล้องกับ Control UI และรูปแบบ gesture ด้วย

โดยทั้งหมดทั้งหมดใน 3 ส่วนนี้ต้องมานั่งแก้ไขกันอีกเยอะแน่ๆ ครับ (ยังมีอะไรด้านหลังอีกหลายส่วนที่คาดว่าอาจมีการปรับใหม่อีกหลายรอบ) ซึ่งตอนนี้สำหรับนักพัฒนาใน iOS 7 และคนที่ดูแลโครงการพัฒนา App บน iOS คงต้องไล่อ่านคำแนะนำ UX/UI บน iOS ในหน้า developer site ของ Apple แล้วเอามาวางแผนแก้ไขให้แสดงผลได้อย่างถูกต้องใหม่ ซึ่งหากไม่ทำแบบนั้น จะทำให้ UX/UI ของแอพใน iOS 7 มีปัญหาหนักเมื่อเอาแอพจากตัวเก่าๆ ที่ไม่ได้ปรับแต่งการแสดงบน iOS 7 มาใช้งานครับ

เรื่องเล่าของ Bluetooth Keyboard ที่ใช้งานร่วมกับ Android ได้อย่าง RAPOO E6500 และ Microsoft Wedge Mobile

อยู่ๆ ก็อยากได้ Keyboard มาใช้งานร่วมกับ Android Tablet ที่ผมมีอยู่อย่าง ASUS Nexus 7

วันนี้เลยไปเดินดู ตอนแรกผมได้ Rapoo E6500 Ultra-thin Blade Wireless Bluetooth 3.0 for Android มาก่อน เลยเอามานั่งเล่น โดยรวมมันเล็กดีครับ แต่พอพิมพ์และเล่นไป รู้สึกว่ามันเล็กไป (อ้าววว ไอ้บ้า ตอนซื้อไม่คิด) ก็เลยไปเดินเล่นใน IT City ไปสะดุดกับ Microsoft Wedge Mobile Keyboard เข้า พลิกกล่องไปๆ มาๆ มันไม่ได้บอกว่าใช้กับ Android ได้แฮะที่กล่อง ผมเลยเปิดมือถือค้นหาดูว่ามีใครเขียนรีวิวเรื่องนี้ไว้แล้วเค้าใช้ Android ได้ไหม สรุปว่าได้ แต่ด้วยความไม่มั่นใจ เลยขอทางร้าน IT City เค้าทดสอบอีกที เค้าก็เลยแกะกล่องใหม่มาให้ลอง Pair กับมือถือผมเลย แล้วผมก็ลองพิมพ์ดู สรุปว่าได้แฮะ แถมการ Pair ก็ไม่ได้ยุ่งยาก สรุปเหมือนมัดมือชก ถ้าได้ก็ต้องซื้อ (ร้านแผนสูงนะเนี่ย) สรุปเลยจัดมาเลยอีกตัว ><” (แกลบครับเดือนนี้)

DSC_1771

ด้านล่างเป็น Rapoo E6500 Ultra-thin Blade Wireless Bluetooth 3.0 Android ส่วนด้านบนเป็น Microsoft Wedge Mobile Keyboard จะเห็นว่ากล่องใหญ่แตกต่างกันอย่างมาก ><”

ด้านราคาแล้วนั้น RAPOO E6500 ค่าตัวอยู่ที่ 1,490 บาท ในความรู้สึกส่วนตัวแล้วไม่แพงมากสำหรับ Bluetooth Keyboard ที่ใช้งานร่วมกับ Smartphone และ Tablet ค่าย Android ครับ

ด้านราคาของฝั่ง Microsoft Wedge Mobile Keyboard นั้นอยู่ที่ 2,590 บาท ถือว่าราคาแรงพอสมควรสำหรับหลายๆ คน แต่ถ้าพูดถึงความสามารถในการเชื่อมต่อกับหลายๆ OS แล้ว ผมถือว่าชนะขาดหลายๆ ค่ายเลย ซึ่งตัว Wedge Mobile Keyboard นั้นสามารถเชื่อมต่อผ่าน Bluetooth เข้ากับ Windows 7/RT/8 ได้สบายๆ และยังสามารถใช้กับ Mac OS X สำหรับ Desktop/Notebook โดยทั่วไป และยังสามารถเชื่อมต่อกับ iOS และ Android ได้โดยไม่แยกรุ่นแบบของ RAPOO ที่มีรุ่นสำหรับ iPad และ Android แยกขายคนละรุ่น ซึ่งถ้าซื้อมาใช้พกพาแล้ว Wedge Mobile Keyboard จบในตัวเองเลยด้านการเชื่อมต่อหลายๆ OS

DSC_1776 DSC_1778

ในด้านการใช้งานแล้วนั้น Rapoo E6500 Ultra-thin Blade Wireless Bluetooth 3.0 Android มี Layout ของการจัดวางปุ่มที่แปลกสักหน่อย ถ้าใครซื้อมาเป็นแบบ Screen ปุ่ม US แนะนำให้หาสติกเกอร์มาแปะสักหน่อย ไม่งั้นพิมพ์ไทยหลงปุ่มแน่ๆ ในด้านการพิมพ์ภาษาอังกฤษอันนี้สบายๆ ไม่มีปัญหาอะไร แต่ถ้าพิมพ์ภาษาไทยเนี่ยลำบากพอสมควรเลย เพราะบางปุ่มที่ภาษาอังกฤษใช้เป็นสัญลักษณ์ในภาษาอังฤษจะโดนลดบทบาทลงด้วยการย้ายปุ่มไปตำแหน่งอื่น แต่ในภาษาไทยไอ้ปุ่มที่โดนย้ายไปเนี่ยมันเป็นปุ่มที่โดนควบด้วยปุ่มภาษาไทยที่ใช้บ่อยๆ อยู่หลายตัว เพราะฉะนั้นอาจลำบากสำหรับคนที่ซื้อมาพิมพ์ภาษาไทย (แนะนำให้หาสติกเกอร์ภาษาไทยมาใช้ควบคู่ด้วย)

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

ส่วนเรื่องของ Battery นั้นตัว Rapoo E6500 นั้นเป็น Battery แบบ Li-ion แบบใส่มาในตัวเลย การชาร์จก็ใช้ผ่าน microUSB ง่ายๆ สำหรับการ Pair ตัวคีย์บอร์ดตัวนี้ไม่ยากอะไร และ Pair ได้เร็ว แต่ใช้ได้กับ Android OS และ HID Profile บน Desktop/Notebook เท่านั้น ไม่สามารถใช้บน iOS ได้

DSC_1793 DSC_1794

ตัวต่อมาเป็นตัวที่ผมรู้สักประทับใจมากเมื่อได้สัมผัส ก็คือ Microsoft Wedge Mobile Keyboard จากที่บอกไปแล้วว่าตัวคีย์บอร์ดตัวนี้สนับสนุน OS หลากหลายกว่า Rapoo และแน่นอนว่าขนาดของตัวคีย์บอร์ดตัวนี้มีขนาดใหญ่กว่า Rapoo E6500 ที่วางเทียบๆ โดย Rapoo มีขนาด 21cm x 8cm ส่วน Wedge Mobile Keyboard มีขนาด 25.5cm x 10cm จะเห็นว่าระยะความกว้างของ Wedge Mobile Keyboard นั้นกว้างกว่าพอสมควร ทำให้การจัดเรียงตัวปุ่มนั้นทำได้ใกล้เคียงกับคีย์บอร์ด Notebook ขนาดเล็กเลย และสำหรับ Layout ภาษาอังกฤษนั้นไม่มีการโยกย้ายปุ่มแบบ Rapoo ทำให้เวลาเปลี่ยนมาพิมพ์ภาษาไทยนั้นทำได้ง่ายกว่ามาก รวมถึงระยะปุ่มก็ห่างก็พอกัน ทำให้ไม่พิมพ์ผิดได้ง่ายเท่า Rapoo ที่ตัวเล็กกว่า (แถมโยกย้ายปุ่มอย่างที่บอกไป)

สำหรับในด้านการตอบสนองการพิมพ์นั้น Wedge Mobile Keyboard นั้นปุ่มนิ่มกว่า เลยไม่ต้องใช้แรงกดเยอะ แต่การตอบสนองทำได้ดี และฐานตัวคีย์บอร์ดทำได้แข็งแรงกว่า Rapoo อีก ทำให้พิมพ์แล้วไม่ยวบลงไป ซึ่งกดพิมพ์แล้วมั่นใจมากๆ อันนี้ ถ้าเทียบกันทั้ง Rapoo และ Wedge Mobile Keyboard ทำได้ดีทั้งสองตัวเลย

DSC_1803 DSC_1801

แน่นอนว่า Wedge Mobile Keyboard เป็นแบบ Wireless การใช้พลังงานนั้นแตกต่างจาก Rapoo E6500 เพราะใช้ Battery Alkaline ขนาด AAA ทั้งหมด 2 ก้อนมาใส่ที่ฐานแล้วเปิดใช้งาน ตัวคีย์บอร์ดมีปุ่มสำหรับเชื่อมต่อ Bluetooth เท่านั้น ไม่มีปุ่มปิดเฉพาะแบบ Rapoo แต่อย่างใด แต่ใช้ Multi-purpose Cover มาเปิดตัวคีย์บอร์ดแทน ก็คือการปิดการใช้งาน แต่เจ้าตัว Multi-purpose Cover ที่ให้มานอกจากจะเป็น Cover ของตัวคีย์บอร์ดแล้ว ยังเป็น Stand ให้กับตัว Tablet ให้เราได้อีกด้วย ซึ่งซื้อคีย์บอร์ดตัวนี้คิดซะว่าได้แถม Stand มาอีกตัวในชุด (ผมว่าคุ้มนะ Stand ตัวนึงก็ราคาหลายร้อยอยู่)

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

“บังคับ” ทางเลือกที่ยากลำบากของ Apple

ขอเอามาจาก Tweet ใน Twitter นิดนึง

ผมขอเสริมขยายความความรู้สึกตัวเองในฐานะผู้ใช้งาน iOS 6 บน iPod Touch/iPad และ iOS Developer Account คนหนึ่ง

Maps ตัวใหม่ หรือ Keyboard 4 แถวของไทยใน iOS 6 จะไม่ใช่ประเด็นเลย ถ้า Apple มีทางเลือกให้ผู้ใช้ว่าจะใช้ตัวเก่าหรือตัวใหม่ แต่ Apple เลือกที่จะ “บังคับ”

การเลือกที่จะ “บังคับ” ถ้ามันห่วยกว่าเดิม หรือไม่ถูกจริตคนใช้งานเก่าๆ นั้น ตัว Apple เองแหละที่จะลำบาก

ซึ่งคงเหมือนกับ Start Screen ใน Windows 8 ซึ่งตัด Start Menu ออกไป แต่ Start Screen ใน Windows 8 ยังไม่ใช่ประเด็น เพราะผู้ใช้ยังสามารถหา Software ทีทำงานคล้ายๆ กันมาใช้งานทดแทนได้ทันที และผู้ใช้มีทางเลือกว่าจะอัพเกรดหรือไม่ก็ได้ในระหว่างนี้ โดยถ้าจำเป็นต้องอัพก็มีเวลาเตรียมตัว สร้างความคุ้นเคย นั้นทำให้ทุกคนรู้และได้ลองก่อนอัพแน่ๆ มันจึงเป็นที่มาของ Release Preview และ Evaluate Version ให้ทดลองใช้ 90 ก่อน

สำหรับ Apple ในเรื่องนี้นั้นเหมือน “หักดิบ” แถมการ downgrade กลับไป iOS 5 ถึงจะทำได้ในทางเทคนิค แต่ก็ไม่ง่าย และแต่นั้นหมายถึงความเสี่ยงต่อการที่ข้อมูลที่ upgrade มาจะย้อนกลับไปใช้งานกับ iOS 5 ไม่ได้ด้วย

สิ่งที่น่าคิดคือ ถ้ายังไม่พร้อมทำไมไม่มีทางเลือกให้คนใช้งานเพื่อทดแทนความไม่พร้อมของตัวเอง แทนที่จะบังคับใช้ น่าจะค่อยๆ ปรับเปลี่ยน แล้วรับฟังความคิดเห็นจากผู้ใช้ทั่วๆ ไป แทนที่จะฟังแต่ developer กลุ่มเล็กๆ ทั้งในและนอกบริษัทตัวเอง ซึ่งมันอาจจะเป็นเพราะสิ่งที่ตัวเองยึดมั่นถือมั่นกับความสำเร็จเก่าๆ มันบังตาไปหมดแล้ว จนลืมไปว่า Ping ของตัวเองก็ล้มเหลวมาแล้ว และ Apple ก็ไม่รู้จักจำ เพราะขนาด developer account ที่ได้ทดลองใช้งาน iOS 6 มาก่อนล่วงหน้านานหลายเดือนยังบอกเลยว่า Maps ตัวใหม่นั้นยังไม่พร้อม ยังตามหลังคู่แข่งอย่าง Google Maps ที่ตัวเองถอดออกไปอยู่เยอะมาก แต่ developer account หลายๆ คนเชื่อมั่นว่าเมื่อถึงวันเปิดตัว คงพร้อมมากกว่านี้ แต่แล้วพอวันที่ Release จริง ทุกอย่างก็เหมือนเดิม

หรือจริงๆ แล้ว Apple ไม่เคยฟังใครเลย….

เมื่อ Web/Windows Developer จะกระแดะไปทำ iOS App ชีวิตมันก็ไม่ง่าย

เมื่อวันเสาร์ที่ผ่านมาไปงาน Bangkok Adobe Camp ได้พบทางอีกทางที่น่าจะโอเคสำหรับคนใช้ Windows แต่อยากทำ App บน iOS แน่นอนว่ามันต้องทำด้วย HTML5 + jQuery Mobile สิ่งที่ต้องการไม่มีอะไรมากมาย ให้มันทำงานได้บนนั้นและ call พวก native api ทั่วๆ ไปได้ เช่นพวกกล้องถ่ายรูป ฯลฯ พวก sync data ต่างๆ

ซึ่งผมก็รู้จักกับ Build.PhoneGap.com มาได้สักพักใหญ่ๆ แล้ว แต่ไม่ทราบว่ามัน Compile in the Cloud ได้ เพราะจำได้ตอนที่ได้ลอง PhoneGap ตอนแรกผิดหวังมารอบแล้ว เพราะว่ามันไม่สามารถ build บน Windows ให้เป็น ipa ได้ เพราะขาด SDK ของ iOS นั้นเอง

แต่เมื่อวันเสาร์พอทราบ ผมก็นั่งๆ ลองๆ หาข้อมูลต่อไป ซึ่งสุดท้ายแล้วการจะ Build ตัว iOS App บน Build.PhoneGap.com ต้องใช้ Signature Certificates ของ Apple ด้วย สุดท้ายวันอาทิตย์ตอนดึกๆ ก็เลยสมัคร Apple iOS Developer ไปซะเลย หมดไป $99 ซะอย่างงั้น (นี่มันลองของจริง เสียเงินแพงมาก!!!)

พอสมัครเสร็จรอ confirm อีเมล ตอนเช้ามาก็ได้ลองของ สิ่งที่ไม่คาดคิดก็เกิดขึ้น ขั้นตอนการสร้าง Certificates บางตัว ต้องใช้ Keychain Access บนเครื่อง Mac …. T_T

ผมก็เลยไปยืมเครื่องพี่ที่ทำงานเค้าทำให้แทน ขั้นตอนมันก็มีประมาณนี้

  • ไป generate ตัว Certificate Signing Request จาก Keychain Access บนเครื่อง Mac ก่อน เสร็จแล้วไป submit ในเว็บ Apple ที่ iOS Provisioning Portal เมนู Certificates
  • รอสักพักจะได้ developer_identity.cer ออกมา แล้วให้ import cert ตอนนี้เข้าเข้า Keychain Access แล้ว Export เป็น Certificates .P12
  • เสร็จแล้วกลับไปที่ เว็บ Apple ที่ iOS Provisioning Portal ก่อนหน้านี้
  • สร้าง Profile ของ Devices
  • สร้าง App ID จาก App IDs
  • สุดท้ายสร้าง Provisioning Profiles เพื่อให้ได้ mobileprovision ออกมา
  • แล้วเอาทั้ง Certificates .P12 และ mobileprovision จากเว็บ Apple ที่ iOS Provisioning Portal มา submit ที่ Build.Phonegap.com

พอได้ Certificates .P12 และ mobileprovision แล้วอะไรก็ไม่ยากแล้วครับ ^^/

เดี่ยวขอเวลาไปลองเล่นสักแป็บ ^^

ลองเล่นๆ แงะ Backup ของ iOS 4 เพื่อดึงการเก็บข้อมูลพิกัดของผู้ใช้งาน

จากข่าว iOS 4 เก็บข้อมูลพิกัดทุกคนไว้โดยตั้งใจ ก็เลยรู้สึกคันไม้คันมือลองของ เนื้อหาตอนนี้เขียนขึ้นเพื่อเตือนและให้ระมัดระวังตัว เพราะฉะนั้นหวังว่าจะมีประโยชน์กับคนที่อ่าน แน่นอน อุปกรณ์และตัวอย่างทั้งหมด ไม่ได้ jailbreak หรือ hack/crack แต่อย่างใด เพราะส่วนตัวแล้วนั้นผมใช้ iPod Touch 4 อยู่แล้ว และไม่ได้ jailbreak ใดๆ Apps ทุกตัวซื้อทั้งหมด และใช้งานตาม EULA ของ Apple ซึ่งตัว iOS ที่ใช้ก็ือ 4.3.2 ตัวล่าสุด! แน่นอนว่ามันมีข่าว ผมก็ต้องจัดสักหน่อย ดูว่าเป็นอย่างที่เค้าว่ากันว่าไหม

จากแหล่งข้อมูลอ้างอิง ผมใช้ข้อมูลตัวอย่างจากการ Backup เป็นหลักแล้วกัน ถ้าจะให้เข้าไปเอาจากในเครื่องเลย ดูจะเสียเวลาและดูยุ่งยาก ซึ่งแน่นอนว่าเป็นข้อมูลที่เข้าถึงง่ายที่สุดและไม่ได้อยู่ติดตัวผู้ใช้ตลอด ทำให้โดนเอาไปใช้งานได้ทันที!!!! รหัสผ่านไม่ต้องกรอก แต่สามารถเข้าถึงเครื่องที่ iPhone/iPod Touch รุ่นนั้นๆ เคย Sync ไว้กับเครื่องของไว้ ก็จะสามารถนำข้อมูลส่วนนี้และนำไปใช้งานได้ทันที

เพราะฉะนั้นถ้าคิดว่าเอาไปให้ร้านมือถือ upgrade ให้ก็จงระวังให้หนักสำหรับเรื่องตรงนี้ครับ โดยเฉพาะคุณผู้หญิงทั้งหลาย เพราะมันลากไส้มาตั้งแต่คุณ activate เครื่องในการซื้อครั้งแรกเลย เพราะงั้น ถ้าเราเอาข้อมูลพวกนี้มาทำสถิติก็จะพอบอกได้ว่าบ้านและสถานที่ที่ไปบ่อยๆ นั้นอยู่ที่ไหนบ้าง

เรามาเริ่มกันเลย การเข้าถึงแหล่งข้อมูล Backup นั้นผมอ้างอิง path ของระบบผ่าน Microsoft Windows 7

C:\Users\[Windows's User Name]\AppData\Roaming\Apple Computer\MobileSync\Backup\xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-yyyymmdd-hhmmss

[Windows’s User Name]
ชื่อ User Name ของ Windows ที่ใช้งานอยู่

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
คือรหัส 40 ตัวอักษรที่ hash ไว้

yyyymmdd-hhmmss
วันและเวลาที่ backup

ใน directory ปลายทาง หาไฟล์ที่ชื่อ

4096c9ec676f2847dc283405900e284a7c815836
เป็นไฟล์ฐานข้อมูลของ SQLite และ “ไม่ได้เข้ารหัส”

ใช้ SQLite Manager ที่เป็น Extension ของ Mozilla Firefox เปิดเอาก็ได้แบบนี้!

Table ในฐานข้อมูลที่ต้องสนใจคือ CellLocation และ WifiLocation ครับ

จะได้ข้อมูลเวลา สถานที่ที่เป็น lat/long ชัดเจนมาก โชคดีที่ผมใช้เป็น Wifi แต่ถ้าเป็นมือถืออย่าง iPhone ก็จะอยู่ที่ CellLocation โครงสร้างก็ไม่แตกต่างกันครับ เอาข้อมูลไป lat/long ไปค้นหาใน Google Maps ได้ทันที จะเขียนโปรแกรม ฯลฯ ก็น่าจะยากสำหรับคนที่ต้องการติดตามตัวครับ!!!

เนื้อหาตอนนี้เป็นการตีแผ่และหวังว่าในอนาคต Apple จะปรับปรุงการเก็บข้อมูลส่วนนี้ให้มีความปลอดภัยมากขึ้น และแจ้งผู้ใช้งานก่อนไม่ใช่อยากจะเก็บก็เก็บโดยไม่ได้บอกผู้ใช้ก่อนแบบนี้

ปล. เนื้อหาบทความนี้อาจจะอายุไม่ยืน ถ้ามีการแจ้งให้ลบบทความจากหน่วยราชการคงต้องลบนะครับ ;P

อ้างอิงจาก http://petewarden.github.com/iPhoneTracker/

หมายเหตุ : วิธีนี้จะใช้ได้ผลใน iOS รุ่นที่ต่ำกว่า iOS 4.3.3 ลงมา