soledad penadés » trick

A hack to parse RSS feeds with php

sole — Sat, 21 Jan 2012 17:19:37 +0000

Just happened to assemble this ~~script~~ hack recently, out of the requirement for a quick’n'dirty feed parsing feature:

$feed_contents = file_get_contents($feed_url);

$xml = simplexml_load_string($feed_contents, LIBXML_NOCDATA); 

$feed_array = json_decode(json_encode($xml));

print_r($feed_array); // Surprise!!

Now this evidently is not SimplePie or Magpie RSS or whatever feed reader library tickles your fancy*, but assuming the feed will never be malformed, it can save you lots of time! Isn’t that what php was meant for? :-P

At first it surprised me that it would even work–but it seems that the JSON module interoperates very nicely with SimpleXML objects. At the end you get an associative array in $feed_array which is a nice representation of the RSS 2 feed. It’s important to highlight the LIBXML_NOCDATA parameter, as it makes sure the CDATA nodes are read as text. Otherwise you would just get empty feed items, etc.

Obviously for this to work you need both the JSON and SimpleXML modules installed and enabled in your server. Since that’s something that always worries me, I wrote another quick script to test whether the hack would work on the server:

$functions = array('simplexml_load_string', 'json_decode');

foreach($functions as $f) {

  echo $f . ' exists? ' . (function_exists($f) ? 'yes' : 'no') . '
';

}

It should output something like…

simplexml_load_string yes

json_decode yes

Happy hacking! :-P

Fix the “fluxgui is already running, exiting” error

sole — Mon, 01 Aug 2011 06:42:07 +0000

It seems fluxgui had crashed previously, or maybe I had killed it some days ago and forgot about it entirely. When I tried to restart it, it didn’t do anything. Launching it from the command line returned the “Fix the “fluxgui is already running, exiting”" message.

Looking at the most recent version of fluxgui code, I thought there would be some sort of .pid file in my home directory:

self.pidfile = os.path.expanduser("~/.fluxgui.pid")

but I was wrong; there wasn’t any fluxgui.pid file in my directory. The git version is not the same that is published in the PPA, and as such there might have been some changes to where the PID file is saved.

I found mine was actually in /tmp, so the only thing I needed doing was deleting the file:

rm /tmp/fluxgui_sole.pid

Obviously, unless your username is sole too, the name of your file will be different, so have a look at /tmp before trying to delete anything :-P

sole@courgette:~$ ls -l /tmp/flux*

-rw-r--r-- 1 sole sole 4 2011-08-01 08:21 /tmp/fluxgui_sole.pid

-rw-r--r-- 1 sole sole 0 2011-08-01 08:21 /tmp/fluxlog.txt

Android’s activity stack and pressing HOME

sole — Tue, 14 Jun 2011 10:53:21 +0000

I was having a huge issue with the application I’m working on. The idea is to have a MainActivity and a GameActivity; when you’re in MainActivity and click on a certain button, you get GameActivity. So far so good.

The problem was that if I pressed HOME and then clicked again on the application launcher, I was brought to the MainActivity instead of GameActivity. The expected behaviour by default in Android would be to return to GameActivity, which was the top activity in the application’s activity stack. So why wasn’t this working?

After looking for hours and reading in detail everything in the documentation regarding the activity section in the AndroidManifest.xml and tasks stack, I decided to dare ask my first ever Stack Overflow question, and went to sleep.

This morning, I found that two people had answered the question already. Yay! Unfortunately their answers were only tangentially related to my question. It’s amazing how complicated human language is: you ask something, people answer what they understand–and it might be completely different to what you meant to answer.

But I had earned an student badge and five points thanks to asking a question! Yay! Awesome! My reputation had increased to SIX points! Woooo!

Encouraged by this marvelous self-achievement, I decided to further pursue my quest for a proper answer, and I began to examine the list of questions related to my question. Lucky as I was, there was a particular one that answered mine!

So I have ended up answering my first ever Stack Overflow question, but I can’t accept my own answer yet. Booh!

However since this is my blog I’ll write my answer here and you’ll have to believe it’s the right one. So there we go.

And the Answer is…

I was launching the app by using IntelliJ, and it seems it launches the application in a different way than a user, clicking a home screen widget, would launch. It’s explained in the answer to another Stack Overflow question:

This is due to the intents being used to start the app being different. Eclipse starts an app using an intent with no action and no category. The Launcher starts an app using an intent with android.intent.action.MAIN action and android.intent.category.LAUNCHER category. The installer starts an app with the android.intent.action.MAIN action and no category.

So I’ve manually killed the application in the phone, and relaunched it again from the home screen widget. Then opened the GameActivity, and pressed HOME. Now, when relaunching it the GameActivity is still visible and keeping its UI state as it was when I left it.

