SmartPhones4U.com

The final tablet we got our hands on during ASUS’s CES showing was the MeMO 171. We’ve seen this little guy before as the Eee Pad MeMO 3D — but this time they’ve dropped the 3D and hope to upgrade Honeycomb to Ice Cream Sandwich in the near future. The included capacitive stylus and MeMIC Bluetooth companion phone/media play is all here. As for the rest of the specs, they are as follows:

• 7" WXGA (1280 x 800) IPS panel with capacitive touch
• 1.2GHz dual-core Qualcomm 8260 processor
• 1GB RAM
• 16GB/32GB eMMC internal storage and "ASUS Webstorage" options
• WLAN 802.11b/g/n, Bluetooth 2.1 +EDR, and Qualcomm GPS One
• 5MP rear camera with autofocus and 1080P recording and 1.2MP front camera
• G-sensor, e-compass, light sensor, gyroscope, and proximity sensor
• Micro-USB port, micro-HDMI (1.3a), and MicroSD card reader
• 4400mAh lithium-polymer battery with 8.5hrs video playback
• 7.8 x 4.6 x 0.50" and 14.2oz

You could pretty much file the MeMO 171 under one more ASUS device we’ll likely never see hit stateside. I can’t imagine something like this would do very well in the US and ASUS specifically mentioned they currently have no plans to bring the MeMO 171 anywhere outside of it’s homeland. What do you guys think? Heartbroken? Or is the MeMO 171 too gimmicky?

Mobile app monetization and distribution networkW3iis announcing the results of its tests to determine whether or not an iPhone’s MAC address can serve as a replacement to the UDID (the unique device identifier), which Apple is phasing out as a way for developers to track an app’s users.

According to W3i, developers can and should begin tracking the iPhone’s MAC address as a UDID alternative, as it has successfully seen Apple approve its own application where this is the case. Unfortunately, this advice is arguably premature. Apple may let slip a single app, but if a large number of iOS developers began doing the same (tracking the MAC addresses, that is), Apple may certainly change its position on the matter.

For background, in August, Erick reported howApple sneaked a major change into iOS5: it was deprecating developer access to the UDID. The UDID, an alphanumeric string unique to each Apple device, has been used by mobile ad networks, game networks, analytics providers, developers and app testing systems likeTestFlight. In some cases, developers used the UDID to verify whether users were accessing their app from a new device or as a way to track users across apps.

Since that change was revealed, companies have been scrambling to come up with workarounds. OpenFeint announced its UDID replacement OFUID. AppsFire proposed an open source solution calledOpenUDID. And now W3i is suggesting developers use the iPhone’s MAC address – specifically the MAC address of the device’s Wi-Fi network interface.

The MAC address, also a unique identifier, is used for communications on a physical network segment. What W3i wanted to determine was whether or not that address could be reliably captured across multiple device types and with different configurations (e.g., airplane mode, Wi-Fi off or on, not in range, etc.)

Using its proprietary app, AppAllStar, which was submitted and approved on October 5th, W3i collected 78,662 MAC addresses from 10/5 to 10/22, representing 100% of the installs across iPhone, iPod Touch and iPad devices. The app was also resubmitted during that time (on Oct. 1oth) to correct some non-test related errors. In both cases, the company says it placed the code at a very high level while also naming the classes appropriately.

W3i, however, did find that 33 devices had a duplicated MAC address, which W3i thinks may indicate either jailbroken or knock-off devices. A subset of those had spoofed UDIDs as well. The data on where the duplicates were located is interesting. China and the Netherlands each had 9 duplicates, Italy had 5, Spain 3, Saudi Arabia 2, and Singapore, the U.S., Australia, Czech Republic and India each had 1.

Based on these findings, W3i is now recommending that developers begin collecting and storing Wi-Fi MAC addresses with the associated UDID and modify the application logic to use both UDID and the Wi-Fi MAC address.

Of course, all this advice may be worthless in the long run. A test involving a single application is by no means definitive proof that this is something Apple would allow on a larger scale. After all, considering that the removal of developer access to the UDID was intended to better respect user privacy, simply allowing developers to switch to a second unique ID would violate the spirit of Apple’s decision, if not the actual terms.