I've been getting some feedback from developers on the WeatherCork application. Specifically, how the application displays the images without saving them to the file system, which someone took time to scour through the file system on his device looking for them.When I first started developing the application, my instinct was to get the image from the URL, save it to the file system, then load the PictureBox controls with the corresponding image. Sort of like the Temporary Internet Files for Internet Explorer, the application would check to see if the file already existed and if not, would download the file to the application directory.
The application itself only takes up 27kb of space but after a week of testing the application on my device, I noticed that the cache I had developed in the application folder contained over 140kb of JPG images! Of course, I could provide a way for the user to delete the cached files, but after a couple of days, the varied images would return taking up precious RAM.
Beta Two of WeatherCork utilized a method for deleting the files when the application closed while Beta Three deleted the files when the application started but considering users may go for months without resetting or closing the application, the problem still existed.
One of the reasons I chose the cache image method was speed. In a desktop application, such as Internet Explorer, the benefits would be noticeable. A check is made to see if the file exists and if it has not been changed since the last time saved, then there is no need for a browser to reload it. This speeds up the experience and on a dial-up connection, this could be significant.
With mobile devices however, memory is more precious than speed. I wouldn't think twice about having an Internet cache on my desktop that contained a gigabyte of files but on my mobile device with limited RAM I would.
With the final release of WeatherCork, I chose to abandon the file cache and dynamically load the images into an ImageList control. Although the load is a little slower, the application at runtime only occupies approximately 50kb of space.
To load the images, I wrote a custom function that retrieved the image from a URL then created a bitmap suitable for a control like an ImageList or a PictureBox.
Function GetDailyImage(ByVal ImageUrl As String) As Bitmap
Try
Dim Request As HttpWebRequest = CType(WebRequest.Create(ImageUrl), HttpWebRequest)
Request.Method = "GET"
Dim Response As HttpWebResponse = CType(Request.GetResponse(), HttpWebResponse)
Dim ResponseStream As Stream = Response.GetResponseStream()
Dim Writer As MemoryStream = New MemoryStream
Dim Buffer() As Byte = New Byte(4096) {}
Dim BytesRead As Integer = ResponseStream.Read(Buffer, 0, Buffer.Length)
While BytesRead > 0
Writer.Write(Buffer, 0, BytesRead)
BytesRead = ResponseStream.Read(Buffer, 0, Buffer.Length)
End While
Dim DailyImage As New Bitmap(Writer)
ResponseStream.Close()
Writer.Close()
Return DailyImage
Catch ex As Exception
Return (New Bitmap(55, 58))
End Try
End Function
Once the bitmap was generated in memory, it is added it to the ImageList.
ImageList1.Images.Add(GetDailyImage(Daily(i).WeatherImage))
ForecastItem.ImageIndex = i
Testing showed that the file cache versions averaged a two second benefit in speed. Although the release version is slower to load, the application, device and user benefits from a smaller footprint and does not require additional code to clean up the cache files.
Since publishing the source code to WeatherCork, I have realized that additional memory could be conserved. Instead of loading all seven images, one for each day, I could point the ListView.ImageIndex property to different images.
For instance, it is possible in some areas like San Diego to have clear, sunny skies all week. The reference to the seven forecast images would all be the same so only one image would have to be loaded into the ImageList control. Each forecast in the ListView control would have an ImageIndex pointing to that one image.
]]>
