things to make sure you have turned on

December 30, 2008

Version 1.1 delivers some new features that improve tiggit mail, many of these can be turned on & off through settings, so it is worth checking your options to make sure you are getting best benefit of the new features, once you have upgraded from version 1.1

  • renderHTML

renderHTML instructs tiggit to attempt to render any HTML messages as a web-page, it will also cause tiggit to download any images that are embedded in the message etc. The renderHTML option is in version 1.0, but the HTML rendering in early versions was not very clever. The ability to draw HTML messages properly is an important new capability for tiggit mail, and if you don’t select renderHTML you will be missing out.

  • contactMenu

tiggit mail can place a link on the contacts menu to allow you to create a tiggit mail directly from your contacts.

BlackBerry Contact List showing tiggit mail menu
BlackBerry Contact List showing tiggit mail menu
  • useSDCard

tiggit mail can use the removable media card (the SD Card) to store email messages, rather than using the BlackBerry internal storage. This frees internal storage on the handheld for other things, and provides a vastly improved storage space for tiggit mail.

  • postBlockSize

postBlockSize is on the network settings panel, and provides a technical tuning capability. If you use singlePost and/or a tunnel connection, then this setting might be useful. When using singlePost/tunnel outgoing messages the message is sent to the tunnel as a series of http blocks using the http POST mechanism. This option sets the size of the block to be used, in bytes. The default is currently set to 1024 (1K) which is a little small if messages contain attachments as the overhead of the http headers etc. becomes quite significant. I have this value set to 25600 (256K) and find it quite reliable.

  • useWiFi

useWiFi has changed, and provides an option to have tiggit automatically switch between the cellular network and the wifi network. Users can set useWiFi to

    • cellular only
    • Wifi & Cellular
    • WiFi Only
  • mailboxOpen

mailboxOpen is found on the settings panel for each mailbox (towards the bottom) and is used in conjunction with the ‘default folder’ setting on the folder settings dialog.

defaultfolder

Folder properties panel showing default folder setting

mailboxOpen can be set to either DEFAULT or FOLDERS. The controls how the mailbox opens. If default is selected, the mailbox will open to a view of the default folder – typically the INBOX. If folders is selected, the mailbox will open to the folder view for that mailbox.

Users that have all their incoming mail in a single folder might prefer to set this to DEFAULT, and set the default folder to that which has all the incoming mail. Users that have their incoming mail filed into a number of different folders might prefer to select the folder view.

Screen shots in this post are taken from my BlackBerry Storm device, and not from the simulator. The blog was looking a bit boring with no screen shots…..
Advertisements

IDLE Battery Life

June 15, 2008

Some tiggit mail users have been experimenting with tiggit’s IMAP IDLE functionality. One of their concerns is that the BlackBerry battery life is severely compromised as a result of enabling IDLE.

I have started running a test to benchmark the impact of maintaining an IDLE session on battery life.

The test is set up as follows. I have a BlackBerry Curve 8210 that uses GPRS over Vodafone in the UK, on a regular data package. It is running tiggit mail 0.1.48 and is connecting to gmail over IMAP. Obviously tiggit has useIDLE set and has no value in idleRefresh – so it is using the default.

I also need to simulate email activity and so have set up a cron job on a webserver to send an email to my gmail account five times an hour on an irregular schedule. Actually at these minutes past the hour 10,20,40,45 and 47.

I started the test running at 11:00 this morning with a fully charged battery, and it is now nearly 3pm, and the battery shows about 5% used. (I guess a tool to tell me precisely how much battery has been used would be handy, and should only take a few minutes to write.)

As an aside, there have been a few questions about data use, so this test will probably be repeated with some additional data use tracking enabled in the code.

UPDATE At 8pm: I have written a little tool that tells me the battery use reported by the handheld. After 9 hours of running in IDLE mode, the BlackBerry Curve is reporting 83% battery.

UPDATE At 11pm: The Curve has been running for 12 hours in IDLE mode, and the battery is reporting 77%. I have shutdown the test for now, and turned off the BlackBerry for now.

No UPDATE on Monday, as I have been fixing packaging issues all day. Will restart the tests tomorrow.


Seamless wireless access

June 13, 2008

For many BlackBerry users the amount of data that is consumed by an application is not an issue, mostly because they have unlimited data plans with their BlackBerry tariff. However there are a growing community of BlackBerry users that do not have an unlimited data plan, and use applications such as tiggit mail to access their email.  

The advent of WiFi capabilities within the BlackBerry handheld means that these users would very much prefer to use the much cheaper bandwidth that is available by WiFi to access their email. For them, it is highly desirable for BlackBerry to be able to seamlessly switch between the mobile phone network and WiFi depending on what is available, and making the switch while sessions remain active and with no apparent loss of service.

The BlackBerry API 4.3 documents a very useful class to implement this kind of functionality WAPInfo. This object provides programmatic access to WiFi hardware within the BlackBerry device and provides information such as the SSID of the network that is in use as well as things like signal strength and whether there is an available internet connection.

Further investigation however reveals that most of the devices that have WiFi hardware have an OS built on 4.2 or 4.2.1 of the API, which renders these functions particularly useless. Explaining to a typical BlackBerry user that they need to upgrade the operating system has enough scary words in it that it is highly unlikely they will make the step. 

Further and slightly more difficult is the lack of simulators with version 4.3 API and WiFi hardware. 

In the meantime it looks like I am going to have to implement a really goofy test to attempt to open a connection via WiFi and if this fails then switch to mobile network. Far from smooth and definitely won’t be seamless. Ho hum.