Is the built-in dictionary in iBooks etc available to developers? If so how would I go about using it?
It's not available to developers. You could use an open source dictionary like this one from Project Gutenberg, but it might take substantial munging to make it presentable.
Unfortunately, I believe the system dictionary is only available through a private API.
Personal conjecture: It's one of the many "features" locked away by Apple to separate the iBooks app from 3rd party e-book reader competition. However, at the rate Apple is going, I would expect the API to become public at some point in the next few years.
I think that it might be a copyright issue. I had the same problem about a year ago and not much has changed since then.
My solution was to embed an offline dictionary inside my app and I later turned it into a static library that others can use (for a small fee). If you're looking for a full-blown dictionary you can check it out at www.lexicontext.com
If you just need a spell checker, you can also use UITextChecker
Related
I know that TTT(Three20)framework provides quite a lot of customization of default iOS elements, however, it appears that the framework has not been updated in over a year, and a lot of tutorials on the framework I see are dated 2011 or so.
Is there some newer, better framework that industry apps are using? Or is Three20 still relevant?
As you correctly stated, Three20 is no longer used (it was too heavy, and you never got to use it entirely anyways).
Nowadays, I think people tend to follow a "componentization" (sorry for the lingo) approach, which means you just put in your project stuff that you know you'll be using that can be easily added/removed. This way, if you change your mind about using a certain component, you can discard it at any time and replace it with another one almost in a couple of minutes.
To accomplish this, I'd have a look to cocoacontrols and cocoapods.
The first one to browse across all sorts of visual and non-visual components, 3rd party libraries and so on. The second one to actually import those into your project with minimal hassle.
This way your project will only include classes that will be used, and won't be that difficult to set up.
If you're looking for a magic toolbox that does it all, I'm afraid it doesn't exist (and I don't think it ever did).
Ok guys, so im new to iPhone development, so apologies if this is a silly question, but before i actually create my app i want to know if this is possible, and if Apple will reject this.
(Note this is all theoretical)
So i'd have a API (.NET) that runs on a cloud server somewhere and can return HTML/JSON/XML.
I'll have a website that can access this API and allow customers to do some stuff (but this is not important for this question).
I would then like my iPhone app to make a call to this API which would return JSON data. So my iPhone app might make a call to http://myapp/Foos which would return a JSON string of Foo objects. The iPhone app would then parse this JSON and do some funky stuff with it.
So, that's the background, now the questions:
Is this possible? (that is, call an external cloud API over HTTP, parse JSON response?)
What are the chances of Apple rejecting this application (because it would be calling a non-Apple API)
Are there any limitations (security, libraries, etc) on the iPhone/Objective-C/Cocoa that might hinder this solution? In regards to Security - can you freely make a HTTP (or even HTTPS call) from inside an iPhone app, and parse the response? In regards to libraries - is there sufficient support in Objective-C/Cocoa to accomplish this?
On this website, they seem to be doing exactly what im asking.
Thoughts, suggestions, links would be greatly appreciated...
Yes. It is possible. There are quite a few apps that do similar things.
Slim to none. Apple hinders what languages and libraries you can develop in and run on the phone. They won't limit you based on what external data you pull in to your app.
There shouldn't be any worries here either. You shouldn't run in to security concerns and there are plenty of libraries that you should be able to utilize to make your life much easier.
Good luck!
Yes it's certainly possible, and there are json parsers available already. Secondly, based on what you just described, should the application not break any rules outside of the scope of this question, then there is no reason I can see Apple rejecting it (except perhaps content, ie., don't display any porn or the like :)) ... Finally, you haven't properly described your application to fully answer #3, and I don't dare guess at what you meant, since it may be just a waste of your time. Feel free to expand on your #3 in comments, I'll answer there.
Edit: With regard to your edit of #3 above, yeah you won't have an issue here at all either.
I haven't found a comprehensive list of the steps that are required to use a private API from the iPhone Library.
In particular, I would like to know how to get header files, if they are even required, how to get it to compile (when I simply add the header, it complains that the functions aren't defined), and what resources one can use to learn about private APIs (e.g. from other user's experiences, such as http://iphonedevwiki.net/ which has a few).
I've read in other places that people recommend using class-dump to get the headers. Are there any alternative methods? I've noticed that there are some repositories of iPhone Private SDKs, what are the most up to date resources you would recommend?
Most of the previous questions about documentation of private APIs, have all linked to Erica Sadun's website, which doesn't seem to have documentation anymore (all the links on the left are crossed out).
Please save the comments about not using private API's... I know of the biggest risks:
App will get rejected by Apple.
App will break in future updates to the OS.
I'm talking about legitimate uses, such as:
Private application use (e.g. for unit testing, or messing around to see what's possible)
Objective-C has enough information in the compiled binary to almost completely reconstruct the headers. The only things missing are argument names, which can often be approximated from the type or method prototype, and some structure and enum definitions. That is why programs like class-dump are the best way to get the headers. They are comprehensive, including every method whether it was in the real header or not, up to date and do not need to be distributed. The other way to get headers is to look in the public version of the same framework, for example WebKit is only private on the iPhone and is otherwise well documented.
If you are interested in things besides Objective-C you pretty much have to do it the old fashioned way, slogging through disassembly to guess function arguments. Once you get a few symbols, search for them and maybe you will find a header someone else has posted. otool is a good place to start.
If you include the headers, be it for Objective-C or C, you must also include the frameworks or libraries the headers declare methods for, just like any other headers. Most of the Objective-C stuff is in a PrivateFrameworks folder right next to the regular Frameworks folder. You can look in the usr/lib folder to find libraries.
Be aware that there are lots of differences between the simulator and the device, so make sure you build headers from the real device. There are also some of methods that you will not have permission to run as a sandboxed app.
I received the following mail form Apple, considering my application:
Thank you for submitting your update to Νομοθεσία to the App Store. During our review of your application we found it is using private APIs, which is in violation of the iPhone Developer Program License Agreement section 3.3.1; "3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs." While your application has not been rejected, it would be appropriate to resolve this issue in your next update.
The following non-public APIs are included in your application:
u_isspace
ubrk_close
ubrk_current
ubrk_first
ubrk_next
ubrk_open
If you have defined methods in your source code with the same names as the above mentioned APIs, we suggest altering your method names so that they no longer collide with Apple's private APIs to avoid your application being flagged with future submissions.
Please resolve this issue in your next update to Νομοθεσία.
Sincerely,
iPhone App Review Team
The functions mentioned in this mail are used in the ICU library (International Components for Unicode).
Although my app is not rejected at this point, I don't feel very secure for the future of my app, because it relies heavily on the Unicode protocol and on this components in particular.
Another thing is that I do not call these functions directly, but they are called by a custom 'sqlite' build (with FTS3 extensions enabled).
Am I missing something here?
Any suggestions?
I would recommend not publicly venting about the issue (that will only hurt you in the long run), but responding politely to the application review email address you were given, explaining that you are using a custom SQLite build which references the ICU framework. Given that this is a standard third-party framework, I would argue that these are not Apple's private APIs that you are using. It may be that they were simply overzealous in the inclusion of symbols in their scanning software.
If you are unable to convince them otherwise, you might contemplate switching from SQLite with FTS3 to something like Aaron Hillegass' BNRPersistence, which just added fast full-text searching.
If they have trouble with linking to the system ICU, why not simply import the ICU source code into your project?
Hmmm...it is possible that Apple also uses ICU components. The best response would be to politely explain what's going on, and hopefully things should sort out okay.
What are some of the less-known and interesting public APIs and frameworks that I can use for iPhone? In OS 3.0 they're supposed to be 1000 new APIs more than in 2.2, so which one of these are the most interesting and not so well-known?
There is the screen capture function that the newly approved streaming video iPhone apps are using. Though, normally its use would be prohibited (private API policy), Apple changed its stance on this one in particular.
CGImageRef UIGetScreenImage();
Link to devforums.apple.com
Although PDFKit is not available on iPhone, much of the Core Graphics level CGPDF stuff is. You can draw PDFs with a CGPDFContext, or parse existing PDFs with a CGPDFDocument.
There is the UIDataDetectors API. Not much documentation. But you asked for obscure ;-)
There is an API for the copy, cut and paste too. Not seen too many apps use this yet.
To be honest, I've tinkered with most of the new APIs. While they state a 1000 new APIs it's more like they've added 1000 new methods distributed across fewer what we'd call APIs.
There is the ExternalAccessory API. Not widely used as you need, well, external accessories. Maybe you can have some fun with this API and video goggles.
All the big ones I'm sure you already know about. CoreData is the biggest one for me. But the highlight for me in 3.0 were the huge number of small changes:
[UIApplication canOpenURL:] is great, as it means that you can only offer options if certain applications are loaded
Methods such as [UIViewController willAnimateRotationToInterfaceOrientation:duration:] make certain animations significantly easier
It's easier to work with toolbars (now part of UIViewController)
[UIViewController viewDidUnload] make certain memory management tasks simpler
Changes to table views and cells... it's not so much a single method as how they all interact that makes it much easier to work with than in OS 2.x
The copy/paste functionality is nice, though not terribly well documented
Since my main app still needs to build for OS 2.x I've not used all of these in anger.