Quassel is a distributed IRC client. Distributed in the sense that it keeps your chat sessions on the server side: even if you get disconnected you won’t lose any chat messages. This is a nice feature for people who need to be constantly in touch with the communities.  For IRC veterans, Quassel is like the good ol’ screen + irssi combo, but with an user interface which does not require a degree in Perl scripting. This is a short tutorial for getting or building  the mobile version of Quassel, Quasseldroid for Android.

Everyone how has tried it knows that irssi or any terminal software suits very badly for mobile screens. QuasselDroid fixes this: it provides an user interface which is suitable even for touch screens. Also, with Quassel core on the server side, you do not need to worry about disconnections which often happen with mobile networks, With desktop Quassel and mobile QuasselDroid you should be able to seamlessly leave your desktop, go traveling whilst continuing the on-going dispute of the next most important internet thing with your on-line friends and foes.

This tutorial show how to get binary or source from Github and compile the project for your phone. Note that QuasselDroid is still in very early developing phase and the main purpose of this is to drive more development into QuasselDroid. Do not expect it to be ready for your specific use cases yet! Also, these instructions are tested only on Samsung Galaxy S with Android 2.2.

Quassel is originally based on Qt C++ libraries and uses Qt based serialization protocol to communicate between the server (your IRC session) and client (your phone). QuasselDroid implements Qt protocol from scratch in Java and does not use any Qt libraries on Android. There also existed a prior version which required a proxy server, but this has been fixed for now.

Getting and building QuasselDroid

Before proceeding you need

• A server which allows you to run a background process with more than hundred megabytes of memory usage
• Quassel core installed on the server side (this maintains your IRC session). Core itself comes with decent command-line help. If you get stuck ask help on #quassel channel @ freenode IRC network.
• Preferable Quassal desktop client (Windows, OSX, Linux) for ircing from the desktop

Downloading pre-built binary

Note: there exists a pre-built Android binaries for non-Android hackers. Download QuasselDroid Android binary from here. You still need to set-up the server side core yourself.

Prerequisites for building and running QuasselDroid

This is the recommend method of installing QuasselDroid if you are looking for helping in QuasselDroid development. It is not that difficult, as Android tools are quite friendly for newcomers.

• OSX or Linux (your mileage on Windows may vary)
• Android Phone (Android 2.1 or newer)
• Android SDK
• Eclipse IDE for Java Developers
• Android Eclipse plug-in (you need to install it through Find and Install updates inside Eclipse)
• Git (for OSX use Macports to install it)
• Minimal understanding of terminal and UNIX style command line

Compiling and running

Install Android SDK, Eclipse  Android plug-ins for Eclipse. Note this is several hundreds of megabytes worth of software, so be patient and entertain yourself with some cool music whilst downloading.

Install Quassel client, Quassel core and get yourself familiar with the noveau IRC experience.

Get code from Github:

git clone https://github.com/sandsmark/QuasselDroid

Open project in Eclipse. Start Eclipse, choose or create any empty directory as workspace of just choose the default one. Then choose File -> Import -> General -> Existing projects into Workspace. In Select Root Directory you need to choose a directory above Github checkout directory. Select QuasselDroid in Projects list (which is now refreshed after selecting root directory).

In this point I had to select the project, choose Project -> Clean from Eclipse menu (there were some errors popping up in Eclipse internal console).

Right click Project -> choose Run as -> Android application.

• If your phone is connected via USB Eclipse will automatically build and install APK directly to your phone
• If you do not have phone connected QuasselDroid will start in the emulator

Installing QuasselDroid

Creating a core entry

When QuasselDroid is run for the first time. press Android Menu key on the start-up screen(this was little hard to discover) and choose Manage cores. Now you need to configure quassel core for the server – for this process you should already have experience with Quassel desktop client.

SSL

Also, you might need to disable SSL support if you are running a core without SSL compiled in. Again, press Android Menu key, choose Preferences and uncheck SSL.

