Android SampleNetworking

很经典的 android 访问网络数据（这里是 RSS）的例子，按照 OOP 的思想来实现。 来自：http://www.therealjoshua.com/2012/10/android-architecture-structuring-network-calls-part-3/ Android Architecture: Structuring Network Calls, Part 3 October 7th, 2012 · 10 Comments · Android, OOP So far we’ve talked about some theory and OOP design principles and making our request asynchronous. In this post we’re going to discuss what was going on inside of the AsyncTask to make the network request and parse the data. Much like most of my posts, I won’t be discussing how to make a network request or how to parse xml or json. Instead, we’ll keep it broader and continue to talk about the architecture. Making the call: Let’s check out FetchRssHeadlinesTask. @Override protected List<RssSnipetVo> doNetworkAction() throws IOException, SAXException { command = new ReadRssCommand(rssFeed); return command.execute(); } You can see here that our class delegates the network request to another object. Let’s check out ReadRssCommand. public ReadRssCommand(String rssFeed) { this.rssFeed = rssFeed; } public List<RssSnipetVo> execute() throws IOException, SAXException { Uri.Builder builder = Uri.parse(rssFeed).buildUpon(); InputStream inStream = requestStream(builder.toString()); Document doc = streamToXml(inStream); List<RssSnipetVo> items = RssParser.parseItems(doc); return items; } Skeptic: Wait wait wait! So FetchRssHeadlinesTask delegates to ReadRssCommand which delegates to RssParser? You have 3 classes for 6 actual lines of code? That’s absurd. Yes that’s correct…well not the absurd part. There’s 2 OOP principles going on here, the Single Responsibility Principle and DRY (Don’t Repeat Yourself). The Single Responsibility Principle states that a class should only do one thing (and do it well. This also means it would only have 1 reason to change.) Let’s look at the responsibilities of each class. FetchRssHeadlinesTask - makes the request asynchronous. It has the option to perform business logic on the returned results. ReadRssCommand – is used to make the actual http request to the server. RssParser – is used to parse the results returned from the server into Data Objects. If we look at the responsibilities of the classes it’s clear where to break them up and delegate. Line numbers are not an indication of this, responsibilities are. Just a general hint: if you have to use the word “and” when describing what your class does, perhaps you should consider if it violates the Single Responsibility Principle. Let’s consider DRY for a moment now. ReadRssCommand calls some API (notice we don’t even care what url or api it calls. How and what it calls is hidden.) and that returns back an XML result set. Suppose we were to create a SearchRssCommand which took in a search term. The results back from that query would have the same structure as the ReadRssCommand. As such we can reuse the RssParser. If we had put that parsing code in with the network request we’d have to duplicate that same parsing logic in our SearchRssCommand. We would be repeating ourselves. Why is repeating ourselves such a bad idea? Duplicate code is hard to maintain. What happens when I find a bug in the parsing code or perhaps a new node is added to the XML? We’d have to go through all the different places and make change. By having a single point for parsing the XML results, it makes code easier to maintain and it becomes reusable. I want to point out to make sure it’s clear, it doesn’t matter if we’re using XML or JSON or POST or GET or PUT or whatever. Notice the internals are all encapsulated. It’s all hidden. If we were using JSON instead of XML, I’d still have an RssParser. It would just be parsing JSON instead of XML and the internals of that would still be hidden. If we were using POST instead of GET to fetch the RSS results, it wouldn’t matter. Our structure stays consistent throughout it all. As a quick summary, AsynTask command is used for business logic. The AsynTask delegates the URL request to another class whose responsibility it is to call the appropriate API with the correct parameters. The results of that API are passed into some type of parser (a custom parser or one that uses reflection or whatever) to translate it into data objects. From there the results are returned to the original requesting client. The specifics of what happens in between aren’t so important.