dw2

30 June 2012

My reasonably smooth upgrade to Ice Cream Sandwich

Filed under: Android, change, compatibility, Google, Samsung, WordPress — David Wood @ 9:42 pm

I’ve been looking forwards to the new experiences that would be unlocked by installing “Ice Cream Sandwich” (Android 4.0) in my Samsung Galaxy Note, in place of the Gingerbread (Android 2.3) it originally contained. But I’ve been delaying the upgrade.

I’m a big fan of new technology, but my experience teaches me that upgrades often bring disruption as well as progress. Upgrades of complex software systems often unintentionally break functionality, due to unexpected incompatibilities with the old platform. And even when functionality is improved, it can take some time for users to learn a new interface: old habits have to be unlearned, and new “intuitions” acquired. That’s why I’m sometimes a technology laggard, as well as a technology enthusiast.

But today is the day. The new platform is mature, and is no longer “bleeding edge”. It’s been on the market for a few months. Several of my Accenture work colleagues have already upgraded the Galaxy Notes they use, without reporting any issues. And some of the applications I now want to test (applications developed by work colleagues) rely on functionality that is present only in the newer platform – such as improved Bluetooth. So this morning I resolved: let’s do it today.

In summary: the experience was smooth, although not without glitch. So far, I am pleased with the outcome, although I’ve experienced surprises along the way.

The first surprise was that I had to go looking for the upgrade. I had expected I would automatically be notified that a new version was ready. After all, a similar system works fine, to automatically notify me of the availability of new versions of the apps I’ve installed. And – see the following screenshot – my phone had the setting “auto update: check for updates automatically” enabled.

However, my experience was that I had to explicitly press the button “Check for updates”.

That button helpfully recommended me to ensure that I was on a wifi network. Good point.

The update would happen in two stages:

  1. First, the new version of the software would be downloaded – all 349.38MB of it
  2. Second, the new software would be installed, in place of the old.

The download system estimated that it would take 16 minutes to download the new version. It told me I could keep on using the device in the meantime, with the download proceeding in background. Having kicked off the download, and watched the first 10% of it complete fine, I switched tasks and started browsing. In retrospect, that was a mistake.

As the download proceeded, I read some tweets, and followed links in tweets to Internet pages. One link took me into someone’s Google Plus page, and another link from their took me to yet another page. (By this stage, the download was about 60% complete – I was keeping an eye on it via a notification icon in the top bar of the screen.) I then tried pressing the Back button to undo the stack of links. But as sometimes happens, Back didn’t work cleanly. It took me “back” from one page to the same page, with a minor shiggle in between. This kind of thing sometimes happens when a link includes a redirection.

This is where personal habit took over. In such cases, I have fallen into the habit of hammering the Back key several times quickly in succession. And that seemed to work – I ended up back in the Twitter application. But a few minutes later, I realised that the upgrade notifier icon had disappeared. And the download was nowhere to be found. I think that one of the Back buttons must have ended up going to the download window, cancelling it. Woops.

No problem, I thought, I’ll restart the download. It will presumably continue from where it had been interrupted. But alas, no, it started at the beginning again.

The second time, I resisted the temptation to multi-task, and let the download complete in splendid isolation. Around 20 minutes later, the download was complete. I thought to myself, Now for the more interesting part…

Before completing the installation, I ensured the mains power lead was plugged in, to avoid any complications of a battery failure half-way through rewriting the operating system part of the phone. At all costs, I did not want to end up with a “bricked” device (a device that cannot restart, and has as much life as a brick).

The upgrade proceeded. The screen changed several times during the process. At one stage, a progress indicator seemed to become stuck at around 80% complete for ages – so that I wondered if the system had crashed – before finally slowly inching forwards again.

Once the phone restarted, it run through yet more steps of the upgrade. It told me it was “Optimising application 1 of 82” … “Optimising application 82 of 82”. Then it said it was “Upgrading Contacts database” and “Upgrading Agenda database”. Clearly a lot was happening behind the scenes.

Finally it showed the familiar SIM unlock screen. Except that it wasn’t exactly the same SIM unlock screen as before – there were small but noticeable changes in the layout. Likewise with the device unlock: the ‘OK’ button is now in a different position from before. My fingers will need to learn a slightly different physical sequence, to unlock the device.

A bigger surprise was that all my customisations to the seven different home screens were lost – they had all been reset to defaults. It’s no big deal – I can gradually change the screens back to what I personally find convenient. And a good clean out is probably not a bad idea.

There are lots of pleasant surprises too. For example, there’s a handy new “Restart” addition to the dialog that is shown when the power switch is held down:

Here’s another example of an unexpected change: I found by trial and error that screenshots are now stored in a different directory on the phone – \phone\pictures\screenshots rather than \phone\screencapture – and are (it seems) stored in a different way: they’re not written to disk until some indeterminate time after the screen capture has finished.

That change caught me out twice over: first, because I could not find the screenshots (as copied into this blogpost) in the place I was accustomed to finding them, and second, because the files I tried to upload into WordPress were zero bytes in size. (WordPress helpfully advised me to “upload something more substantial”.)

In case this sounds like a litany of complaints, let me hasten to clarify that I find the entire process highly impressive. A huge quantity of software has been transferred wirelessly onto my phone, including countless changes from before. It’s a technology miracle.

