Blogging to Nowhere

cat /dev/brain > /dev/null

SwallowCatcher 0.1.1 Released

Download SwallowCatcher 0.1.1

Download SwallowCatcher 0.1.1

Today sees the release of the second version of SwallowCatcher, version 0.1.1. This version contains many enhancements and bugfixes over the previous version and should so be considered as the main stable release for the 0.1.x series. Further releases in this series will contain bugfixes, with new features being added to 0.2.x.




Obligatory release notes:

Features:

* Import Podcasts from OPML;
* Add Podcasts Via Barcode or URL;
* Open podcast:// and feed:// URLs directly in SwallowCatcher;
* Download Podcast feeds;
* List newly found Episodes;
* List Subscriptions and Episodes;
* Download Podcasts;
* Share via intent (and thence via email, mustard, etc.).
* Basic playback support.

Fixed Issues from Previous Version:

* New episodes screen issue;
* Can now add podcasts directly by feed URL;
* Added basic playback support;
* Prettier downloads list;
* Podcasts list remembers scroll position;
* Fixed text on the first run dialogues;
* Fixed OPML import from Google Reader;
* More robust feed/date parsing;
* Lots of general stability fixes;
* Much improved UI with more options, etc.

Known Issues:

* Downloads still aren’t pausable/resumable;
* I need some icons!

Future Plans:

The 0.1.x series will continue to address the remaining issues above and fix bugs.
The next main release (0.2.0) will include cover art and show notes support.

SwallowCatcher is still not in the Android Market so either download above or check out the project page and the gitorious page where you can download the source code. Feedback and bug reports can again be submitted via identi.ca, email or via the comments on this post. No Spam please (only ham and eggs).

SwallowCatcher 0.1.0 Released

Download SwallowCatcher 0.0.1

Download SwallowCatcher 0.0.1

I’m very proud to announce the first release of my project SwallowCatcher. This is a project I’ve been working on for some time, but I haven’t blogged about it because I wanted to have something to show for it before I did. To quote the project page, SwallowCatcher is…

A FOSS Podcatcher for Android. SwallowCatcher wishes it was written in Python, but it isn’t. No coconuts were harmed in the making of this Podcatcher.

The naming and general theme is inspired by Monty Python and the Holy Grail, with the release codename for the 0.1.x series being “Bravely Bold Sir Robin”. Subsequent releases will follow with names of other characters from the film.

Right now it’s very rough, as the obligatory release notes state:

Features:

* Import Podcasts from OPML;
* Download Podcast feeds;
* List newly found Episodes;
* List Subscriptions and Episodes;
* Download Podcasts;
* Share via intent (and thence via email, mustard, etc.).

Known Issues:

* The new episodes screen has issues marking multiple episodes as old;
* Can’t add a podcast directly by feed URL yet;
* Can’t play from inside app (need to use external media player app);
* Downloads list is ugly and can’t be cleared;
* Podcasts list doesn’t remember scroll position;
* Downloads aren’t pausable/resumable;
* The text on the first run dialogues is too big;
* The GUI sucks and there really aren’t any options for anything;
* I need some icons!

Future Plans:

The 0.1.x series will focus on addressing the known issues above. The next main
release will start adding new features such as cover art and show notes support.

Anyway, if you have an Android phone then please give it a try. Right now it’s built for Android 2.2 and above, because that’s what I’ve tested it on. Currently its not on the Marketplace due to lack of icons. Also, check out the project page and the gitorious page where you can download the source code. Feedback and bug reports can be submitted via identi.ca, email or via the comments on this post. Enjoy!

Calculating Alcohol By Volume in Python on Android

Wow, I just managed to combine three of my favourite things in a single title! Recently, I’ve been getting further into home brewing, with a book I received as a Christmas present (Home Brewed Beers and Stouts, by C.J.J. Berry). Since I’d never actually measured the Alcohol By Volume (ABV) of my beer I decided to write some Python code to automate the process. The simple modules I came up with work from the command line and also on Android phones via SL4A, which makes them very useful when doing quick measurements.

