Happy coding

Skype for Linux doesn’t support SMS sending from the user interface. But that functionality is in fact implemented in the library and external apps can use it via the public API. I’ve found a working example of that nice feature. Just do these simple steps:

1. Download Skype4Py from here, uncompress it and install it typing sudo python setup.py install
2. Download Skype tools 0.11 from here and uncompress it
3. Open your Skype client and prepare for the authorization dialog that will appear when you execute the next step
4. Enter into the previous directory and send the SMS: ./send_sms.py +34123123456 My test sms

If the message takes too much to be sent, stop the app (CTRL+C), delete the authorization using the Skype options dialog, and try again. Third and next times worked fine for me.

These weeks I’ve proposed myself to have a look at Google’s Android and try to learn how to write applications on it.

I went to the Android main page and, from there, I followed the “getting started” stuff to download the SDK, Eclipse and started to understand the framework.

The framework is a bit different from what I’m used to. The applications have 4 building blocks:

• Activity: Tasks that the application performs (from the user point of view). For example, manage a collection of text notes. Activities can also request “intents”, that is, use the system to locate a component that can manage the action that the app wants to be done. For example, edit a single note. Intents are a clever way to reuse functionality.
• Intent receiver: These are methods to attend external events asynchronously.
• Service: Functionality provided to another applications by running code in the background.
• Contend provider: A standard way to provide data to other applications.

Android features nice pieces of code, like SQLite database. The intended way of working relies heavily on XML config files, which make easier to build user interfaces and makes me remember the way UIs are done on other frameworks (I’ve heard that Glade uses XML files too).

My wish about Android would be to develop “Caterpillar”, a robotized (this is, for Android) version of Berto’s Vagalume. But for that there’s still a long way to go through.

At this moment, I’ve already created the “Hello Android” app and I’m following the tutorial. I’ve just completed exercise 2 this night. As I advance more, I’ll update this post to let you know about my progress.

UPDATE: 26/01/2008

The three exercises of the tutorial plus the extra credit one are now completed. The next step will be to have a look to common Android tasks and to continue learning from there. I’d also like to try DroidDraw for GUI designing.

UPDATE: 30/01/2008

I’ve started to write Caterpillar. An early version of the GUI was designed using DroidDraw (see the previous update) and fine tuned by hand. Fortunately, DroidDraw lets you not only export, but also import a layout text description.

The very first task I tried was to try to play an arbitrary MP3 file. I looked into the media APIs and tried some methods to load the test sound (as a raw resource, as an external URL and as a local file), but didn’t succeed. At first I thought that the emulator hadn’t the audio enabled, but after adding the “-useaudio” option, that shown not to be the problem.

Then I found this post (spanish) and this other that gave me some hints. At this moment I know that the sound system works, because I can hear the system sound when raising up the volume, but my media player instance is still null, despite I’m using an MP3 lesser than 1 MB in size. Yeah, the emulator has a 1 MB limitation on that. :-/

UPDATE: 03/02/2008

On this Google groups thread there are people saying that Android has problems playing MP3 from online streams, because it pretends to copy the whole stream to disk (SD card or whatever) and then play it. The problem has been reported to the Android bug tracking system.

UPDATE: 02/03/2008

After a month of silence I have to say that I’ve continued my work on Caterpillar in my spare time. Having a look to the Vagalume source code and doing some tests with Firefox and wget, I’ve developed the session management and playlist fetching and parsing code, so I can end up with a bunch of tracks and all the required information about them: title, author, album, picture, audio file URL…

I’ve decided to overcome the limitations of the Android media player by downloading the tracks one by one and feeding them to the media player as local files, erasing them when the media player has finished playing each one. It’s a bit weird solution but is the only one I’ve found.

The TrackDownloader, as I’ve named it, is created by the controller, which registers itself as an observer. When the downloader has got enough data, it notifies the controller, which starts up the media player. In the meanwhile, the downloader keeps downloading in the background and, when the transfer is about to finish, notifies the controller about that, just to spawn another TrackDownloader for the next track. When the track has definitely ended, the controller dismisses it and it’s erased from disk to save space. I haven’t tested the TrackDownloader for the moment, only coded it.

I’ll keep hacking. Stay tuned!

Hi all!

I’ve found this page:

https://help.ubuntu.com/community/BluetoothRemoteControl

…that explains how to configure an Ubuntu distro to support pointer remote control via bluetooth for Sony-Ericsson mobile phones. I’ve found it very useful for presentations, for example.

Try it! 🙂

Theese days I’ve been following a thread in the php-es mailing list at lists.php.es. A subscriber noticed that static class attributes weren’t shared between different page requests. Someone explained him that the way PHP deals with the requests is the cause for it not to have an “application” variable scope.

In Java servlets, for example, static class attributes are shared by all the instances of that class in the virtual machine. Scalability (and speed) at a medium scale is achieved using object in-memory caches. In PHP that approach can’t be done without using shared memory management libraries, and never in an easy way. Developers have to resort to disk and database caches, much slower that the memory ones.

Moreover, the fact of having to parse in each request not only the target PHP file, but also all those ones recursively included, represent another of the disadvantages of the platform.

It’s strange because, as far as I know, an “execution environment” common to all the requests does exist on other languages, like Perl (Apache mod_perl) or Python. That way, data can be shared among the requests, memory caches can be done, and so on.

Something that would be nice, even being a daydream, would be to develop an “application server” consisting of:

• A library that made shared memory usage simpler for storing session variables and object instances on it (even singletons), making them available from different threads.
• A multithreaded web server implemented entirely in PHP using the socket API. The server would spawn threads with each request using the threads and processes API. It’d be a replacement for Apache.

This way, we would have the advanteges of the application servers and the syntax simplicity of PHP. The disadvantage would be that, as PHP has been developed with the “parse, create environment, process the request and dispose everything” model in mind, with the proposed approach, a great number of memory leaks would be found. That memory leaks are currently hidden thanks to the short life cycle of the requests.

That’s all. This was an idea I had some time ago and it seemed interesting to me. Now I’ve decided to share it with you. It’s surprising that nobody has already thought about it, isn’t it?

UPDATE:

I’ve just found Quercus, a PHP5 implementation written in Java that allows PHP programs to interact directly with Java libraries, taking advantage of all the benefits that Java caches, connection pools, etc. can provide. It’s not the same approach I propose, but maybe a good one anyway.