Debugging issues

When you run an issue and you can repeat it reliably with necessary log traces available, file a bug report on Github project page.

Android has a logging tool called LogCat, showing log output from emulator or device. You will see Android log output in Eclipse in LogCat view when

• Emulator is running
• A device is connected via USB, debug mode enabled (from system Settings menu)

Use Eclipse Window -> Show -> Debug perspective to see LogCat window if it’s hidden.

If you launch the application in Eclipse using Debug run (the bug icon) Eclipse will stop on the line where an uncaught Java exception is thrown. This is very useful for debugging crashing bugs (Android pops up force close dialog).

On the server side, you can see quasselcore output in stdout and see how the core reacts to client connection attempts.

Get developers  Subscribe mFabrik blog in a reader Follow me on Twitter

To take a screenshot

• Hold Back touch key
• Double press Home key

This feature is probably available on other Samsung Android devices, like Samsung Wildfire and Samsung Galaxy Tab.

Get developers  Subscribe mFabrik blog in a reader Follow me on Twitter

Actually this is even better than before. While developing for Symbian or Meego, I always had a cloud of uncertainty hanging over my head. My experience with Symbian had taught me to be very skeptical about the platform and Meego devices weren’t out yet(and still aren’t ). And as everybody knows, those fears got some justification by Nokia. Maybe Meego will prevail, but I’m pretty sure Android is not going to disappear very soon.

mFabrik News – download now for iPhone and Android

Why create a mobile application?

The first question is why one rather create a mobile application when the same task can be accomplished with a mobile site? Most people even prefer mobile sites over applications. From a pure engineering viewpoint, mobile applications are usually just glorified RSS readers that embed Webkit and add some native user interface bling bling over it. With an app, you are limiting your target audience, because an application is limited to one platform. Maintaining application(s) and application developers is more expensive compared to a mobile site which few (cheap) PHP junkies can throw together.

But is not always technology or price which matters. Mobile applications have prestige value – having or showing success, rank, wealth, etc. If you have a high quality brand, you probably want to have a mobile application too. When you see the brand logo swinging forth and back in an iPhone application with smooth animation running 60 frames per second, you see that it is a proper placement for the brand logo. The output is more luxury, more carefully planned, and does not look like it was thrown together by few cheap web developers.

There are even rationale reason for going after applications. First, you are in a business of making money. It is a lot of easier when the platform itself is offering you a payment solution without a monthly fees (iTunes payment). Other good reason is that there exists interaction between the application and your content beyond the browser window.  You can push messages or do things even if the user is not on your site (see more information about the push solution we implemented below).

Mobile application development and Python

As most of this post readers are probably fellow Python developers, here are some thoughts specifically aimed for them. Python itself is not a very good alternative what comes to mobile application development. Though, the application itself may not contain Python code, Python still shines on the backend side of the things. For example, we’ll hope to publish an example application using Google App Engine in the near future.

The only future proof platform where Python is 1st class citizen for building applications, is Nokia’s Meego with its Pyside and Qt bindings. Unfortunately Meego doesn’t have any shipped handsets and looks like it never will.

Android has script bindings, but they are not good enough for real application development, as interaction with the native platform happens over TCP/IP sockets. However, Android has seen some recent exciting development from PyPy project, possibly enabling native Android development for Python in the future.

iOS with Python could be a go, now when Apple has lift ban on interpreted languages. I haven’t heard anybody doing it yet, though. CTypes had some problems long time ago regarding run-time generated code for Python bindings.

Python has also a port for Series 60 (Symbian) – don’t go there if you are not prototyping. It is good platform for students for  playing around, but unfortunately it has never been considered as serious development environment by the handset manufacturer. You have tons of headaches if you actually want to release a product version of your application.  Nokia N900, soon supported. is better prototyping platform for Python than Series 60 as you get full Debian userland.

Mobile application development and wrappers

