Android bundles three different kinds of parser APIs(DOM, SAX, and XmlPull).
whether they need to load the entire XML document into memory up front. Parsers based on the Document Object Model (DOM) do that: they parse XML documents into a tree structure, which can then be traversed in-memory to read its contents.
Using DOM alone isn’t much of a benefit because its API is clunky and it’s expensive to always read everything into memory even if you don’t need to. Hence, DOM parsers are, in most cases, not the optimal choice to parse XML on Android.
These parsers are stream-based, which means they process an XML document while still reading it from the data source (the Web or a disk). This implies that you do not have random access to the XML tree as with DOM because no internal representation of the
document is being maintained. Stream parsers can be further distinguished from each other. There are push parsers that, while streaming the document, will call back to your application when encountering a new element. SAX parsers, discussed in this technique,
fall into this class. Then there are pull parsers, which are more like iterators or cursors: here the client must explicitly ask for the next element to be retrieved (XmlPull parsers do that, and will be discussed in the next technique).
SAX is an event-driven pushparser specification and operates at a low level, so it doesn’t bring any unnecessary overhead.
You’re looking for a lightweight way to parse XML documents without having to keep them in-memory at all times. You specifically want a parser that calls back to your application whenever an element is encountered in the XML document (push).
using the SAX (Simple API for XML) model, is event-driven.
A convenient way is to inherit from Default-Handler and only override those parts of its interface that we need.
In order to parse this document using SAX, we must react to the handler events when an XML element we’re interested in is encountered. In general, the SAX events you want to catch are usually related to document boundaries, element boundaries, and simple
text nodes.
The usual approach is to do setup work in startDocument, such as creating an empty object that will hold the data parsed from the document (a Movie object in our
case), then collect text content in characters (such as a movie title) and use the text content in endElement to populate the respective field of the object.
public class SAXMovieParser extends DefaultHandler {
private Movie movie;
private StringBuilder elementText;
public Movie getMovie(){
return movie;
}
public void startDocument() throws SAXException{
elementText=new StringBuilder();
}
public void startElement(String uri,String localName,String qName,Attributes attributes)
throws SAXException{
if("movie".equals(localName))
movie=new Movie();
}
public void endElement(String uri,String localName,String qName)
throws SAXException{
if("name".equals(localName))
movie.setTitle(elementText.toString().trim());
else if("rating".equals(localName))
movie.setRating(elementText.toString().trim());
elementText.setLength(0);
}
//set current value
//be called whenever text that’s not a structural element
public void characters(char[] ch,int start,int length)throws SAXException{
elementText.append(ch,start,length);
}
//helper method to parse Stream
public static Movie parseMovie(InputStream xml){
SAXMovieParser parser=new SAXMovieParser();
Xml.parse(xml, Encoding.UTF_8,parser);
return parser.getMovie();
}
}
you have no idea which it is—the movie name or the category name. This means that for more complex documents with a medium to high depth, you’ll have to maintain state in your handler about where you are while the document is being parsed. You
could set boolean flags to remember when you’re inside a category element. This can get tedious and painful to manage. Another criticism leveled at SAX parsers is that you always receive callbacks about any kind of event—even if you’re not interested. You
have to implement all callbacks