What’s more, I didn’t pay anything for this upgrade. It’s a free technology miracle.

But I am glad I waited until the weekend before embarking on this upgrade, rather than trying to squeeze it into the middle of a busy work schedule. Significant change deserves significant time.

25 September 2008

Revealing secrets

Filed under: APIs, compatibility, openness — David Wood @ 8:58 am

I’m increasingly looking forward to the unveiling of lots of secrets about Symbian software. The more I hear about specific ideas third party developers have for add-on and plug-in software for Symbian devices, the more I realise that their needs will be better served once the Symbian secrecy kimono is swept away.

Take one example, from my browsing of the Forum Nokia Developer Community Discussion Board. User “jas76” asks a question:

Hi, I need to mute downlink audio (i.e. from remote end) during call; and play music on music player. Remote voice is currently mixed with music and couldn’t find a way around it with any public API/SDK plugin. All discussion thread finaly result in to microphone mute. (mute mic is possible though via SDK plugin)

Is this possible from any private API that we could request? or there is no API that could achieve it? Any experince from Nokia partners in this area?

Less than 90 minutes later, there’s an answer on the Forum, from one of the Forum Nokia Experts, “symbianyucca”:

I’m rather sure there are not such an API available.

Needless to say, jas76 had been hoping for a different kind of answer. He followed up:

Hi Symbianyucca, Thanks for your inputs. So disappointing that such a simple functionality/requirement and Nokia made it not difficult but impossible. If this is because of security reason they could lock it under some capability. But making it impossible is really really disappointing.

Thanks anyways for your response. Anyone else tried to get API from Nokia for this purpose?

And the thread goes cold.

Is the answer on the Forum correct? Is the particular aspiration of the third party developer one that is reasonable, from a technical point of view? The point is, it’s really hard to tell, without gaining access to information that is currently not available to the majority of participants of this kind of forum.

By the way, before going further, I must say that I am impressed by the helpfulness, knowledge, friendliness, diligence, and upbeat humour shown on these forums by the Forum Nokia champions – who are generally providing answers on a voluntary (unpaid) basis. These individuals do a fine job, oiling the wheels of discussion, and making lots of useful suggestions, to nurture and expand a spirit of community self-help. However, there are often limits on the help that can be provided in this way. That’s because of current restrictions on distributing the source code of Symbian OS and S60. Without access to this source code, many discussions become stalled.

Take another example. Significant numbers of developers (including researchers at universities) are keen to explore the interesting possibilities of the information known to the phone about its location. The phone itself is usually in contact with several different cell towers. If applications could access this full set of information, it would allow them to determine the position of the phone more accurately than is possible by just using information from a single cell tower. However, I’m told that no APIs are available that provide this richer set of information. On the other hand, internal Nokia applications do seem to be able to benefit from this information. (Note: I understand that this information will be available to third parties in Symbian OS v9.5 – but that’s of little comfort to developers who are trying to develop location-aware applications on existing Symbian phones.)

That’s two examples. There are many more. I probably not have picked the best examples. I’m not sure about the details of each example, and I may got some of the details wrong. However, the general points seem clear:

  • Developers will in principle benefit considerably from being able to delve into currently restricted information on Symbian and S60 APIs, once the code is placed into open source;
  • This will avoid the situation where, at present, too many interesting discussion threads become stalled, and enthusiasm withers away before it has the chance to create an important innovation.

On the other hand, there are of course drawbacks to this kind of openness. There are often good reasons why internal APIs have not been publicised.

For example, as soon as they are published in official SDKs, APIs become subject to tight compatibility change control. This change control is vital, for the stability of add-on and plug-in applications that depend on these APIs. But it also restricts the freedom of internal Symbian and S60 developers to evolve and improve these APIs. Especially while APIs are at an early stage in their life, there can be compelling reasons for developers to completely change their design. So there will need to be a careful education campaign, that explains that internal APIs (and many other pieces of information which developers obtain by browsing the source code) can change without warning – and may even change between two apparently similar versions of the same phone (distinguished, perhaps, only by a minor build number)!

  • For this reason, I expect that discussion forums will collect and publicise information about the ways these internal APIs change between different phones.

Secondly, some part of the code of a phone will not be made public. Like it or not, the owners of some parts of the code may decide that the code would allow leakage of knowledge of commercially sensitive algorithms, data structures, or whatever. However, the good news is that, in the world of the Symbian Foundation, the extent of this kind of withheld code will be very much less than at present. Whereas the current bias often seems to be, “in case of any doubt, withhold”, the new bias will be, “release the code, unless there’s a very strong specific reason not to do so”.

So we can look forward to moving from a situation where developers are often constrained by lack of information, towards one in which the primary constraint will be their own ability. That’s a much better situation.

That leaves the question: how long will we need to wait? Given that it may take up to two years (from the initial SyFo announcement on 24th June) for the completion of the exercise to move Symbian platform code into open source, it may seem this is a far-off future vision. But many things will be happening before the end of that two year period. Parts of the source code will be released, in a staged manner, at various phases during 2009. We’ll be moving as fast as we can, subject to due care and attention – and subject to continuing to meet our very important “business as usual” commitments of interim deliveries of technologies and customer support.

Blog at WordPress.com.