There exist various wrapper technologies which help you to wrap your HTML5 application to a native application shell. With simplistic APIs provided through Javascript bindings, you can access a limited subset of native platform APIs. Wrapper technologies are mostly aimed for web developers, who do not have any experience on application development and they might want to skip the learn experience of native development.

Wrapper technologies do their job and produce decent apps. But if you are a Python developer I recommend you skip the wrapper step and build your own native user interface and embed Webkit yourself. Designing an user interface is much is easier with Apple’s Interface Builder or Google’s  Android tools than with half-baked Javascript bindings. The fact that you are actually able to insert a real breakpoint into your code is itself worth of skipping wrappers. If you already are a Python developer you already know at least one real programming language and mastering Objective-C or Java should be an easy task for you.

Webkit itself has bugs. You will regularly hit obscrure bugs when the amount of  Javascript and CSS code grows. In the worst cases Webkit just dies under your application without a way to debug the problem – sometimes without a workaround available for the problem. This means dead end for your lovely application. You don’t want to end up to this situation. So, just to have more low level control, using native tools is good.

mFabrik News application

mFabrik News mobile application allows you to follow the latest news of mobile and web development, produced by our hacking team. The applications source the news from our Plone based web site and WordPress blog (which you are currently reading). It uses special RSS streams prepared with our Web and Mobile multichannel publishing solution: news images are optimized for mobile device screens using a handset database (Wurfl) and some other HTML preproessing is done to make the posts look better in embedded WebKit. Processing is done using mobile.sniffer and mobile.htmlprocessing Python packages which are generic Python packages and should be usable in various environments, including App Engine.

iOS mFabrik News application has push notification support. Android doesn’t yet implement push solution, but it is coming for Android 2.2 handsets.  Please see the earlier blog post how we use Apple Push Notifications with Python.

Download, give the apps a spin and report any feedback! (direct links at the beginning of the post)

We may or may not release the source code of the applications, depending if anybody thinks they actually would find it useful.

Get developers  Subscribe mFabrik blog in a reader Follow me on Twitter

Can't bind to local 8600 for debugger

To fix this do the following steps exactly in this order

• Close Eclipse
• Disconnect USB cable
• Kill all adb instances on the task manager of your computer
• Start Eclipse
• Connect USB cable
• Launch the application

If this does not help then make sure that you are using IPv4 address for localhost DNS loopback name. Edit /etc/hosts and comment out all IPv6 entries.

Get developers  Subscribe mFabrik blog in a reader Follow me on Twitter

Naturally, this Windows software 1) is not very good 2) works on Windows only.

However, you can still mount  the device as normal USB mass storage. Just set Settings -> Applications -> Development -> Allow USB debugging checkbox on and replug the USB cable. Then open the notifications menu (pull down the top bar on the home screen). Now there is new option USB Connected. Choose it and then choose Mount.

You should be able to access both the phone internal storage and microSD memory card in Finder / Nautilus.

I created directory /media/mp3 where I copied few music files from my computer. I was able to achieve 5 MB/s transfer rate from my Asus Eee 1005HA PC when writing files to phone internal memory. The phone music player was able to pick up them fine.

More info

• http://forumuk.samsungmobile.com/PostsList.aspx?ForumPostID=199886

Get developers  Subscribe mFabrik blog in a reader Follow me on Twitter

• Image uploads
• Payments for subscribed content

Sounds easy, right? Well it isn’t… Below are some notes for our due diligence work which you fellow developers might find interesting.

SDKs

Mobile phone vendors are jealously and don’t want to co-operate with each other. Building application which works in all handsets is major headache.

We found some reasonable candidates for cross-platform mobile development doing HTML and Javascript. HTML and Javascript pages are converted to native application using a wrapper technology (a.k.a. appaccelerator). Doing Flash Lite or Java ME can be pretty much forgotten nowadays as they won’t run on the most hyped platform, iPhone. Flash Lite has poor support for anything except content authoring due to primitive and limited APIs. Java ME provides horrible user experience.

