Today looks like an interesting day for Symbian programmers. Right after announcing EKA2 kernel availability as open source, the Symbian Foundation has published details for downloading a free version (some restrictions apply) of the ARM RVCT.

For details, check out this page

Just a short note to give some great news. Right before the annual Symbian event SEE, the Symbian Foundation just announced they're making the kernel and related tools available as open source.

For more details, just read the proper announcement and press release

Interesting times coming!

To those interested, the Symbian Foundation's developer website (beta) is finally open to all

http://developer.symbian.org/

Few weeks ago the FFII and other organizations launched a new campaign to stop software patents. Should you wish to participate please sign up here.

In case that terms like software patents and copyright sound analog to you, please follow these links:

http://en.wikipedia.org/wiki/Software_patent

http://en.wikipedia.org/wiki/Software_patent_debate

If you're a software developer, ISV, etc. and want to know how this could affect you, just take a look at the following patents granted by the EPO (European Patent Office):

Webshop

Order by mobile phone

Get key via SMS

Generate different web page depending on detected device

Reduce page loading time by automatically reducing image quality

'Nuf said..

Just a short note to raise awareness of this list published a couple of days ago.

In my opinion, everyone serious about programming should give it a good read, or better yet be already familiar with concepts such as race conditions, sql injection, buffer overflows, etc.

Recently I had the chance to play a bit with the new Sensor FW API, made publicly available few weeks ago. It's no secret that such functionality will certainly bring new possibilities and offers to the s60 ecosystem. One such example is mixing the live video stream from your camera with tags (provided by the user or some other external resource), thus providing extended information to the physical world.

Of course the field of augmented/mixed reality is not new, but current devices are starting to make this reasonable, with no need of backpacks head-mounted displays or add-on gadgets (though walking around while facing your screen might look a bit weird as well)

The most obvious use case is making use of these placemarks when doing tourism. You tap on a specific point of interest and you get detailed information (either text or audio) about that place.

Unfortunately I don't have a decent camera to make a proper video capture, so here are some screen captures taken on a weekend short walk, featuring the application with a basic UI. (Those attending the MWC will find the place familiar..)

Some people have shown some interest and asked me to create a repository to make collaboration easier, so I hosted the project at google code. You can check out the code using your favorite Subversion client, or with the command line client:

svn checkout http://j2me-mpeg.googlecode.com/svn/trunk/ j2me-mpeg

If you're interested in participating, feel free to contact me.

Update: the project was moved here

From time to time switching to other less used languages is a good thing (especially when doing Symbian)

I recall having seen requests to decode MPEG streams in J2ME (without relying on any media API such as the MMAPI of course):

http://discussion.forum.nokia.com/forum/showthread.php?t=101607
http://discussion.forum.nokia.com/forum/showthread.php?t=129788

Surprisingly enough I haven't seen any decoder so far. So this little hobby project aims to provide such functionality for MIDP 2.0 devices (CLDC 1.0).

The code is self explanatory (I hope) and I set up a page for it on the Wiki: http://wiki.forum.nokia.com/index.php/J2ME_MPEG_decoder

As the text states, the main aim was providing a simple example for learning purposes. There's a lot of room for improvement and optimization and it would be really nice to see some collaboration if anyone's interested.

Even though you won't get the performance available with the MMAPI, using a software decoder has some good pros:

* You are in control of the code, which is rather lightweight (The current jar file size with no obfuscation is about 36KB)

This also means not having to deal with differences and limitations in the implementation, bugs, etc, something the MMAPI has been quite good at (limited aspects, missing events, problems with full screen videos are some of the issues I recall in the past)

* More phones available, as you don't need to rely on the MMAPI

* Being in control of the stream(s), allowing to achieve things such as picture in picture, etc.

An obvious improvement would be supporting MPEG-2 streams (H.264 / MPEG4-Part 10 would be the real achievement) and adding streaming functionality (RTP)

A rather obvious problem is that audio is not supported, yet there are many possible use cases for this project (video surveillance being one of them)

Oldest device I got with MIDP2 was a Nokia 7610, where (depending on the video) up to 5 fps was achieved.

Here's a screen capture rendering "The Wall":

Enjoy.-

At this pace, mobile application development is probably bound to become one of the most fragmented software activities.

Today Google announced Android, "the first truly open and comprehensive platform for mobile devices.", following the (quiet) acquisition of the company ( http://www.android.com ) two years ago.

Besides Google's name (as if that weren't enough), 34 other companies (forming the Open Handset Alliance) are involved in the platform: T-Mobile, HTC, Motorola and Qualcomm, just to name a few.

Besides the initial buzz, this will probably bring some interesting news in the next few weeks.

More info:

http://www.openhandsetalliance.com/android_overview.html 

Among the several talks in the Symbian WDF, I was quite interested in the one on PIPS. The presentation (by Erik Jacobson from Symbian) turned out to be pretty interesting and enlightening. Having worked in some porting projects in the past, and suffering many of the shortcomings of the estlib (now soon to be deprecated), there seems to be at last some good news for future porting developing.

Here're some highlights:

- select() is supported: this single addition makes the whole project worth to me :)
- exec() / fork() are not supported, as they would require many changes in the kernel (use posix_spawn() instead)
- Many IPC mechanisms supported: pipes, fifos, etc.
- Signals and thus asynchronous I/O is not supported
- dlsym() cannot be used with symbolic names, use ordinals instead (there could be some facility provided in the future though, to ease development)
- Carbide.c++ v1.2 is intended to support PIPS development (v9.3+ will introduce new target types: STDEXE & STDDLL). Anyway you can always rely on the good old command line.

PIPS was originally intended for v9.3, but given that most functionality works in v9.1, there will be a sis available to that OS version.
To prove its effectiveness, an independent company ported the TightVNC client for both S60 and UIQ.

To start to get a feeling out of it, I'd recommend you keep an eye on the P.I.P.S. Home @ DevNet , starting with the freely downloadable booklet.