NewsRob 2.0 is just another release. Nothing earth shattering, completely backward compatible.
Sunday, April 26, 2009
NewsRob 2.0 is just another release. Nothing earth shattering, completely backward compatible.
Wednesday, April 22, 2009
Saturday, April 18, 2009
What's new in NewsRob 1.9?
More Control Of Downloading And Displaying
The biggest feature in the new version allows for more fine grained control of the download process to reduce download times and storage consumption to the necessary minimum.
On a related note it is now possible to define in which mode an article should be opened ("Feed", "Web"). That should make navigation quicker.
More information here.
As suggested by Eric Sinclair and Marcus Schmidtke I reworked "Share By Mail" and made it more general. It is now called "Share Link" and looks like this:
The mentioned applications are just exemplary. The actual applications on your phone that participate in sharing might be different (YMMV).
Rescheduling background synchronization after upgrade
Marcus also reported that he needs to set the synchronization schedule again after each update.
The problem here is that an upgrade on Android is an uninstall followed by an install. And during the uninstall the scheduled alarms get uninstalled also – which makes sense – leaving the phone in a pristine state. Unfortunately the app doesn't get notified during the install process to (re-)establish any alarms.
So for NewsRob that meant that the alarm was only re-scheduled when you visited the preference screen or when the phone was booted again.
From this version on every time NewsRob is launched by the user it checks if auto-sync is enabled (the default) and if that is the case it schedules the next sync, if there isn't a schedule already.
Still, if you don't launch NewsRob after an upgrade the auto synchronization will not resume until the next reboot.
Clearing Cache On Install Now Features A Progress Dialog
Another problem stemming from the above issue of not being notified when the app is installed or uninstalled is that NewsRob isn't able to properly clean up after itself. In particular the stored articles on the SD card are not removed during an uninstall. You can, of course, push "Clear Cache" before uninstalling it.
This led to a problem where you installed NewsRob, uninstalled it and re-installed it at some later point. As the NewsRob database gots unistalled the downloaded files don't mean much anymore as the "index" is missing. So every time NewsRob instantiates a storage provider or switches it (phone memory <-> SD card) it cleans the old and new storage provider.
So during a new install where NewsRob finds old files on the SD card, they get removed first. Unfortunately I forgot to put a progress monitor around it which lead to the dreaded "Application Not Responding" as well as to other weird GUI behavior. This has been fixed now.
Ejecting SD Card During Synchronization Now Longer Leads To A Forced Close: NullPointerException
When ejecting the SD card in the middle of the "Reduce To Capacity" phase – NewsRob deletes the articles that are over the configured maximum number of articles – lead to a forced close with a NullPointerException.
Hanaguro reported this problem and helped me over the course of many emails, tests and the use of Log Collector (Now that's a great Android Market rating!) to track the problem down. It is now fixed. Many thanks Hanaguro.
New Auto-Sync Mode: "WiFi-Only"
With another user I exchanged a couple of mails on using NewsRob without a flat rate data plan. As a result there is a new option that not only for the content download, but also the auto-sync, you can now specify a "WiFi only" option.
But, please be careful. NewsRob checks occasionally if WiFi is no longer available, e.g. between article downloads, between chunks of new articles, but this is very coarse grained. NewsRob is not cancelling the downloading of a file in the middle of the download.
The upload-only synchronization that kicks in 5 minutes after the last status change, now is also dependent on the auto-sync setting.
I'd also like to add, at least in my personal experience, the G1 loves to hop on and off WiFi.
Having said that, I want to make sure you guys understand that NewsRob is a bandwidth hog, no matter which way you slice the issue. If you don't have a flat rate, please don't use NewsRob. And if you must, make sure that you go into "offline" mode by changing the APN settings automatically or whatever.
Last and least new/changed feature: The article's context menu – as accessible by a long press on the article header on the Show Article Screen or on a row in the Article List – is now also the option menu (hardkey "menu") on the Show Article screen.
And as always many more little details.
Like with the next release - this one was tested, but there will likely be bugs small and possibly big that you will find and report. During the first three days of the release I will upload new versions frequently. So if you don't want to help testing the app and bugs and upgrades make you throw up, please wait another three days before taking the upgrade.
With this release I now have implemented Feeds as entities of their own right, as opposed to just being the feed title as before. They are used to set the download and display references. In one of the next two releases I plan to surface them, so that they are one more level to browse through the articles.
Also planned for one of the next two releases is the basic integration of Locale.
For the releases thereafter I currently plan on fixing whatever bugs come my way, documentation (website, videos) and vacation.
And I am thinking about stopping those release notes. The note from yesterday and this take together almost 6 hours to prepare. This time I am not working on features or fixing bugs. Worst of all, when reading the mails I get, I can't fight the feeling that the release notes are read only by a minority. And the same is true for the web site. Please leave a comment if you read this ;-) "Read it" would be fine, but more verbose comments would be acceptable too ;-)
Maybe videos that are linked directly in the app are better?!
Friday, April 17, 2009
More Download Control
The new version brings you more fine grained control over what is downloaded and how long it takes.
I often hear that NewsRob is slow and it takes very long to make the web pages available offline.
NewsRob downloads the feed content and the web page. Let's first have a look at the feed content. The feed content's text is already part of the feed that is synced with Google Reader. So only the images that are referenced in the text need to be downloaded – so that you can see them more quickly when browsing through your articles, or that you can see them at all when you are offline.
This is a relative straight forward process and doesn't take all that long. And in many cases that is all that is needed. So from now on you can select a download option called "feed content" to stop after that.
There are lots of web pages – in particular the commercial websites that really want you to see the ads on their webpage to make their business model work – that only provide summaries in the feed. That's called a partial feed as opposed to a full feed that contains the full text and all the images.
When you encounter those partial feeds in Google Reader you'll see only a line or two describing the content in the article's body. To read the actual article you have to click on the title to open up the web page as a new tab/window in your browser. That is slightly annoying when you are at your desktop, but really annoying when on Android. It just takes very long to open a new browser window or even launch the browser.
(Btw. If any of you know of a Mac or browser based reader application that does what NewsRob does, please let me know.)
So to take care of that NewsRob let's you display the web page inside NewsRob.
That is possible when the content is downloaded as well as when the content is not downloaded (yet). In the latter case NewsRob just acts as an ordinary browser and downloads the page on the fly. This also works when you use the download options "headers only" and "feed content".
The web page that is referenced in the article is called "alternate content".
To offer this alternate content offline, NewsRob downloads the html page and goes through it looking for images. When it finds a reference to an image it downloads that image, saves it to the SD card/phone memory and changes the reference in the html page to point to the local file.
Then it repeats the process for all the stylesheets. After the stylesheets are downloaded, they are processed the same way – that is NewsRob looks for image references, downloads the images, changes the stylesheet, etc.
I hope you can imagine that this takes a bit of time. Please also consider that the web pages are not meant originally to be downloaded to a mobile phone. A typical commercial web page has 100-300 images embedded. Those images are usually very small though: these are rounded-corners, dividers, navigation elements and whatever else the history of the internet brought with it.
So if you don't need the web page – because the feed you're interested in is a full feed – use the "feed content" option; otherwise use the "feed content + web page" option.
Why a "feed content + web page" option, not a "web page" only option? Doesn't this take up more space and time than necessary?
The web page and the feed content share the same content and NewsRob preserves that. So if an image is downloaded for the feed content, the same instance of the images is also used in the web page or vice versa. As a consequence the feed content comes "for free".
The "feed content + web page" option was the default – and only option – in NewsRob until now.
The new default is "feed content".
And there is a third choice now "headers only"; this means that no feed content is downloaded.
This is basically the functionality you have when you use the mobile version of Google Reader.
You can still see the feed content, but the images are downloaded on demand. You can also still see the web page, but it is downloaded on demand.
So it's not exactly as the mobile version of Google Reader as you don't need to open a new window when you want to look at a linked web page, the alternate content.
The "headers only" option is great for feeds that just contain short textual information. All information is then already contained in the feed. There is no need to download the alternate content or images in the feed for status updates of your Facebook buddies or the latest tweets.
The option is also great for partial feeds that contain some articles that you like, but you don't care for all of them. So with "headers only" you stay informed what articles are there and can look at the alternate content when you are online, it just takes a little bit longer as it has not been downloaded ahead of time.
You can specify the new download option on a per-feed basis and also set a global default:
There is another new option you can specify on a per-feed basis: the display preference.
The default is that for a feed where you specified that the web page should be downloaded an article from this feed will also be opened in the "Web" mode. This is also the case when you navigate between articles on the Show Article screen.
If you specified that NewsRob should not download the content or only the feed content, then the default is that the Show Article screen is opened in "(Display) Feed" mode.
But you can also specify the "(Display) Feed" or "(Display) Web (Page)" mode explicitly.
Why would that make sense?
Consider this: You have a partial feed from a commercial news site, then it not only takes long to download the web page, but it also takes a lot of time to display it. Remember the 100-300 files?
So it may make sense for you for those feeds to configure downloading the feed content + web page, but open articles from this feed in "Feed" mode by default, so that you can browse very quickly through your articles and click on the header to change to the "Web" mode, if an article is interesting to you.
Does this make sense? You tell me – leave a comment. NewsRob is intended for people that live in their news reader, not so much for the casual users that checks once a week for something to read.
You could tap in the Article List on the globe to directly open the Show Article screen in "Web" mode before. With the introduction of the new configuration options this is an obsolete feature for most of the cases and so I removed it. If you are one of the two people using it, please don't fight the removal. In an attempt for more simplicity this feature is gone for good.
The "Feed" or "Web" mode is displayed in the upper left corner of the Show Article screen. Below that you'll see the download state as before (globe, phone).
The download state can also be seen in the Article list in a bit more detail than before.
Monday, April 6, 2009
- 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.