(X)HTML is the only common language spoken by mobile phones. Thus, there has been a rise of “appaccelerators”, technologies which allow to create mobile applications with HTML(5) and Javascript.

• Phonegap: iPhone, Android, Blackberry and possibly S60 in the future. Pluses: BSD license, very active community. Minuses: bad documentation, difficult deployment process.
• Titanium: iPhone, Android. Pluses: Professional, Apache license. Minuses: Too tightly coupled with Appacclerator Inc. company.
• Rhomobile: iPhone, Android, Blackberry, S60, Windows Mobile. Pluses: Professional, tries to build open source community, the widest platform support. Minuses: Dual licensing and tightly coupled with Rhomobile Inc.
• Nokia Web-runtime: Nokia S60 and some other Symbian based phones. Pluses: Professional, good documentation. Minuses: Not open source, impossible to extend, Nokia has little interest to make this cross-platform, Nokia doesn’t like updating old models and web-runtime is useable only in the latest S60 5th edition models.
• Palm Pre supports web applications natively. However Palm Pre application business is still taking a shape.

All these wrap the browser component (WebKit) and provide some extra Javascript APIs when your web pages as executed under the application mode.

• Locationing
• Contacts
• SMS
• Client-side database
• and so on…

Rhomobile has little different use cases  from the rest of the bunch as it provides client-side programming using Ruby and less focuses on Javascript/web applications.

Payments and in-application purchases

There are four major way to do mobile payments “inside” the application for bought content and subscriptions. The price tag on the application itself is left out on this discussion as the application stores themselves take care of it.

• Credit card
• SMS
• App Store payment (thus far Apple only)
• Direct operator payments – you have a service provider (Bango) which can directly charge items to the operator phone bill based on handset identification.

App Store payment is the most attractive as it provides the best end user experience.  It allows you to use App Store payment mechanism inside the application. It is safe and no need to hassle with external payment providers. However, App Store payment can be used only for content consumed directly inside the application. You cannot use it e.g. for ordering a pizza. I think this might be related to recent EU legislation forbidding SMS payments for services not consumed in the phone itself.

SMS payment is ok for little payments. Operators take big cut of the revenue, generally 30% – 70% depending on the country. Short code fees usually start from 500€ set-up fee + 500€ / month. SMS cannot be often send as a background, but the user is presented the normal SMS editor which reduces the user experience somehow.

For credit card payments there exists several providers. Credit card has the cheapest entry fees, but the downside is that the user needs to have the credit card. This excludes teenager audience.

Direct operator payments are not very well supported yet globally. Most western operators support them. The operator also takes a big share and the fixed fee is pretty high.

My favorite payment provider thus far is Bango which provides credit card payment starting 9€ / mo. and scales up to worldwide SMS payments which cost few grannies per month.

In most cases, the payment experience will not be smooth. You need to open the phone main browser on the payment provider page to do the payment. This usually will close your own application. Rarely you can do the payment inside the application and support multiple platforms. After doing the payment most platforms allow you to close the browse and reopen your application using a special URL handler.

Wikipedia mobile payments page is also useful.

Image upload

<input type=”file”> won’t work on iPhone and some other platforms as those don’t have user browsable file system. Also the file dialog usually doens’t have image preview making it useless.

Phonegap has a branch which supports images picking using iPhone’s own gallery browser.

In any case, there is not yet cross-platform solution for this.

Future prospects

In some time-frame we will get rid of the need to wrap HTML applications natively as the web browser applications will support all HTML5 features without extensions and probably have some proprietary extensions for mobile specific features like SMS. We already have had some taste for this:

• The first taste of this is Mozilla’s Fennec mobile browser which has locationing support.
• iPhone’s Safari already supports client-side storage and CSS3.
• All phones have support for dial-in links. The format of the link may vary. DeviceAtlas is good place to hunt for this information.
• Nokia browser supports send SMS links
• Nokia browser supports downloadable map markers (to the map application of the phone itself)