Testing the new Nokia Email Service
Nokia has launched the public beta of its new email service. The email client on my Nokia E61 is very weak for a purportedly messaging and enterprise device. Maybe Nokia finally got it right this time.
Nokia wants your password
I start the sign-up process easily enough from the new email.nokia.com site. You are asked to choose your phone from the supported models. It looks like a relatively small subset of S60 Edition 3 handsets from the past 2 years. Next is step is introducing your email address. OK. Then your password. OK... Oh wait what?
It turns out this is not a hosted service. It peeks into your existing account! Nokia is trying to pull a Blackberry-like trick here. Fair enough, but for testing purposes I am going to use an empty email account before I decide to trust my main email account to the service.
SSL? What is SSL?
Next the service tries to auto discover the email server and fails. After a long while the page loads and asks you for your IMAP/POP3 details. Why it couldn't do that from the beginning?
SSL IMAP doesn't appear to work, the form keeps telling me it cannot access the account. Since I am using Google Apps for Domains I enable the other choice, SSL POP3. Which, unsurprisingly, doesn't work either.
It appears that the service either doesn't support SSL access to email servers, or that the setting is not exposed during account creation.
Back to square one
At this point it was clear I wasn't going to be able to use Google for Domains, so I had to create yet another account, this time on Gmail proper, under the reasoning that Nokia wouldn't be so stupid to leave out one of the most popular email services ever. Except, of course, for the little comment about not supporting Hotmail...
This time it worked, and never prompted for any additional server details. My guess is that Nokia is hardcoding internally this info for Gmail users. I complete the account creation process and in one minute I receive the SMS with the link. Yes, a SMS with a link, not a WAP-PUSH. Cheap Nokia.
The cheapness continues with the site it loads. The page is being loaded with the "Services" browser so the site can read the model information from the User-Agent header. And they asked me earlier my handset model. Yet the page is asking me again to choose a download link depending on my handset model.
The download goes fast (1.7MB) and starts the installer. Everything is autoconfigured and in the end it just asks for the password.
Not so good, not so bad
The application appears to be divided in modules. This probably keeps memory requirements low but introduces some pauses while navigating the interface in my lowly E61. In the settings pane I notice that apparently my mail is going to be pushed. I really hope this is not like the incredibly bad IMAP IDLE support the built-in client features.
I send an email to my test account, and within 10 seconds it is displayed in the phone. Fantastic, working push email. To test it further I mark the message as read from the Gmail interface, and then archive it. The emaill app in the phone keeps it in the inbox as unread. This could be a design decision or just Nokia not wanting to push metadata. Either way it's just an small detail.
The data session is being kept open so I guess it is using a keepalived TCP connection, like Microsoft Exchange Push. To test it I close the data session and send another email. It arrives to the Gmail account but it is nowhere to be seen in the handset. After a minute the data session is opened again with no intervention on my part. But the email is not here. I have to go and select the Sync icon to make it appear. I try it again, waiting this time for much longer. As before the data session is opened again in under a minute but the email doesn't show up. 5 minutes later is still not here. I decide to try to send another email without closing the data session this time. It arrives in ten seconds, and at the same time the undelivered, unpushed one arrives too.
Conclusion
Looks like the quest for robust non-Blackberry, non-Microsoft push email continues. IMAP IDLE is here and well supported, now all we need is an email client that doesn't crap out the moment the connection goes out and is able to reopen it.
How current smartphone platforms deal with background apps
Developers and the Apple faithful are still arguing about Apple decision to block third party apps from running in the background on the iPhone. I'm going to try to offer a bit of perspective on the issue by explaining how current smartphone platforms deal with background apps.
Going by the classic definition of smartphone, both Google Android and the Blackberry JDE are arguably not smartphone platforms and feature phones with J2ME are sure as hell not one. But I am going to include them for the sake of comparison.
Palm OS
Lacks background process. Anything running "in the background" is in fact an OS interrupt handler or some other hackery. Palm OS is simply obsolete in terms of operating system design, and has been for years.
Symbian
Symbian allows full GUI background processes. When the device runs low on memory the operating system will start shutting down background processes. Additionally many of its APIs have explicit error conditions related to low memory errors and resource sharing. The operating system notifies the application when it needs to close it for memory reasons by sending the EEikCmdExit message.
Windows Mobile
Windows Mobile is similar to Symbian w.r.t. background apps. It allows full GUI applications to run in the background and uses its standard message delivery system to notify the application before closing if it runs out of memory (messages WM_HIBERNATE and WM_CLOSE).
Feature phones with J2ME
Sony Ericsson first, and recently Nokia have added background running for J2ME applications. Midlets are by nature usually very frugal on memory consumption so it works fairly well. In addition J2ME also supports termination notifications issued by the OS, so applications can save their running state on low memory conditions. That said the majority of J2ME feature phones are not from Sony Ericsson or from the high end Nokia range, so in general background running midlets are not supported.
Blackberry JDE
I am not experienced on Blackberry development, but as a platform it has supported background applications since day 1 and they are explicitly supported in the API.
Android
Android probably features the best and most balanced background application support. It has memory warning callbacks, like Symbian, and the explicit guarantee that the operating system will try its best to keep the application around, like Windows Mobile. But its defining feature is the the concept of Services: UI-less processes that run in the background and can be spawned on request by applications or by URI schemes:
A Service is a body of code that runs in the background. It can run in its own process, or in the context of another application's process, depending on its needs. Other components "bind" to a Service and invoke methods on it via remote procedure calls. An example of a Service is a media player; even when the user quits the media-selection UI, she probably still intends for her music to keep playing. A Service keeps the music going even when the UI has completed.
iPhone OS
The iPhone OS is a full Unix-like operating system, with a full blown kernel with memory protection and demand paging, running on a powerful CPU that has full support for all these features. In terms of OS design and features it leaves everything else in the dust. Which only makes the way Apple has chosen to cripple third party applications more painful to accept. The iPhone OS has full support for background applications if you are Apple. If you are not then it will kill your application the moment the user jumps out of it.
How Apple could add backround apps on the iPhone
The official reason is that background apps would kill the iPhone battery in no time, so they are not supported. But there is another way. Instead of keeping the full blown GUI of the application have the OS support the Google Android concept of Services. UI-less processes with access to certain features like the sound and network system, working under CPU and I/O quotas so they play nice to each other. They would be still under a "can be killed anytime" policy, but since they don't need to keep a GUI around they would be much easier on the RAM and CPU of the device.
In case you are left wondering what killed the first ALP smartphone, all clues point towards LiMo, the Linux Mobile Foundation and its pet project. The reply came from Edelman, Orange's PR firm, which also told us to contact Samsung and Access directly, but stated: "just so you know the Samsung i800 has been withdrawn. Since the original project was defined back in February there have been a number of advances in mobile technology."
I love how there is not a single smartphone listed at the LiMo site. LiMo looks like a closed, feature phone software licensor, just like Symbian MOAP.
The App Store for the iPhone/iPod touch 2.0 is up. With 500 applications available on the launch day. For reference a popular Symbian site lists 503 applications for current Nokia smartphones.
500 Nokia S60 3th edition applications
- Developed over the last 3 years.
- They do not need to pass any quality certification, only a code-signing process.
500 iPhone 2.0 applications
- Developed over the last 6 months.
- Their code-signing process involves an actual quality assurance test.
After looking into both platforms, from a developer point of view, it doesn't surprise me at all. Even with the maniacal control Apple puts onto their platform it is still more developer friendly than anything Symbian/Nokia has released over the years. You are just more productive on Cocoa. It is actually a joy to program with.