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?
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.
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.)
Related
For instance, I subclassed UILabel and added a method or property called -verticalTextAlignment to align text vertically.
And in the future, if next version of SDK or iOS added a method or property which has the same name, then it is possible my app crashs or behaves unexpectedly.
*This problem happens even if you use category instead of subclassing.
Question1
How to avoid this kind of accidental overriding in Objective-C?
I think you can avoid this by prefixing all of your methods and properties like -XXX_verticalTextAlignment. But it is not realistic, is it?
Question2
I know that this kind of accidental overriding happens at compiling time or when you update your iOS SDK, OSX SDK, or XCode.
But is it possible to happen also when updating your iPhone's iOS version?
For example, is it possible that your app runs well on iOS5 but doesn't run on iOS6 due to accidental overriding in iOS6.(You can replace iOS5 and iOS6 with any versions, for example iOS5.0 and iOS5.1)
Yes you could use your own prefix, however that is uncommon.
Yes, it can happen after an O/S update; Objective-C is a very dynamic language where messages are sent to methods rather than being called, as in other languages. These things are worked-out at runtime, not compile time.
Bottom line is yes, you might accidentally override a future base class method and the only solution is to be there when it happens and rename the method.
Prefixing your category methods are the safest way to avoid these conflicts in an every growing, non namespaced cocoa ecosystem.
It's quite valid and reasonable that framework creators, open source developers and other individual developers should prefix their class methods.
Quite often I write methods prefixed with my company initials, then continue with the method.
- (void)JCMyMethodNamedSimilarToBaseClass;
Question 1a Category
Use a prefix, or avoid the whole mess and use functions instead.
Question 1b Subclass Methods
If a method does something general enough that the superclass may also implement it, I simply choose a method name which is a little more 'wordy' than Apple would conventionally choose -- such as specifying a non standard typename in the method's name. Of course, this only reduces the possibility of collision.
If you need a higher level of security, you could just test this at execution (so you know when they are introduced) and hope every user stays up to date -- or you could rely on C and/or C++ more heavily (they do not have this problem).
Question 2
But is it possible to happen also when updating your iPhone's iOS version?
Yes. It's not so unusual. When the frameworks are updated (e.g. via software update), they may contain updated frameworks. This code is loaded into the objc runtime, and you always get the version of the installed frameworks' objc implementations.
It's also a much broader problem on OS X, where you may load code and/or plugins dynamically quite easily.
An elegant solution is to check for the method being already there and only adding it if it isn't: Conditional categories in Mountain Lion
Apparently Apple has changed some term in the agreement again.
From http://www.appleoutsider.com/2010/06/10/hello-lua/
section 3.3.2 is now
Unless otherwise approved by Apple in writing, no interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s). Notwithstanding the foregoing, with Apple’s prior written consent, an Application may use embedded interpreted code in a limited way if such use is solely for providing minor features or functionality that are consistent with the intended and advertised purpose of the Application.
instead of the original
No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).
I am more interested in embedding Lua, but other people have other embeddings they want to make.
I am wondering how you ask for permission, and what they mean by the terms "minor features" and "consistent" and how will Apple interpret this section? It seems to have enough loopholes to drive a real firetruck through.
(BTW this is a terribly important question for me an my product.)
Realistically, the ultimate interpretation of the developer agreement is up to Apple.
Since this is all new, it's not clear who to e-mail. You could start with the iTunes Connect people, but be prepared for a long wait to hear back. Alternatively, I've gotten some occasional quick help just by calling up the nice Apple people in Ireland.
Given the wording , if you want to embed Lua, you should be prepared to justify that you will be using Lua in a limited fashion to provide minor features or functionality.
Since you've stated this is a really important question, you might want to consider the risks inherent with pushing the envelope/being a pioneer. If there's an alternative way to get around all this, you should consider it. If there's no way around it, it might make more business sense for you to pursue another platform for now.
How do you design a UI like Facebook?
Is it hard to implement a custom skin into a iphone app? How is it done?
Do I need to follow apple's guideline? What if I don't want to?
How do you design a UI like Facebook?
Facebook's iPhone app appears to be built around using UITableView in various guises. It looks like it adheres to the Apple Human Interface Guidelines.
Is it hard to implement a custom skin
into a iphone app? How is it done?
Skins are just graphic elements that are designed to have their image components swapped out. They are not difficult to implement.
Do I need to follow apple's guideline?
What if I dont want to?
Apple will not penalize you for a non-standard interface. The only interface restrictions are (1) some issues of obscene content and (2) you can't create the illusion that the device itself is broken, has crashed or otherwise failed.
A bit of advice. Don't use non-standard interfaces.
Good interfaces are almost by definition standardized so that users don't have to think about them. Novel interfaces slow users down even if they have no problems otherwise. Just try switching rapidly between Mac, Windows and Linux sometimes. None of the interfaces has major problems per se but having to stop and think how to do something in each particular interface is a pain. You can create the same problem by using a good but non-standard interface within an app.
That is assuming of course that you can actually create a good interface. There are far, far more ways to make bad interfaces than there are to make good ones. Most interfaces fail even those designed by interface gods. The standardized interfaces are the result of tens of thousands of hours of testing and years of experience. You're unlikely to whip out something really new and useful your first time out.
If you try something novel I suggest you mock it up first and then test let people test it without giving them any instruction. You'd be surprised how complex it can get. We used to just make photoshop mockups and then ask test users what they thought each element did or which element they would choose to accomplish a particular task. We were surprised at how poorly our (the developers) perception of the interface overlapped with the perception of the users.
In sum, a novel interface is more likely to hurt your app than help it.
With regard to how to build an app like Facebook, check out Three20. In particular, the TTLauncherView is the class that implements the Springboard-like grid of icons.
3- You don't need to follow the AHIG. But be careful if you don't, because it's very easy to go wrong doing so. Users like to not have to learn anything new. They know the typical Apple software UI, so if you use it, users will know how to use your app as soon as they buy it. If you don't use it, it is important to make sure that the UI is exceedingly easy and intuitive, and looks good to an iPhone user's eyes (and fingers).
Are there any guidelines on pitfalls to avoid while developing iPhone applications?
Sure, thousands. The same is true for any software development. Unfortunately, the easiest way to enumerate them is to write them down on a sheet of paper while waiting for a friendly soul to release you from the one you just fell into.
However:
Don't try to reinvent the wheel. The iPhone API is very complete -- you just have to LOOK for the facility you need. Things are NOT always implemented the way you would expect. Read the guides, carefully. Look at the tutorials and analyze how they work. (Try changing a line here or there in the tutorial to see what difference the change makes.) The single biggest mistake I have made in 1 year of iPhone development is not trying hard enough to find the iPhone way of doing something.
Don't ignore memory management; master it early and often. Use the Object Allocation and Leaks tools in Instruments to check for memory leaks frequently. I'd recommend checking after you complete each feature or view; more often than that if you keep finding bugs. Eventually you may understand it so well you can stop doing this.
Don't just use the default build settings. Play around with them to understand what they do. Figure out certification and distribution. GET INTO THE DEVELOPER PROGRAM QUICKLY -- it can take a while to push through that pipeline. [ AND when you get that notification that you need to renew, get it on instantly -- there have been problems with that process. ]
Don't neglect to read the Human Interface Guidelines (HIG) carefully. If they say not to do something -- DON'T DO IT. Apple will reject applications that misuse their iconography.
Don't stint on marketing. Yes, the App Store puts your app in front of millions of people... In theory. But the odds of getting front-paged are slim. There are a lot of great apps on the App Store that haven't sold much because no one knows about them.
Don't rest on your laurels. If a new technology comes out, find out if it makes your job easier; if it does, take the time to learn it. Personal example: I'm just now trying to switch from SQLite-based data management to Core Data, because I was in a hurry at the time I started my most recent project; now I wish I had slowed down and thought about it.
Don't go into your design thinking (for example) "How do I implement my concept with a table view?" It's true that table views are natural for many informational and utility applications, but don't be constrained. Instead, think about what users will want to be able to do, how you can make it easier for them -- put things together that will be used together, etc. If you've never explored the concept of Use Cases, read up on them.
Don't hesitate to build composite views. Many of the questions I have seen here on Stack Overflow have to do with putting a toolbar at the top of a table, or having an image in the background of a text field. I understand the desire to do things the easy way, and as I state in #1 above, if there is an easy way, use it. But in many cases the solution is just to layer a couple of views with appropriate placement and transparency.
Think about what might be Apple-approved from the start.
App Rejected is one of several useful sites to help understand Apple's mostly undocumented standards. (One more.) (A previous question on app store rejection reasons.)
A few quick examples:
Using a UIWebView can get your app a 17+ rating.
Coding with an undocumented/private API = rejected
Version number < 1.0 might= rejected
Not enough feedback about network success/fail = rejected
Too much network use = rejected
Clearly limited free version vs full version = rejected
The word 'iPhone' in the app name = rejected
The above links contain many more examples, and more details about those examples.
Don't neglect the programming guides. While the documentation is quite extensive, the programming guides contains a veritable trove of useful tips and "insider" information that simply cannot be gleaned from reading method definitions. I spend just as much time reading the guides for a technology (say, Core Data) as I do actually implementing it.
Don't assume you know what a method does. If you have any degree of doubt about the functionality of a method, it is well worth your time to go look it up in the documentation to verify.
Wonderful examples from #Amagrammer above.
I would love to add that the first place to start is iPhone development is Photoshop. This is still the best advice I can give to anyone who is starting out. I now use OmniGraffle because it has awesome stencil templates.
What I find is that even for super simple app's, draw up your prototype and look for usability issues and work flow issues. It is 100x quicker to redraw your app than re-code it. I have fallen into this trap numerous times and now actually draw up some pretty simple functionality to see what it will look and feel like.
This advice will save you 10s maybe even 100s of hours in hopefully getting your app right first time and getting you to think through what the issues are. Throwing away code sucks and I have done it not because the code was bad but because it made the usability or solution worse. I think the best of us end up throwing code away and prototyping your design definitely will help in having to RTFM for something you did not have to build in the first place.
If you don't have an great designer, and can't do great design by yourself, then don't even start iPhone app development. This rule only applies if you want/need to make money with your apps.
I want to know what the risks are of using undocumented methods in the iPhone SDK.
I haven't had any issues thus far, but I am worried that doing something like this might screw up the app.
Any opinions/suggestions are greatly appreciated.
Apple has recently begun running apps through a static analyzer that will catch use of undocumented (i.e., private) method calls and automatically reject them (unless Steve Jobs takes pity on you; I wouldn't count on it, though).
That said, there's nothing stopping you from using them for private apps, although you should be careful with OS updates since private methods are not guaranteed to function the same (even if you get the same results, the implementation might have different side effects).
The risks of calling an undocumented method are the same in any application; since the method is not publicly known, it is more likely to change without warning in a future version of the library than in a public API.