And I guess that the reason why a new instance of the activity was created when pressing the shortcut before was due to a different Intent being used for starting the activity.

In other words: when things go awry with your activities, make sure you kill your application and start anew, launching it from the phone and not from your favourite development environment.

Now, I’m back to the code! \o/

How to hide the camera preview in Android

sole — Thu, 07 Apr 2011 16:18:19 +0000

It actually was something that intrigued me to no end. No tutorial that I’ve read explained how to do it; there were only vague (and incorrect) mentions to not setting PUSH_BUFFERS in the SurfaceHolder, but yet there were apps who were totally hiding the camera preview, such as the famous “spy camera” style apps (those that look like an innocently looking web page but actually are recording everything). So there should be a way, and I just had to find it.

Things that do not work:

Placing the preview outside the screen, yet still in the current layout
Placing another element on top of the preview –since the preview must be a SurfaceView type of View, its behaviour is to “crop” the area of screen that is in, and draw it self. So it would be visible anyway, through the “hole” it punched in the elements on top of it.
Setting the preview to INVISIBLE or GONE
Setting the preview size to a small size of 1×1 (here’s why it doesn’t work… sometimes)

Can you think of yet another way of hiding the preview? :-D

Anyway, the solution is to follow a series of steps–it’s not a static process. Ready?

This is the solution:

Before starting the camera preview…

Set the camera’s preview display to the preview’s SurfaceHolder
Set the preview surface to VISIBLE

And after starting the camera preview…

Set the preview surface to GONE or INVISIBLE

This process must be repeated each time the camera needs to start previewing. So if you stop it for whatever the reason (e.g. in onPause), remember to repeat the “before” steps, or you won’t be able to re-start the preview again.

If you’re lucky, it will just do nothing, because since the surface is hidden it won’t trigger surfaceChanged or surfaceCreated events. In a bad case, it can even throw a huge exception in native code, and “force close” your app, which you know drives people crazy :-P

Warning, rants ahead!

I don’t know if this “show and hide” game must be played because of…

some silly restriction such as the one that mandates that camera phones have to emit an annoying shutter sound,
or if it’s just some technical restriction

The first hypothesis sounds so myopically short-sighted that it actually seems quite feasible: politicians would strongly agree on it, and programmers would just make the surface so small that no hypothetical subject would notice being spied upon. Job done.

The second hypothesis sounds equally silly: why, oh why, do we have to assign a preview surface for the camera driver to output its frames to it if we are also requesting the raw YUV420 frames too in order to decode and process them? It’s really idiotic that the camera driver has to decode the frames and scale them in order to fit into a minuscule preview surface.

But whatever the reason is–I don’t really care.

All I care about is making great stuff. And this kind of non-trivial issues prevent me from doing so.

Imagine you’re the camera driver, and you’re requested to start a preview, right? Then if you’re provided with an output surface, output your frames there, scaling as required. If you’re provided with a preview callback, then call that method and send your raw frames there as you get them. You’re only allowed to fail and crash if you don’t get ANYTHING (no surface, no callback).

It’s that simple.

It’s reasonable, and easier to program and use. And it probably uses less processor resources if only the preview callback is used, because there’s nothing to be blitted to the preview surface, no area to be invalidated and redrawn, nothing.

Now we simply need to get the Android Camera API changed, plus all the drivers in all the phones upgraded to reflect this extremely sensible and logical approach.

Oh well… sometimes dreaming is the only thing that is left ^^

Using shared network printers in Ubuntu

sole — Wed, 26 Jan 2011 12:32:13 +0000

NOTE: Full credit should go to mrdoob, who found out about this. I’m just documenting it!

Our home server is a Mac Mini running Ubuntu (yes, this one) with a RAID external disk for backups, and it’s also got a printer connected to it. We always wondered why did we have to install drivers in the rest of computers in order to print from them. It was silly: if the server already knows how to communicate with the printer, why can’t we just communicate with the server?

Turns out it’s just a problem of a checkbox not being set by default. Once it’s set, all the shared printers in the network will show up and you can send documents to them from virtually all computers!

First, go to System ⟶ Administration ⟶ Printing. Then choose Server ⟶ Settings. And when you get the following dialog, just check the Show printers shared by other systems checkbox.

If no printer shows up yet, click the Reload button (i.e. the blue round arrow which is more or less under the Group menu option in the screenshot).

And voilà, your shared network printer(s) will appear in the list of available printers. You don’t need to Add the printer, since it’s shared by the server.

Now you can print from your favourite program in your computer–just select the network printer in the printer dialog. Yay!