Acceptance criteria:
Given that I am viewing the article history
When the server returns (null) or empty values for change counts
Then I should see "0" in the article history view

JMinor - I think the server returning null isn't the issue here - the issue is we're only showing the last 50 or so changes, so the last change can't be compared against a previous one to see the size change. The fix would be to implement continuous scrolling so when you get to the bottom of the most recent set of 50 or so changes, we would would request the previous 50, and so on, until you scroll all the way back to the first change.

thanks for the clarification @Mhurd. Lets merge this fix in and work on "infinite scrolling" of the history under a separate task.

@JMinor Hi. @Mhurd and I ran into a couple different scenarios.

Some testing notes -

there are 3 known cases

1. all possible revisions downloaded. do not remove any revisions// EXAMPLE: "enwiki > Bumba airport"
2. only 51 of n revisions have been downloaded. The earliest day we have revisions for has multiple revisions. in this case, remove the earliest revision on the earliest day, but leave the day in the table with the rest of its revisions// EXAMPLE: "enwiki > Gregor MacGregor"
3. only 51 of n revisions have been downloaded. The earliest day we have revisions for has only one revision. in this case, remove the day from the revisions days array// EXAMPLE: "enwiki > Nicole, Erica and Jaclyn Dahm"

Testing on iOS 9.3.1 the app 5.0.3 (809). 0 now appears in place of Null, so this is fixed - I checked the "Economy of Virginia" in addition to "Nicole, Erica and Jacyln Dahm."