Porting QML RSS Reader to Windows Phone

Porting the design

The Windows Phone version of RSS Reader looks and also behaves somewhat differently than the QML version. Even though the basic flow of the application is the same (choose a feed, choose an article, read the article preview, open it in the platform browser), the way to accomplish the task is different.

In the QML version, there is a custom accordion list that is used to access the feeds in different categories, but in the Windows Phone version we wanted to embrace the Metro UI. Therefore we decided to use the Panorama control in the main view, so that each !PanoramaItem contains one category of RSS feeds. The feeds are shown as large squares with the feed icon and name (if the feed icon is not available, a default icon is shown). The squares imitate the style of the Windows Phone start menu icons.

The feed view is constructed as a Pivot control. The Pivot control consists of PivotItems with one PivotItem for each RSS feed in the currently selected category, and the user can switch between the RSS feeds by swiping the screen horizontally. Inside the PivotItem, the RSS items of the feed are shown very similarly to the QML version, in a scrollable list. Filtering the list of items on the Windows Phone version is done a little differently; tapping the search button takes the user to a new screen with the list of items and a textbox for searching. The decision to go to a separate page is due to screen estate concerns, as there would not be quite enough room for the actual RSS items if the search field were on the PivotItem (especially when the on-screen keyboard is visible).

Porting the data model handling

Contrary to the QML version of RSS Reader, the Windows Phone version needs to persist RSS data to disk. This is due to tombstoning, which occurs whenever the application is pushed to the background, for example when a phone call occurs or, in the case of RSS Reader, the user opens an article in the platform browser. The application has limited time to store ('tombstone') its state and data before it is killed. When the user returns to the application (the phone call ends or the user presses the back key in the browser), the application is brought back from the tombstoned state. That's when the application reads its state again and fills its data model from the disk.

Porting the UI

To maintain the platform feel, both QML and Windows Phone versions use platform components for the navigation (Qt Quick Toolbar vs. device HW keys), Dialogs, Buttons, and so on. This is also a usability issue, as within the same platform the user expects application closing, navigation, and other basic tasks to happen the same way in all the applications. In addition to platform components, the QML version uses a custom accordion list component. Please refer to the section 'Porting the design' to find out the reasoning behind choosing the components.

Image 1. Comparing the main screens.

On the main screen, the biggest difference between the two versions is the direction of the UI - in the QML version the categories are stacked vertically in an accordion control, and in the Windows Phone version the categories are horizontally next to each other in a Panorama control. In the Windows Phone version the user can access the Manage Category screen by tapping the cogwheel, and as in the QML version, the currently visible star opens the Manage Category page for the currently visible category. Like in the QML version, in the Windows Phone application there is no dedicated Quit button anywhere - instead, the application in Windows Phone quits when the user presses the HW Back button on the first screen of the application; just as the QML application quits when the user presses the Back button in the Toolbar on the first screen. If the user presses the Windows HW button, the application is tombstoned to the background and can be reached again by using the Back button.

Image 2. Comparing the feed screens.

The feed screens are mostly similar. The biggest difference is in the search functionality, as the QML version does the search in the feed screen and the Windows Phone version has a dedicated search screen, as explained above in 'Porting the design'.

Image 3. Comparing the item screens.

As with the feed screens, the item screens are mostly similar. There is a small difference in navigating to the full article, as the QML version has this functionality as a button in the content area whereas the Windows Phone version has this functionality in the application bar, where the primary functionality of the view should be placed in Windows Phone.

Porting the RSS feed handling

Both versions parse XML using components baked into the frameworks. The QML version uses XmlListModel whereas the Windows Phone version utilises the XmlReader, SyndicationFeed, and SyndicationItem classes, with which one can easily manipulate RSS feed content.

GIF support

Silverlight does not support the GIF file format, which is problematic as it is still widely used in RSS feed icons. A known workaround for this is to utilise .NET Image Tools which convert GIF files to a Silverlight-friendly format on-the-fly. However, three critical issues were identified, eventually leading to the decision not to use the Image Tools library in RSS Reader.

First, Image Tools is basically just an image format converter which means the performance is much poorer compared to what native GIF support in Silverlight would be. We observed both a significant increase in application start-up time and very noticeable lock-ups during the first few seconds after the splash screen gets dismissed. This is because applications must load all feed icons in the main panorama view, and the performance of Image Tools seems to be suboptimal. Secondly, at the time of writing this article the stable version of Image Tools library (0.30) offers support for GIF, PNG, and BMP, but surprisingly does not support JPG. This makes the usage of the library hard because two separate code paths are required. Image Tools JPG support plug-in would be available in the trunk version, but the trunk version seemed to be too unstable to be taken into use.

For reference, the .NET Image Tools site contains the required documentation for taking the tools into use. The trunk version of the library is publicly available, and developers can choose to either compile the whole library, or just compile the JPG format plug-in and use it with version 0.30 binaries of the library.