tags:

views:

696

answers:

2

I did some searches and found that if want to adjust the brightness, I need to use private framework and apple will reject it.

If I just want to get the value of brightness(just get that value to display, not adjust it), is there a way which apple accept?

+1  A: 

Using a undocumented API of a public framework is not necessarily bad. I know many people, including myself who use undocumented methods here and there, for example to check for connectivity or add text fields to UIAlertViews.

On the other hand, linking to a private framework is much worse, because those tend to be very volatile, and might be removed from 3.0, or renamed.

I'm not sure about the specifics of your case, but the distinction between private framework or undocumented APIs of a public framework is important.

Kenneth Ballenegger
I find both practices tricky business. You never know how Apple will react. And as you well stated, the implementation could break with a new OS.
Kriem
A: 

There is no way to answer the question "will Apple allow it?" You have to pick your risk tolerance and submit. Personally, I stay away from things that are undocumented. But in the cases that I do enhance my programs with things on the edge (generally undocumented things that are not actually private), I try to make my program resilient to changes.

One major way to do this is to check whether the thing you're about to link to or function you're about to call exists. For methods, you can use -respondsToSelector: before calling it. For functions, you can test whether the function exists:

extern void SomeFunction() __attribute__((weak_import));

if (SomeFunction != NULL) {
   SomeFunction();
}

(You'll need to test that out on iPhone; I use it on Mac, and weak_import should be portable since iPhone uses GCC4. See Ensuring Backward Compatibility. So far, I've always been able to find some trick to avoid actually needing this on iPhone.)

The key to all of this is to make sure your program functions without the undocumented feature. That way, even if Apple rejects it, pulling it out is trivial.

That said, for me this is a last resort for things I've spent a lot of time trying to do in a documented way, for things that provide a significant improvement to the user experience, and don't violate Apple's basic intent. For instance, running in the background, even if you can get it to work, is a clear violation of the spirit of Apple's rules; other things are private just because they haven't been made public, like the internal views of UI elements.

Changing the screen brightness in a way that persists outside your app would seem a violation of the basic rules of play (stay in your sandbox). Getting the current screen brightness doesn't sound like that (though I'm not sure what you would do with it.)

Rob Napier