Measuring ABV involves taking Specific Gravity (SG) measurements at the start and end of fermentation, adjusting them for temperature and pushing them into a simple formula. The SG measurements are taken with a Hydrometer, which is supposed to read at 20C (hence the need to adjust for other temperatures).

The temperature adjustment is done via a simple table (which I took from the book). In the script I used Linear Interpolation, to adapt it for values which weren’t available in the table. Initially I used the numpy.interp() function. However, I found that numpy isn’t present in SL4A and that installing it would be a pain since it is a C module which would need cross compiling for Android.

I therefore wrote my own interp() function, which keeps the same interface:

def interp(x, xp, fp):
    i = 0
    for p in xp:
        if p > x:
            i = xp.index(p) - 1
            break
    return ((x - xp[i])*fp[i+1] + (xp[i+1] - x)*fp[i]) / (xp[i+1] - xp[i])

I split up the code into two separate modules, sg.py (which just does specific gravity adjustment) and abv.py (which does ABV calualation). Splitting the code up enables me to take SG measurements and adjust based on temperature, without doing a full ABV measurement. In sg.py the reverse adjusted SG is what you would need to read from the hydrometer at the specified temperature, in order to achieve the adjusted reading you specified.

Since the calculations are fairly trivial the main bulk of the code is in the user interfaces. I implemented a simple command line interface which either takes arguments from the command line, or prompts the user via the python input() function. I also use the SL4A API to implement a simple UI for Android, basically the user is prompted for each quantity by a dialog box.

Anyway, there’s not much else to say, except that I’ve put the code up on Gitorious for anyone who wants it (it’s licenced AGPL). The code is in a git repository for useful Python scripts I’ve written, right now it’s the only thing there, but I’m going to track down some of the scripts I’ve written over the years and add them too – I might even get a few blog posts out of some of them!

On Language/Platform Restrictions…

Editorial Note: I know I said I was going to have a Kiwi Pycon Roundup, but I’ve been really busy recently. I’m now going to wait until the conference video/audio is posted then I can give a proper roundup and post people to the talks I found particularly interesting.

OK, today I’m having a rant. This isn’t going to be an ill conceived rant about a company, like my last one. This one is about something of a general feeling that I’ve been getting recently. I want to talk about what I call Language/Platform restriction (I’m open to a better name). This can best be described by taking an example, the best of which is Android.

So, you want to develop an Android application, but you’ve got no experience in this area. So what do you do? You head over to the Android Developer site and read some of the tutorials and documentation. To your dismay you find all the code is in Java, but you’re a Python programmer. There doesn’t seem to be any way to use your favourite language on Android, despite everyone claiming that Android is an open platform.

Granted, this example is a little contrived. The chances of any developer not knowing that Android is a Java only platform are pretty small. This isn’t even my own experience as I’m pretty good with both Java and Python (though Python is my favourite). I guess my point is that developers have preferences over which language they like to use and that these preferences seem to be being largely ignored.

Now, Android does have a working Python implementation as part of the SL4A project, but this is very much a scripting environment not an application development environment. There is no native access to the Android APIs that are required to develop a fully fledged application. Also, in my opinion its usefulness as a scripting environment is limited by the lack of a Free Software cron equivalent, to run scripts automatically.

Lest you think I’m picking on Android, this problem isn’t specific to that platform. It’s also present on The Web. “Oh No!”, I hear you cry, “The Web is an incredibly open platform, you can use any language you want!”. In some ways this is true, on the server side, yes you can pretty much use any language you want (I’ve never seen any web apps written in assembly, but I’m sure it’s possible). The client side is another matter though.

