This version has been lingering in the queue for quite a while. Most of the changes won’t be immediately visible to users. For this blog I pick one that exemplifies the priorities of the upcoming mobile app:
Testers inside Burma (Myanmar) have reported that downloading the initial data to the app still takes considerable time. This will need to be addressed by an improved download mechanism, including lazy loading. Since the development version of the mobile app can now determine the network speed, we are also able to transfer different image sizes depending on the connection quality.
The avatar sizes of the fictional user Ma Lay, for example, are:
- 12.1 KiB for the full-size avatar
- 2.1 KiB for the large icon
- 1.4 KiB for the small icon
On the list view, the API therefore delivers on slow networks the small (instead of the large) icon and on the detail view the large icon (instead of the full-size avatar). For our sample deployment, this reduces the amount of data for the list view from around 59 KiB to 30 KiB, which amounts to roughly 50%. This ratio results from the fact that images make up the main part of the volume. For the detail page, the difference is 14 KiB versus 4 KiB – reducing the volume by about two third, as a rule of thumb.
These amounts seem negligible to us who are used to have a fast connection but they appear to be relevant on networks that allow just a trickle of data.
Looking at the trade-off in terms of image degradation, the difference becomes particularly visible on larger images:
Note that the image quality loss has not been caused by a different JPEG compression ratio, but by enlarging an undersized image. Using a different compression would mean additional work for the API, while simply delivering a different image size can be done from resources that are already available.