Posted on by

So this past weekend I went to the AT&T and Verizon stores with the crazy idea that I might be able to get my hands on a demo model of the iPhone 5. Of course, the carriers don’t have demo units yet, so while I was at the Verizon store I decided to check out the Galaxy S3.

I’ll admit it’s a nice phone and the screen size is very appealing. The phone is light, the screen is bright, and the price is right. But, while I was fondling the demo unit, I notice that there was a ghost image just under the surface of the display. Regardless of app or orientation it was there. The letters read “S Beam” with two back to back phones featured just below that. At first, I thought it was some sort of in-store watermark, but then it hit me. The S3’s Super Amoled screen was suffering from screen burn in. After hours of running in-store demo software that continually promoted the S Beam feature, the image was permanently burned into the screen. Not good.

This got me to thinking about all the desk clock app developers who are going to get complaints that their software caused burn in on Galaxy S3 screens, when in fact it’s the super amoled screen itself. It also got me to thinking about how the burn in issue can become a way for app developers to separate themselves from their competition. If they can take steps to educate S3 phone owners and toute that their app takes steps to reduce the chance of burn in, then they have selling point that other clock app developers dont have. Are you with me?

Okay, so how would something that work? Well, first you would have to detect that the app is installed on a Galaxy S3. At which point you might want to provide an initial message to the customer that says something like, “Screen burn in isn’t any fun, so we’ve included options to help reduce the change that it will happen to your S3.” Then you could display an options panel with burn in reduction automatically checked. How you decide to provide “burn in reduction” is up to you as the app developer, but a few ideas would be to move the clock around on the screen like screen savers do. This isn’t really a new problem for displays, so just borrow previous solutions and apply them to your mobile app.

As for detecting what device your customer is on, the Corona SDK provides system.getInfo(), which “returns information about the system on which the application is running.” Also, as of Build 909 Corona updated model names in the Corona Simulator of Galaxy SIII and Kindle Fire HD to match the actual devices, which means you should be able to test for the Galaxy S3. I haven’t written code to do this yet, be sure to post in the comments if this does or doesn’t work for you.

In a market filled with apps competing for attention, having some sort of edge is important, no matter how small. The important thing to realize is that Samsung may see screen burn in as a problem that costs them money in repairs and warranty replacements, but for app developers it means opportunity.

How do you handle these types of issues in your app? Post a comment.

Charles McKeever
Corona Geek


Posted by . Thanks for reading...

One Response to “Avoiding Screen Burn In on Galaxy S3 Phones – How App Developers Can Set Their Apps Apart From The Competition”

Leave a Reply

  • (Will Not Be Published)