better-performance-with-libxml2-or-nsxmlparser-on-the-iphone
I've read that question and the answer about comparation of XML parser on iOS Apps Development. Well, actually i don't get what the point is.
My questions is, if I want to get and load huge XML data on my apps, larger than 200kb, what the best I could use..? is it NSXMLParser or libxml2..?
btw, I'm using Xcode 4.2 on iOS 5
I have used this resource in the past:
How To Choose The Best XML Parser for Your iPhone Project
The post summarizes the differences between a number of different XML parsers for iOS.
What's wrong with the accepted answer to that question?
Basically, #zPesk says :
libxml was found to be a bit faster but harder to use because it's in C instead of objective-c.
I don't think it matters that much as long as you use SAX parsing instead of DOM parsing - the last thing you want to do with an XML document that big is to load it into memory all at once!
Related
I need to present and open pdf documents in my app. I would like to avoid third part libraries, because of update reasons (and I couldn´t find anyone created in swift).
I have been looking at QLPreviewController, UIDocumentInteractionController and presenting the pdf in an UIWebView. All these alternatives works fine for just presenting the pdf but I can´t find any built in search. I want functionality like the iBooks app.
Any advice is appreciated!
You'll likely wont find any 3rd-party frameworks written in Swift yet, simply because as of Swift 2.2 it's not binary compatible yet, and any binary framework written in Swift would be very fragile to break with even a minor update of Xcode (and updates to the compiler, that is).
I'm working on the commercial available PSPDFKit SDK for both iOS and Android. We're actually using a lot of C++ internally since raw performance is very important and Objective-C (and for many things, also Swift) are not yet fast enough for certain tasks.
We did invest a lot of time in adopting the latest Objective-C features such as nullability and generics next to declarations such as noescape for block-based API to make our SDK great to consume from within Swift.
While a separate Swift-wrapper could offer additional convenience, you'll find it very simple to use, and we're always working to adopt more features that improve bridging as they come available - there are a few interesting things in the Swift 3 proposals.
If you do not want to go the framework route, you can use CGPDFScanner to base a custom text extraction engine on. You will need to read up on Character Map Parsing - Page 446ff and many other sections - extracting text from a PDF document is surprisingly difficult, and after much work you'll be left with individual glyph positions and need to approximate where words are and if the document uses spaces or if you need to synthesize your own to correctly extract text. It's something that just takes a lot of experimentation and approximation to get right.
This question already has answers here:
Choosing the right IOS XML parser [closed]
(5 answers)
Closed 9 years ago.
So I need to decide which iOS XML Parser to use for my new app. I will be downloading large documents from a website and parsing them into TableView cells as well as normal views. So it needs to be quick and easy to use.
Also, I would like the ability to parse the document, while downloading. So if I am scrolling in a tableView - I don't want to UI to lock up due to XML Parsing?
I guess I could use GDC to use overcome this?
I looked at TBXML and the libxml2 SAX XML parsers.
Any ideas?
Thanks guys.
p.S: I realise this is a duplicate question - However I wanted to see if TBXML was still used or now deprecated like the ASIHTTPRequest network API (Where AFnetworking is used now)
I would recommend to use TBXML as it takes lowest time comparatively to parse a document. To implement this surely you need multi-threading(GCD). You can implement this like lazy-loading concept, adding more rows as scroll reach to last.
How do I parse OFX in iOS? OFX is formatted in SGML, and I can't find any good parsers to use in C or Objective-C on iOS.
Try using libofx. It depends on OpenJADE for SGML but I've gotten them both to compile and work on iOS.
There are a few challenges here:
(1) OFX 1.x documents are SGML-based, while 2.x documents are XML-based, so if you know you will only deal with 2.x documents you could probably use an XML parser.
(2) If you do have to deal with 1.x documents, you'll have some code-lifting ahead of you. SGML in general and OFX 1.x in particular do not enforce close tags for simple types. That means you'll see things like:
<INVACCTFROM>
<BROKERID>Fidelity Investments
<ACCTID>FidRoth
</INVACCTFROM>
Parsing this kind of thing will be tricky unless you provide your own schema logic, or pre-process the data to a more "valid" format. An example of the latter, while not in C/Obj-C/C++, is given on Scott Hanselman's blog.
Good resources on OFX can be found here.
I'm developing an iPhone application (well, I'm migrating a Windows Phone 7.1 to iPhone), and I have some questions:
Previously, I've asked this question, Storing data in XML or SQL?, when I was developing a Windows Phone 7.1 app. And now I have the same question, but in this case it is about iPhone.
I've found in iOS development, that XML is not as easy to read as in Windows Phone. In this question, Reading XML attributes and text, you can find what method I'm using to read a XML file.
I'm sure, I don't need to use a database to store only 22 items, but, is there any other way to store that 22 items? Or, maybe, you know an easy way to read XML.
I need something like this:
<?xml version="1.0" encoding="utf-8" ?>
<cards>
<card id ="0">
<name lang="en">Mad</name>
<description lang="en">This...</description>
</card>
...
</cards>
This data will be readonly: user will never change it. And it will be as file bundled with my app.
You haven't said how you are using this data.
Are you talking about simply bundling data with your application? If so, the simplest way of doing so is to use a property list (plist). Both NSArray and NSDictionary have convenience methods to pull arrays and dictionaries straight out of plists, and there is a graphical editor build into Xcode.
Are you loading this data over a web service? Do you have to support multiple platforms? If this is the case, then JSON would be a better option. JSON support was only included in iOS 5, but if you need to support earlier versions, JSONKit will handle this for you.
Do you have to update and run queries over the data? Core Data is a better option for this kind of thing. You can preload it with the contents of a plist or JSON file when the user first runs the application.
There are a lot of different options, and unless you provide more detail, it's difficult to give you good advice.
XML Parsing in Objective C isn't that challenging. Please see this example on Introduction to Tree-Based XML Programming Guide for Cocoa http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/NSXML_Concepts/NSXML.html#//apple_ref/doc/uid/TP40001263-SW1
I'm going ahead and using Core Data in my project even though I don't really have all that much to store. It's really not all that difficult, especially since you can choose Core Data as an option in a couple of the Apple templates. Inside the iOS developer library they also have a pretty good basic tutorial.
Core Data Starting Point
I guess the main difference between whether I would use the Plist or Core Data would be whether I expect my data to be static from compile time or to be updated by the user.
Plist files
Documentation: http://developer.apple.com/library/ios/#documentation/general/Reference/InfoPlistKeyReference/Articles/AboutInformationPropertyListFiles.html
Example: http://www.ifans.com/forums/showthread.php?t=64679
I'm looking to port my working Android XML parser to Blackberry, but the latter's Java feature set isn't as rich? I didn't want to have to write two parsers.
The following code yields "The method getXMLReader() is undefined for the type SAXParser":
SAXParserFactory spf = SAXParserFactory.newInstance();
SAXParser sp = spf.newSAXParser();
XMLReader xr = sp.getXMLReader();
Am I just out of luck here?
It's true I am trying to use org.xml.sax. I've read all the XML parsing discussions I can find out there. I wonder now if I can do this? Should I be using org.kxml2 instead because org.xml.sax makes no sense in BlackBerry land?
Thanks for any advice!
Russ
You don't need to use the getXmlReader() method.
Now that you have your SAXParser use it to parse a document or stream.
SaxParserFactory spf = SaxParerFacter.newInstance();
SAXParser parser = spf.newSAXParser();
Open your stream or file and call and assign it to a variable. Let's call ours input.
parser.parse(input, handler)
The handler file will implement all of the call backs to handle the events the parser encounters.
I found this explanation of SAX to be quite helpful.
I'll answer this though I suspect there are others who know better.
My assessment of BlackBerry is that it's very poor in its API set. So, the SAX XML parser isn't available as it is on Android. Okay, that's cool. It's older and from a "smaller" time.
Worse though, it appears very challenging even to add a third-party library to a BlackBerry application. I followed various posts out there and failed to incorporate my own "third-party" JAR convincingly into a BlackBerry project despite the collective wisdom of a number of web pages on the topic.
I was thinking then of writing my own parsing engine to replace SAXParser.parse(). How hard could it be since my expectations for it are childishly simple?
Very hard indeed since it appears that the JavaME support for java.lang.Class is impoverished as well; it doesn't support the important reflection methods such as getDeclaredMethods() for use in creating the engine (into which I naturally wanted to plug my existing XML parser-handler).
Alas, this makes me wonder just what BlackBerry apps out there are able to do? I'm probably giving this world short shrift, but a couple of days were sufficient for me to go from zero to parsing XML texts off the web on Android, so I expected a very easy time of it here too.
Please feel free to shred my answer. If you can and do, especially if you add a real one, it will doubtless greatly benefit other folk new to BlackBerry development including me later when I come back to the problem (so that I can avoid brute-force stringing through the XML stream instead of cleanly parsing it).