Apple Releases Web Tool for Deactivating iMessage

Not long ago the internet was abuzz with articles and posts about Apple’s issues with iMessage. Users were concerned about not getting texts from iPhone users if they switched to another device. The issue stemmed from how iMessage works on the iPhone. When a user enables iMessage on their iPhone the phone sends a silent text message to either an SMS short code associated with the carrier the phone is being used on, or to one of several phone numbers in the United Kingdom if the phone is on a network that does not officially support the iPhone and is using the ‘unknown’ carrier bundle. This phone number responds with an activation message that uses a protocol called Application Port Addressing to direct the message to a specific process on the phone. If this completes successfully the phone number is registered with Apple’s servers as a number linked to an iPhone and all iOS and OS X devices are able to send iMessages to that phone number. In addition, all iMessages directed at that phone number will be pushed to all devices associated with the Apple ID on the iPhone.

This is where the issue would arise for users that switch from an iPhone to a smartphone running another operating system. When switching to another device, if the user does not go to the messages section of the iOS settings application and deactivate iMessage other iPhones will be unaware that the phone number is no longer being used on an iPhone and that it should be messaged using SMS. This posed a serious issue for users who lose their iPhone or have it damaged in such a way that they are unable to use it to disable iMessage. To make matters worse, if the user has iMessage enabled on other devices like an iPad or a Mac they must also deactivate it on those devices as even after deactivating on their iPhone the phone number will still be listed as an iMessage receiving address on those devices. This causes messages that should be sent by SMS to the new device to be sent as iMessages which are never received by the new phone.

Although this issue had existed since iMessage was released with iOS 5, it only became widely publicized during the last year. Apple has finally released a tool that allows users who cannot access their iPhone to deactivate the iMessage registration of their phone number. By inputting your phone number into the field on the website, Apple will send you an SMS message with a confirmation code. This code can then be entered into the website which will deactivate the iMessage registration for that phone number. It’s good to see that there is finally a solution for users suffering issues receiving text messages after switching from the iPhone, but it certainly did take a while. 

Source: Apple via The Verge

Quick Note: Android Camera2 and Support For External ISPs

While we’ve written about Android’s Camera2 API before, there was one notable aspect of the discussion that was missing. The missing piece was a discussion of the physical link needed to enable all of the controls that were previously discussed. This isn’t necessarily complicated, but it does represent a potential pitfall for updates to current devices. In short, the current protocols for using an external ISP provide insufficient bandwidth to support the full feature set needed for the new camera API.

This means that some of the interesting features, such as per-frame controls are impossible to enable. As a result, many devices that we’ve evaluated before such as the Galaxy S4 Snapdragon, Motorola Moto X (2013), HTC One (M7), and One (M8) won’t support per-frame controls and similarly bandwidth-heavy features. The Galaxy Note 3, S5, S4 Exynos, Note 4, and all Nexus device should support the full set of features in camera2 as they seem to only use an on-die ISP.

To understand why this is, we must understand the protocol that is used for communication. Today, the de facto standard for interfacing between the AP (application processor), ISP, and camera is MIPI’s CSI protocol. By and large, CSI-1 and CSI-2 are the most common iterations of this protocol. While the transport protocol (D-PHY) that actually carries the images has immense amounts of bandwidth (up to 10 Gbps), the control protocol defined has almost no bandwidth in comparison. Instead, the control protocol relies on fast-mode i2c, which can only provide 400 kbit/s of bandwidth.

While this may be an issue now, it seems that in the future this won’t be an issue. According to Arrow Devices, the MIPI CSI-3 protocol merges control and transport protocols into a single M-PHY bus for up to 18.6 Gbps of bandwidth. It’s likely that the demand for 4K60 video and 20+ megapixel burst mode functionality will drive adoption of this newer protocol. However, even now the disclosure of such protocols is rare, so it’s hard to say whether we’ll see widespread adoption of CSI-3 any time soon.

Google Updates Gmail With Material Design and Support for IMAP and Exchange

Google’s applications like Gmail, Camera, and Chrome are likely applications that came on your Android phone when you first purchased it. But unlike iOS where Apple has to ship an entire operating system update to update an application, Google’s apps for Android can be updated right from Google Play. Google has been steadily updating their applications to take advantage of their new “Material Design” design principles that were shown off at Google I/O. With Android 5.0 Lollipop on the horizon, Google has to get the remaining applications up to date, and the latest application to recieve the new visual style is Gmail with its major update to version 5.0.

As you can see above, there’s a lot of changes that come with the new Material Design interface. The most striking change is the the removal of the grey that was prevalent throughout the application. In the previous version, the color of an email preview changed to grey to indicate that the email had been read, while unread messages remained white. In the new design, the change between bolded or unbolded preview text indicates whether a message has been read. I personally find this to be much more aesthetically pleasing.

The header and status bar are now a nice moderately saturated red color that doesn’t feel gaudy but brings more color into the interface. The circular button for composing a new email at the bottom also uses this red color. On the topic of circles, Google has begun to use circular contact photos throughout their applications, although in my case they just display the sender’s first initial. If I had put in the effort to assign contact photos the new circles would display them where the squares previously did. 

Google has also redesigned the navigation drawer that houses your different inbox labels, and settings. The grey has been changed to white, and the top displays your cover photo from Google+ which seems to be a message from Google that you’re supposed to change it from the default rainbow thing. 

The sliding drawer is a topic of debate right now because many applications implement it incorrectly, including many that are made by Google like the Hangouts application. Google’s official guidelines state that the drawer is to slide in overtop of every other part of the interface except for the status bar. The new Gmail application implements this correctly, and I’m hopeful that every other Google application will be updated to adopt the proper design before Android Lollipop ships. It’s very difficult to get developers to follow design guidelines when you don’t set a good example with your own first party applications, and the navigation drawer in Hangouts has multiple issues with its design when compared to Google’s guidelines. 

The last big change in the application is the support for adding email accounts from other providers like Yahoo, iCloud Mail, Outlook, etc. Any email account that supports IMAP/POP or Exchange can be added. This is a great feature as it eliminates the need to have to add every non-Google email account to the standard Email application which isn’t given as much attention as Google’s own Gmail app.