To compensate the ads are gone for the time being.
Just to keep you up to date : As hinted to in my last post, Back To The Drawing Board, I went back to use the existing code base. I am therefore abandoning my previous performance work, but I will keep the experiences I made and will apply some of my new insights over the next releases.
With NewsRob 1.7 I introduced Q-Reports – a bug reporting feature – and it proved tremendously helpful to me.
I answered each and every single bug report and it proved to be a great and pleasant experience to communicate with you guys. It was way better than what I expected. But well, my expectation was set by the Android Market comments ;-)
In the last three weeks – since the release of NewsRob 1.7 – I got around 100 bug reports for about half a dozen bugs. I will continue to answer each bug report, so that the reports keep me honest on really chasing the bugs down, if only to have fewer bug reports to answer to ;-)
There were so many mails that it doesn't make any sense to mention everybody by name. but in any case, thank you very much for your participation.
Most of those bugs are fixed now. Two are really hard to track down though and I have not been able to reproduce them. But even for the latter I implemented some changes that might or might not solve the problems. I need your bug reports to prove that the latter are gone or not.
This release's duration was a bit long and especially people that were reporting bugs in the last week were only getting a response saying that the bug is fixed already. I will keep an eye on that and if this turns out to be a frequent occurrence I will make NewsRob check against a list of know bugs to lift the burden of reporting known bugs from your shoulders.
- New default for storage provider: SD card (most of the time)
Some of you reported a bug that happened when the phone memory was low. The subject line of your bug report mail contained "NullPointerException: null" and the body contained: "CacheManager.java:391".
This bug was actually happening not in the NewsRob code, but in the framework code. JBQ, a Google engineer, took care of the problem quickly, so that it should be fixed in an upcoming release (maybe Cupcake?). If you're interested in the details, you'll find them here and here.
No data is harmed; so from this release on the bug is silently swallowed.
However there is an underlying problem. The lack of memory was because NewsRob was configured to store the downloaded articles in the phone memory, not on the SD card.
There was likely something else eating the phone memory too though as NewsRob stops downloading new stuff when a certain threshold is reached.
But anyway storing into phone memory was the NewsRob default, because it is the simplest approach. On the other hand: SD cards have a higher capacity, but when using an SD card it must be accessible.
It is not accessible when the SD card is not inserted (doh!), when the SD card is in read only mode or when the "Use for USB storage" is activated for the SD card.
The latter means that an Android app cannot share the SD card with the desktop computer you plug it into. This seems to be a limitation of the FAT32 file system, but don't take my word for it.
As you can see using the SD card is interesting as it usually has a higher capacity, but is a bit more complicated.
As I got at least 20 bug reports for this bug only, from now on the story goes like this: When the user first launches NewsRob the default is set to SD card, if an SD card is present and writable, otherwise the default is still the phone memory.
Also when opening NewsRob and the SD card is not accessible even though NewsRob is configured to use it, NewsRob will complain about it. See screenshot below.
"Refresh" and "Clear Cache" will be disabled until the SD card is accessible again or you change the Storage Provider to SD card in the settings.
That looks like the most sensible approach to me. - Display of online web content
Marcus Schmidke suggested to show the Website inside NewsRob when the content has not been downloaded yet, but the user clicked on the phone symbol as if to view the downloaded Website.
That was a small change to implement, but I experienced over the last week that this is quite handy. - Bug "IllegalStateException: Oops. moveToPosition shouldn't fail."
This bug happened when the Show Article screen was displaying an article that then gets removed by a running synchronization. When trying to navigate to the next or previous article this bug occurred.
Tom Kerswill helped me to track down and reproduce the problem. As a result the bug is gone now. Thanks Tom. - Bug "CursorIndexOutOfBoundsException: Index n requested, with a size of n" and
Bug "IllegalStateException: get field slot from row 0 col 0 failed"
Those bugs I have not been able to reproduce, but I have a suspicion that they both are caused by a concurrency issue. I changed the implementation accordingly.
As I haven't been able to reproduce it with the old version I can't verify if it is gone in the new version. So send me those bug reports if you get them.
Don't be afraid to send me the bug report every time it occurs. This way I know how urgent it is to fix the problem. 20 bug reports from 20 people is bad, but not as bad as 5 reports for the same bug from the same person over the cause of two days (Hi Michelle!).
Even better than frequent bug reports are bug reports with instructions on how to reproduce the bug. If I can reproduce it there is a 99% change that I can fix it. - Bug "IllegalStateException: Entry was null in bindView. cursor.getString(0) = tag:google.com,2005:reader/item/xyz cursor.getPosition()=n
This one is hot off the press. Version 1.8.0 had a concurrency issue that fortunately was found by Aaron Chancey literally minutes after the release. Together we were able to reproduce the concurrency issue very quickly and he also found that I yanked one permission too much when disabling the ads. Aaron, thanks for your swift support.
Unfortunately fixing this concurrency issue was not a small thing. So I might have introduced more errors, but I hope not. On the sunny side, look at the scroll performance of the Article List. To fix the bug I adapted code that I developed during the performance project.
I will now work on making the download method configurable. In the future you should be able to define on a per-feed-basis if it should be downloaded as feed content, downloaded as feed content + the website, or not downloaded.
Update: There was also a problem for first-time-users when NewsRob was started the first time on a fresh SD card. This is fixed in 1.8.4. This bug was reported by y2kcong. Thanks for helping with the testing.
Glad to help out, I love finding problems with other people's work :P
ReplyDeleteAll jokes aside, the reader is incredible, and more reliable than MyNewsroom was on my Sidekick, part of the reason I came to the G1
Bug "CursorIndexOutOfBoundsException: Index n requested, with a size of n" and
ReplyDeleteBug "IllegalStateException: get field slot from row 0 col 0 failed"
You are right - this is probably a concurrency exception. I just had the same problem on an app I am developing. The problem can be solved by accessing you database via a singleton.
here is a little of my code:
============Calling code========
DatabaseHelper dbHelper = DatabaseHelper.getInstance(context);
===========DatabaseHelper=============
public static DatabaseHelper getInstance(Context context) {
if (instance == null) {
instance = new DatabaseHelper(context);
}
return instance;
}
Hey Tim,
ReplyDeletethanks for the help, but in this particular case I don't think it can be the cause, as I already make sure that I just have a single instance of the DBHelper.
The concurrency happens someplace else. On one end I am putting something into the database when at the same time I am displaying the contents of a cursor and also change the status of some selected rows which would change the cursor also.
But thanks anyway (really).
Mariano