Harri Salminen's Forum Nokia Blog

Simple solutions, huge benefits

Thu, 30 Aug 2007 22:20:45 +0300

All too often developers try to solve problems with the latest and coolest technologies. You probably can recognise the “next feature pack will include THE missed feature” disease and its close relative “this feature is now available in only one terminal model, but wait until it is embedded into base platform”. Stop for a second and think if the current problem could be solved with existing enablers instead of waiting for some new killer-enabler to appear.

The trigger for these thoughts was a small piece of news I saw in a newspaper. The story told how a Finnish hospital had used SMS-based alert system to inform patients about available consulting hours in case previous patient had cancelled the time. Another example was the solution that sends an SMS message to patient asking if any of the available times would be OK before the actual reservation is made.

The estimate of the savings these applications generate is really something to think about: for a smallish hospital these solutions are estimated to save nine person’s work every year. Those nine people can now do their work taking care of patients, not sitting at the office answering to phone calls. Simple applications like this might not be technically the most exciting, but what’s most important - they improve the processes using widespread mobile technologies. And when hospital use is concerned, solutions like this save lives when nurses can concentrate on their jobs.

Operator view on NFC environment

Wed, 23 May 2007 08:44:04 +0300

GSM Association has recently published a Technical Guideline document about mobile NFC technologies. This paper is an interesting one for two reasons: it gives you an idea how major operators (MNO's involved in this NFC initiative represent 45% of the global GSM market) see the technical future of NFC-platform in mobile domain and the paper also gives an overview to the protocols and problematics that typically are hidden behind different API's.

This is an interesting initiative to follow, as operator's needs and requirements sooner or later will have impact on actual terminal models.

Browser and enterprise applications

Fri, 11 May 2007 07:09:57 +0300

For all these years that I have been in mobile industry one question has remained the same. Typically at some stage of enterprise project customer poses the big question: "But why we just can't use the browser of the terminal, instead of making this client application?"

First the answer was that making data calls (this was before GPRS) is so slow, unreliable and expensive. Then we got GPRS, UMTS and even WLAN.

Then the answer was that browser is not capable of doing the right things or the browser is so slow to use. Then came xHTML browsers.

Then the answer was that browser user-experience is poor, page rendering bad and browser misses some vital parts that desktop browsers have. Then came the new OSS web browser for S60 3rd edition.

Although the infrastructure now seems to be there, I still think that native application is the number one solution for mobile enterprise applications. Here are the most important reasons for this.

Most importantly: native application can be used offline. It is a common scenario that application will be used by field workers in places where network coverage cannot be assumed. Do a test: visit some basements, machine rooms or stairways and see what happens to network coverage. Browser based solution that works fine outdoors and in offices would become unusable in places where application would really be used. Native application can cache data and work fine without network.

Important design rule for (enterprise) applications is that user interface must be easy to use, robust and follow the same look and feel with other applications. UI that would in some other context be judged as uninteresting and non-innovative can work fine in enterprise application. Remember that users are not technology savvy early adopters, but people that probably use the application because their manager has told to. Native application with familiar UI components like settings screens, tabbed dialogs, searchable lists etc. are valuable asset when trying to manage and display large amount of enterprise data.

In many cases applications must be aware of the surroundings of the terminal and integrate with terminal's native applications. Assume an application that needs to take a picture, geotag it with GPS information, attach it to email and send it to office. Or application that switches terminal's profile based on meeting information stored to calendar. These are examples of features that just cannot be made with browser, but are typical enterprise requirements.

Don't get me wrong, I like browser solutions and I also create those for enterprise and consumer use. Just remember to assess carefully the application requirements and usage scenarios before making the big decision about the overall architecture, no matter how fancy the browser would be.

Prompt user at uninstall, ok or not?

Wed, 14 Feb 2007 09:04:00 +0200

We have successfully got an application Symbian Signed and we had to to make a minor change to the application (add one setting field, to be exact). OK, no problem. We change the application, prepare it for Symbian Signing, get the quotations and select the test house. Because application was already signed by another test house, I really wasn't expecting any problems. But...

Application was rejected because of a fatal problem, said the test report, application cannot be uninstalled. This was because our application has a couple of background servers running all the time. When such an application is to be uninstalled, terminal application manager will prompt user for closing down the background servers. User selects yes, servers are closed and all files are removed. However, the test house was feeling that this is not according to the test specification and they decided to reject the application. No matter how hard I try to read the test case PKG-04 I can't see where it is said that users must not be prompted during uninstall. A quick search to Forum Nokia discussion board shows that we are not alone with this problem, please see this thread. Yes, surely it would be possible to add "close down all the background servers" feature to our application but what's the point? The organizations that decide to use our solution want applications to be running all the time at the background and test criteria doesn't force us to add the unnecessary feature either.

I feel the test plan must be clarified regarding uninstallation. Can users be prompted during uninstall or not? Now that is not explicitly stated and test houses interpret the test plans differently.

So, how did the story end? I submitted the unchanged application to the test house we used for first signing, got package signed and customer installations have begun.

Where is my home network?

Wed, 13 Dec 2006 22:58:27 +0200

Some time ago I changed my mobile network operator to get a cheaper data plan. After the change I quickly started to feel that something isn't quite right, but wasn't sure what it was... Then I understood that my phone thinks it is not registered to home network, i.e. it is roaming all the time.

The situation is that my new operator is a MVNO (mobile virtual network operator) that doesn't have own network infrastructure but instead licenses it from a “real” operator. In this case interesting is that my operator has its own mobile network code allocated from ITU; I would assume that's not the case for most MVNOs. So now I have a subscription that is always roaming, current network is different than home network.

In practice this means that

limiting automatic email pull only to home network will not work
limiting MMS receiving only to home network will not work
network registration -aware settings for many applications (like Mail for Exchange) will not work

Techical note

For S60 3^rd edition network registration status can be retrieved with class CTelephony that will tell you the current network and registration information. However, with that class you cannot get information about the home network. To get actual home network information I used an older device and the Mobinfo package from Symbian.

Business note

Of course there wouldn't be a need for “only in home network” kind of a setting if roaming costs were a little bit less astronomical. A short trip abroad with some web browsing and email activity will cost you more than a two-month domestic bill (just happened to me). There is an initiative to cut down roaming costs at EU level, but unfortunately that wouldn't affect data costs.

Where are new RFID terminals?

Tue, 28 Nov 2006 00:22:05 +0200

Last year I was asked about the possibility to use RFID-tags with Nokia terminals. I did some research and found out that there were two devices in the market that supported separate accessory RFID-shells. The problem with those shells was that you were locked in to Nokia's NFC server solution; there was no option that you buy the terminal, shells, RFID-tags and set up your own system. That wasn't acceptable for us and RFID solution was ignored.

Now, after 18 months, the situation is the same. There are no new devices supporting RFID, Forum Nokia has no documentation about RFID and the server lock-in is probably still there (I haven't verified the server situation, this is typically something that you can't read from marketing documents).

I wonder why the situation is like this? RFID solutions would offer great possibilities for field-force systems, asset management, work assignment systems etc. With RFID tags the need to type in data with terminal's small keypad in probably stressful situations is greatly reduced, hence improving data quality and speed; reading is easy and tags are cheap. Imagine a typical commercial off-the-shelf mobile phone with an integrated RFID reader and open APIs to control it - no special hardware, broken devices easy to replace, good connectivity with WLAN and 3G, SDKs available to create great enterprise solutions, good battery life and fine selection of 3rd party applications.

Why this has to be a dream?

E or N-Series; what's the diffrence?

Thu, 16 Nov 2006 21:37:42 +0200

Some days ago Gabor Torok wrote in his blog about his intentions to buy an E-series terminal but buying an N-series device instead. After reading about his experiences I began to wonder what are the "hidden" differences between E and N series devices. So I took E60 and N93 and started to compare those with intention to find out the differences that are not mentioned at the Forum Nokia device specs.

The result was that although there are some differences "Enterprise terminal" and "Multimedia computer" are not very far from each other - which is of course not a big surprise because both are running the same platform.

Here are the differences I found:

E60 has reply-to setting for IMAP accounts
E60 can display email headers on active idle screen
Message item listing for E60 can be displayed either 1 or 2 rows high
E60 has IP-passthrough option for USB-connection
N93 has image printing and media player options for USB-connection
N93 can synchronize bookmarks with SyncML
Application installer for E60 will reject unsigned applications by default
E60 has VPN, Internet telephony and instant messaging applications
E60 has Navigation and Landmark applications
E60 has Voice aid application
E60 has Screen export application to send screen contents to data projector whereas N93 has TV-out
E60 has printing application with support for network printers
Terminals have different applications installable from Catalogs application. For example: E60 has complimentary subscription to WorldMate

Finally a note about SyncML client in both devices: it will not accept an encrypted connection to server if server's root certificate is not installed to terminal. Instead of seeing the familiar "This site has sent an untrusted certificate..." the application just displays "Server not responding" and cancels the synchronization. Thanks to common platform this "undocumented feature" appears in both devices.

Have you noticed some other (non-obvious) differences between these devices?

Synchronizing data between S60 devices

Tue, 14 Nov 2006 00:17:41 +0200

Today when I was browsing the Internet for the latest news on mobile ecosystem, I clicked some link and was thrown to s60.com. It had been quite a while since I last time visited that site and I must admit that there has been a major facelift for the site. My previous experience was that s60.com had just some generic S60 presentations copied from various Nokia websites, but after today's visit I'm sure I'll check that site more often to see how S60 is marketed to public.

One of the most interesting parts of the site were the blogs. There was an exciting entry about phone-to-phone synchronization, which I had thought is only for PIM data. However, users can synchronize any data between the terminals and - this is the best part - it easy for developers. Just write your files to C:DataNokia or E:Nokia to get them synchronized. Read the original entry for more details.

If this feature really works, I can see many possible cases where phone-to-phone synchronization can support and extend the phone-to-server sync. And nice thing is that it doesn't require complex server infrastructure to start experimenting.

I've heard there is a new firmware available...

Tue, 07 Nov 2006 16:24:49 +0200

It was one morning last week when we got a report about new firmware version for Communicator devices. That's always a serious situation, because we have learned that new firmware versions sometimes cause interoperability problems. A typical customer installation can contain applications from different software vendors, security applications, encrypted disks, customer specific settings etc. Some change in terminal firmware can cause problems for the whole installed system.

When we were getting our test devices flashed, I started (once again) to hope that we could get an alert about new firmware releases. Currently we get the information quite randomly: for example customer reports a problem or asks if there are any "known issues" related to some version. Then we try to get one device flashed and verified. If we could get an alert about a new firmware release, we could test the systems before customers get the firmware and fix the possible problems. I'd be happy if I just got a message telling that new firmware is out there.

This time the story has a happy ending: everything worked like a charm after firmware upgrade.

How to become a Phone Sniper?

Thu, 02 Nov 2006 23:15:49 +0200

I assume anybody who has released an application for mobile devices will agree – testing every aspect of the application is a nightmare. Testing as such is a difficult and time-consuming task, but testing mobile devices adds extra difficulty: the variety of devices and different firmware versions. Where to get all the devices? How to get the devices flashed with different firmware versions? How to even know which firmware versions exist!

Funambol, the company hosting the famous open-source synchronization engine, has solved the testing problem by activating the whole developer community to test the application in their Phone Sniper program – and to get paid for it. From their website you can check the list of terminals that so far haven't been certified with their latest released software. If you find your phone from the list of uncertified devices, register yourself to Funambol, run the tests, submit results to them and receive the reward. More information can be found from Funambol's website.

I think the test result submission page is still missing two important details:

the phone firmware version
the SyncML protocol version used, for example S60 3rd edition devices support both 1.1 and 1.2 protocol versions