Chapter 6 earthquake app the data feed is deprecated and will not work

neilw · August 21st, 2013, 10:55 AM

Hello,
The earthquake feed (on page 207/208) uses a data feed that is now deprecated and will be removed at some point. It is now replaced by a completely new format.

The first entry you get now is a deprecated message stating this and the earthquake code fails.

The quick fix is to change the first for loop on page 208 to start from 1:
for ( int i=1;i<n1.getLength();i++)

However, this will probably be removed at some point meaning the entire code for retrieving earthquake data will need to be changed. Which is quite a big thing as the earthquake app is fundamental to every chapter from 6 onwards.

Android23Geek · August 22nd, 2013, 05:09 PM

Mhh, that is very strange.. I know that there is no deprecated method that is called in that for loop that affects the 'entries'. I have worked from Chapter 6 to 10 with the same for loop.

What changed:

URL of the data feed on the web. It changed to "http://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/1.0_hour.atom". However USGS still uses the same atom entry structure. You still have to get feed entries by searching for parent nodes with tag <entry> and its children nodes, so there is no need to start initialize i at 1. If that is the only change in your code, you should see that you're missing the top entry in the data feed. Also, a tip, watch out for semantic errors, it's not 'n1' but 'nl'.

The machine-readable format for dating in this sentence

Code:

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd'T'hh:mm:ss'Z'");

in the code is incorrect. SimpleDateFormat on developer.android.com gives (a few) of the acceptable formats that SimpleDateFormat can work with. In the beginning, I didn't know what went wrong in the example but I delved into the source code of TimeZone and other Date classes and found that the format was wrong and that Z represents the TimeZone in the format. To make it human-readable, programmers must assign a value to Z.
To conform to the RFC about atom, date/ time representations must conform to an international standard thus UTC+0000 is used. I couldn't figure this out at first, so I made a few unnecessary, sloppy changes and didn't change them (again) when I fully understood what was incorrect in the code. I am sure there are method in SimpleDateFormat to do this!

Code:

String details = title.getFirstChild().getNodeValue();
                        String hostname = "http://earthquake.usgs.gov";
                        String linkString = hostname + link.getAttribute("href");

                        String point = g.getFirstChild().getNodeValue();
                        String dt = (when.getFirstChild().getNodeValue()).replaceFirst("Z", "+0000");

                        String format = "yyyy-MM-dd'T'HH:mm:ss.SSSZ";
                        SimpleDateFormat sdf = new SimpleDateFormat(format);
                        sdf.setTimeZone(TimeZone.getDefault());
                        Date qdate = new GregorianCalendar(0, 0, 0).getTime();
                        try {
                            qdate = sdf.parse(dt);
                        } catch (ParseException e) {
                            Log.d(TAG, "Date parsing exception.", e);
                        }

What's new is the code in bold.

The app splits child node <title> from parent node <entry> to get many information, i.e. location. It splits it with regular expression "," and uses the second element in the returned array. The code:
Code:
```
details = details.split(",")[1].trim();
```
It's perfectly fine but the runtime will throw a nullpointer exception whenever it doesn't find a "," such as in these cases

Quote:

<title>M 5.1 - Kuril Islands</title>

So I edited that line to the following:
Code:
```
(details.contains(",")){
                            details = details.split(",")[1].trim();
                        }else{
                            details = details.split("-")[1].trim();
                        }
```

Other than those mistakes in the code, I didn't come across anything else that might go wrong.

neilw · August 23rd, 2013, 06:56 AM

Hello,
I didn't say there were any deprecated methods, I said the earthquake feed url is deprecated.

Visit http://earthquake.usgs.gov/eqcenter/.../1day-M2.5.xml

and the first entry is:

Code:

<entry>
<id>urn:earthquake-usgs-gov:announcement-deprecated</id>
<title>Data Feed Deprecated</title>
<updated>2013-08-23T10:47:12Z</updated>
<link rel="alternate" type="text/html" href="http://earthquake.usgs.gov/earthquakes/catalogs/"/>
<summary>
<![CDATA[
<p style="font-weight:bold;color:#900;">This USGS data file has been deprecated.</p><p>To continue receiving updates for earthquake information you must switch to the <a href="http://earthquake.usgs.gov/earthquakes/feed/">new data format</a>.</p><p>In the future, data feeds will be updated and deprecated following our <a href="http://earthquake.usgs.gov/earthquakes/feed/policy.php">official deprecation policy</a>.</p>
]]>
</summary>
</entry>

Android23Geek · August 23rd, 2013, 07:48 AM

What I meant was that there is no need to change the code which parses nodes. The <entry> nodes are still the same.

It's not true that there is a new data feed entry structure.
It's logical and more efficient to change the data feed URL in the /res folder than to change the whole code.
The entire code for the Earthquake app does not need to be changed solely for this reason. The switch from RSS to Atom does not imply a new <entry> structure. It's actually the contrary.

The 'quick fix' is to change the data feed URL in /res/values/strings.xml to the new one I wrote in my previous reply.

neilw · August 23rd, 2013, 09:14 AM

Yes, that would do. Sorry you had a long post and I missed that bit.

When I visited the website (it is a bit cumbersome to navigate) all I found was a new format using JSON and a link to QuakeML which used a completely different xsd.

Either way, the errata needs updating :)