If we restrict ourselves the technologies which make up “The Open Web” (basically ignoring Flash and Silverlight), we really only have one option: Javascript. Now, Javascript has historically been a complete mess. Granted it’s getting a lot better with HTML5, but it still kinda sucks. It doesn’t have any proper OO (please don’t offer up that “a function is an object” crap, as a sorry excuse). It’s still pretty low level, certainly compared to Python and it seems to be “the language which syntax forgot”.

This worries me. It actually worries me more than the Android situation. The reason for this is that I think The Web is going to be the main application delivery platform going forward and that Free Software needs to seize on this to create a suite of Free cloud applications, just as we have for the desktop. However, the lack of a choice of languages puts me (for one) off.

There have been efforts to port Python to the browser, specifically Pyjamas and Skulpt. There are problems with both these implementations. Pyjamas is too tied to its own application framework (which come from Google Web Toolkit) and it basically ends up bringing desktop like application programming to The Web. Maybe this isn’t a bad thing, but it seems to miss the full potential of The Web. Really what we need is something that takes advantage of all The Web’s APIs, but without having to use Javscript. Skulpt, although initially promising, does the compilation from Python to Javascript on the client side, thus multiplying the overhead in doing so by the number of clients (granted its distributed, but it still seems wasteful when this only needs doing once).

I should also take a minute to mention Google’s Native Client plugin. Although its not really part of the standard Open Web technology suite, it is trying to expand beyond what Flash and Silverlight offer. Basically it’s a way to run native x86 code inside a web application and expose methods through a Javascript API. You can potentially run anything in there. There are some continuing efforts to port Python to this platform, but I think this is the wrong way to go too. It’s not really intended to be a full runtime, its more like a sandboxed version of ctypes for Javascript.

In both these situations (Android and The Web) the best option is for native support for other languages to be added directly to the underlying virtual machine. However, this doesn’t look like it’s going to happen any time soon, so we might need some other solutions. Pyjamas and Skulpt have demonstrated that it’s certainly possible to compile Python to Javascript so I think that’s a low hanging target. I haven’t seen anything more promising than SL4A for Android yet, and porting dynamic languages to run on Dalvik strikes me as much harder (given the static nature of Java).

Throughout this post I’ve kind of focussed on getting Python to run on other platforms, but what I’ve said pretty much goes for Perl, PHP or any other language. If anyone has any thoughts on this topic, or details of other projects I should check out, please get in touch. My main fear is that we’re going to end up with a situation where there is not choice of programming languages for any given platform and that some of the best languages will be left out in the cold.

Denting via Android Intents

This is just a quick post to share something cool that I was playing with the other day. I was wondering if it was possible to send a message from an Android application via the Mustard identi.ca client. It turns out it is, and here’s how you do it:

Intent i = new Intent(Intent.ACTION_SEND);
i.setType("text/plain");
i.putExtra(Intent.EXTRA_TEXT, "Testing intents on android");
startActivity(i);

These four lines of code hook into a key feature of the Android platform: Intents. The intent system is a neat way of communicating via apps and enables different apps to integrate together without knowing about each other specifically.

In this case, we are sending the ACTION_SEND intent, which Mustard is set up to handle. We set the mime-type of the message to ‘text/plain’ and put the contents of our message into the EXTRA_TEXT field. We then start the intent, and we’re done!

When the intent is started Android presents the user with a list of all the possible applications which can handle the ACTION_SEND intent. In my case this is Email, Gmail, Messaging and Mustard, when I select mustard the new message screen pops up and is populated with my message content. Hitting send posts the message and returns control to my app. Neat!

There are probably a whole host of ways you can integrate your apps with other apps on the phone using the intents system, I guess it’s just a matter of knowing what intents are received by each app and what they do.

Thanks to @macno (main developer of Mustard) and @bugabundo on identi.ca for their help working this out!

Anyway, I hope someone finds this useful. This is the first time I’ve posted about Android development, but I’ll hopefully write more about it in the future. Bye for now!

Bad Behavior has blocked 23847 access attempts in the last 7 days.