Posts tagged ‘android’

Building a Python Kivy App in Android (Easier than it looks, but harder than it needs to be)

When I introduced Kivy a while back, I mentioned that I had not been able to deploy a Kivy app on Android. I’ve managed to do this now, using the VirtualBox image provided by the Python For Android project. Using this image was substantially less work than trying to figure out how to install and set up all the prerequisites under Arch Linux. So here’s how to do it:

First download the VirtualBox image from Google Drive. Sadly I cannot find an adequate wget command to download this. Shame on you, Google!

You may want to double check the documentation to see if a later image has been made available.

It’s a big honkin’ file (1.4GB), so grab a cup of coffee, lunch, or go to bed, depending on your bandwidth and the current time of day.

Extract the file using p7zip. This takes a while, so you might want to grab another coffee:

7z e Python\ for\ Android\ -\ Ubuntu\ 12.04.7z

Make sure VirtualBox is installed and the kernel module is loaded. The commands on Arch Linux are:

pacman -S virtualbox virtualbox-host-modules
sudo modprobe vboxdrv

Fire up VirtualBox and hit Machine->Add.

Navigate to the folder the vbox image was extractedto. Select the Python for Android - Ubuntu 12.04.vbox machine and hit open.

If you have enough RAM, select the Python for Android machine and hit settings. Browse to the System tab and increase the RAM to a comfortable level (I set it to 2GB on my 4GB machine). You might also want to increase the number of processors and the video RAM. Hit Start to power on the machine.

Once Ubuntu has loaded, review the README for some important information. You may want to update the VirtualBox Guest Additions install, although I’m sure it will work fine without it.

Now you’re ready to build an APK from a Python project. Open a terminal from the menu on the sidebar. The first thing you’ll want to do is update the python-for-android project to the latest git checkout. This is a bit messy because there are a couple edits in the current checkout that were later fixed upstream. So you’ll want to stash the changes before pulling:

cd android/python-for-android
git stash
git pull
git stash apply

Unfortunately, this introduces a merge conflict in distribute.sh. The upstream project has made some of the customizations obsolete by including more generic code. Luckily, it’s a trivial fix. Open distribute.sh in an editor (gedit distribute.sh works, but I used vim.) and search for the characters =======. It’s at line 170. Delete the line above that says <<<<<<< Updated upstream. Leave the export line that was above the =======. Then delete the ======= and >>>>>>> Stashed changes and the outdated export line in between. Save the file and close the editor.

Now you need a Kivy application to install. Presumably you’ve written your own, but for this example, I’m going to use a cool one supplied by the Kivy team. The Kivy Remote Shell creates an ssh server on the phone that allows you to log in from your computer over ssh and execute Python commands on the phone. You can even run Java commands using the beta pyjnius connector.

These commands will prepare a python for android distribution ready for installation:

cd ..
git clone git://github.com/kivy/kivy-remote-shell
cd python-for-android
./distribute.sh -m 'openssl pycrypto pyasn1 pyjnius twisted kivy'

This will prompt to see if you want to overwrite the previous python for android distribution. Press <enter> to do so. Give it some time to connect to the network, download the dependencies from Pypi, and compile them.

Now you need a rather ugly command to actually build the apk. The options are summarized in the Python for Android documentation.

cd dist/default
./build.py --package org.kivy.sshshell --name "Kivy Remote Shell" \
  --version 1 --dir ../../../kivy-remote-shell/ \
  --icon ../../../kivy-remote-shell/icon.png --permission INTERNET debug

This will create the file bin/KivyRemoteShell-1-.debug.apk. Now let’s install it to the phone! First make sure USB debugging is enabled on your phone. Go to the Settings-->Developer Options menu and make sure Developer Options are enabled and that Android Debugging is enabled.

Plug the phone into your computer via the USB cord. Click the little “USB” icon in the VirtualBox status bar and check the box next to the name for your phone.

Run the command ~/android/android-sdk-linux_x86/platform-tools/adb devices to make sure it outputs the identifier of your phone. If it works, simply run ~/android/android-sdk-linux_x86/platform-tools/adb install bin/KivyRemoteShell-1-debug.apk to install the app.

(If you can’t get the phone to connect to the VM, you can also copy the .apk to the host machine to install it. Use VirtualBox’s shared folders feature).

You can now shut down the virtual machine from Ubuntu’s shutdown menu. For security, it’s a good idea to turn off USB debugging on your phone until you need it again. Run the “Kivy Remote Shell” app that is now in your phone’s app drawer. Type the command that comes up onto your screen into a terminal on your computer, and you will have access to a Python prompt running on your phone!

This same process can be used to install self-developed Kivy apps to your phone. Congratulations!

Python on Android? First impressions of Kivy

Kivy is a modern cross-platform Python GUI toolkit that runs on mobile devices (Android and IPhone) and supports modern input events (multitouch, accelerometor). I was really skeptical at first, but I spent the weekend developing an app in Kivy, and now I’m hooked.

In the past, I have tried most of the available Python GUI toolkits (even Swing, through jython). In recent history, I’ve mostly done HTML based interfaces, partially because that’s where the money has been, but mostly because pyQT, pyGTK,wxpython, and tk are all painful to work with.

In Kivy, interfaces are defined in a language called (aptly) the Kivy Language. The best way to describe the Kivy Language is “what HTML5 wishes it was.” It is mostly just a layout language, but it also supports binding properties and events using inline Python snippets. It is indentation defined, like Python, and utilizes a minimal amount of syntax with a maximal amount of readability. It is vaguely reminiscent of CoffeeKup but cleaner, and doesn’t suffer from having to be compiled to HTML. I love how it mimics Python syntax, but also clearly separates presentation from control code.

My favourite feature of Kivy is that properties are events. You can easily hook a property on one widget to the property on another. For example, I wrote a simple demo that connects the value of a slider to the value of a progressbar:

BoxLayout:
    orientation: 'vertical'
    ProgressBar:
        id: bar
        value: 14
        max: 20
    Slider:
        id: slider
        max: 200
        value: 140
        on_value: bar.value = self.value / 10

When the value property on the slider changes (whether because the user moved the slider, or because it was adjusted programmatically in response to some other event), the on_value event is fired. This is connected to the value of the progress bar using a Python snippet.

Only a few lines of Python code are required to to get a Kivy application running once its interface has been defined in Kivy language. The Kivy Hello World example is actually overly complicated because it doesn’t actually use the Kivy language. The bare essentials, if the above file is named sample.kv is:

from kivy.app import App
class SampleApp(App): pass
SampleApp().run()

Just three lines of code. Kivy introspects the class name (convention over configuration) and automatically loads sample.kv as the interface for a class named SampleApp.

The Kivy API is very simple. In fact, my earliest impression was that it was almost amateurish. It felt like if I wanted to do anything serious with it, I’d be disappointed. It’s the kind of API I would teach a child. However, the few features of the API (basically properties, events, and graphics instructions) are extremely well thought out and well-defined. They can be combined like Lego bricks to create widgets as complicated as one could possibly wish. The fact that the library includes a ReStructured Text rendering widget is testament to that fact!

Kivy is extremely well documented. I actually found their pong tutorial exciting. Seeing how simple it was to do each step actually made me giggle out loud. The programmer’s guide and API are well presented as well. Further, if you get stuck, the developers on IRC are terrific. I felt like I was an accepted member of the team after asking only one question.

Drawbacks

It took a bit of fiddling to get Kivy to install correctly under Arch Linux. I suppose if I’d followed the instructions, all would have been well. However, I like to do all my development in a virtualenv, and there is no trivial way to track down and install all Kivy’s dependencies. This is especially compounded by the fact that pygame currently needs to be patched under Arch in order to compile.

There are instructions for packaging your Kivy app onto Android, but I wasn’t able to pull it off, yet. I’ll have to revisit it when I have more time.

I tried some sample Kivy apps in the Android market. They work just fine once they are loaded, but it takes each app several seconds to initialize on my Galaxy Nexus. Hopefully the Kivy team can reduce this load time. I don’t know if Kivy supports displaying a splash screen while stuff is loading; that would certainly enhance the usability.

Most of these issues are solvable. I’m sure the team is actively working on some of them. Kivy is a quite young project, but it is remarkably mature.

Kivy Catalog

My weekend project was the Kivy Catalog, an interactive showcase of Kivy widgets. It allows you to view the Kivy language code used to define the widgets and to edit it and see what effects your changes have. I think it will be a tremendous aid to users looking to get started with the Kivy language. Developing it certainly was for me!

I am expecting to have this code included with the Kivy distribution in the examples directory in a future release.

My first Blackberry

I don’t often post reviews of hardware. However, RIM is getting a bad rap lately, and all the cool kids are using Android or IPhone these days. I have been severely disappointed with the three Android phones I’ve had to date, and I have had too many bad experiences with touch keyboards to take the IPhone seriously. That left me with a choice between a Nokia Windows device or a Blackberry. I purchased the Blackberry Curve 9360. I wasn’t expecting much, but having used it, I don’t think I’ll ever go back.

From all the market hype, I expected the Blackberry to be inferior to Android. My expectations were therefore blown away. This is hands down, the best device I have ever used. Unlike Android, everything just works, and there are no force closes. The battery lasts a good 2.5 days under normal usage, compared to less than a day on my Android devices. RIM has put a LOT of thought into their OS design, and everything just flows. This phone is a joy to use, instead of an irritant.

The Curve doesn’t have a touch screen, but I never miss it. I’m willing to say, in fact, that the trackpad is a superior method of input for serious usage. Granted, a touch screen is great for mobile games, but I don’t waste time with that sort of thing. While pinch to zoom action on maps and images is quite pretty, on my Android phones it tended to be flaky and annoying (I’ve heard this is not the case on iPhones). One click zooming on my blackberry is more effective.

Actually, I did miss the touch screen when using my web browser at first. Trying to use the trackpad as a mouse was irritating until I increased the sensitivity. Now that the cursor moves as far and fast as I expect it to, I’d say that the interaction is about comparable to touching links and buttons. The touch action is more intuitive overall, but I used to find under Android’s browser that 1 time in 3 the phone would activate a different link from what I had thought I touched. The trackpad pointer never does this. The tradeoff leaves me sitting on the fence; either method works, but neither is optimal.

Of course, there are Blackberry devices with touchscreensI originally wanted to get a Torch 9810 to get the best of both worlds. I doubt I will do that when I upgrade, simply because I’ve unexpectedly proven to myself that the touch screen is not the wonderful idea that Steve Jobs told us it was.

The Blackberry OS 7 is extremely responsive, even though the Curve hardware specifications are modest compared to high power Androids, or even higher power Blackberries. I never have to wait for text to show up on the screen or for activities to complete. The tools that Blackberry is known for, namely messaging and email are even more pleasant to use than I had been led to expect.

The Blackberry market app is a bit of a disappointment. It doesn’t seem to find apps that I know exist, and I normally find it easier to search google on the phone and install an OTA link than to download through the market. Another annoyance is that you need to perform a Windows-like reboot whenever you install new apps. However, this is a rare task for me; I have never been one to download a lot of apps. On my Androids, I tended to replace the stock apps with sexier ones from the Android market (The Go dev team’s contacts, messaging, launcher, and other tools are particularly nice). I feel no need to do this under Blackberry; the stock apps are too good to replace. I have heard there is a lack of selection of Blackberry apps, but I personally haven’t missed it. To be honest, the argument that Android has a much bigger selection of apps in its market is severely watered down when you realize that many of these are fart sound boards or sexy lady wallpaper collections.

The Curve’s camera takes very clear still pictures. The flash is small, but indoor shots seem to be high quality. Digital camera technology is pretty much a solved problem these days; I doubt that any one phone is going to outperform another in this regard. I haven’t bothered with the video camera, so I don’t know how it compares.

Call quality is definitely clearer on this phone than any other device I’ve ever used, including landlines. I have no idea what sort of noise cancellation or other technology is involved, or if the towers in this area have been improved since I last used them. I know they’ve been updated to 4G, but I don’t know how that is expected to affect call quality. I like that the phone usage is a single button press; it highlights that the dialer is not just another app on the phone. I’ve had Android get stuck in another app when trying to answer an incoming call. This doesn’t happen with the Blackberry; calls take priority.

All the reviewers that say they are far superior to any other hardware manufacturer’s keyboard are understating the truth. In just a couple weeks of usage, I am already more accurate than I have been on any soft or hard keyboard on the Android devices I’ve had. I’m also quite a bit faster. Typing an e-mail on a soft Android keyboard used to be annoying enough that I’d wait until I was sitting at my computer. The two Android hardware keyboards were much better, but I could easily write entire book chapters on this phone if I wanted to. The keys are easy to press and give a satisfying click on each keystroke. The keys seem deceptively small, but are easy to locate and press. It took a bit of practice to get used to the keyboard. I was dissatisfied at first, but if you use a BlackBerry phone for more than a day, the learning curve is gone. Compared to the three months I spent trying to learn a soft Android keyboard, this is exceptional!

One other thing I like about the phone is that it acquires a wireless connection in almost no time at all. My ancient laptop takes a couple minutes to connect to a WPA protected network, and my Android phones have all been equally slow. But the Blackberry, for some reason, can do it in no time at all.

I don’t want to be sounding too harsh on Android. If you like Android or like Google’s offerings, than by all means, stick with it. However, if you’re like me, and stumped for a good alternative, don’t let the negative media attention RIM has received fool you. This is a high quality piece of hardware running a high quality collection of software.

Quodroid, an app just for me

I’ve spent a few days reading through the Android developer docs and trying to get Eclipse to cooperate with my outlook on software development. It took giving up on Eclipse to get any real coding done. It was a bit tricky, as I’m not the all-star Java programmer I once was, and I got bogged down on silly syntax errors and library issues. For example, I forgot that ‘new’ is a keyword in Java, and trying to instantiate a class without it results in errors that don’t say, “what do you think this is, Python?”.

The pet project I started is an extremely simple music remote control to interact with Quod Libet, my music player of choice, running on my laptop. So now if I have my phone at the couch I don’t have to get up and walk six steps to my desk to pause or skip to the next song.

The overall architecture is mildly embarrassing, but works well. I’ve got a very simple web.py server running on my laptop that accepts three urls — prevous, next, and play-pause. When one of these is received, it sends a control command to quod libet to perform the associated action. The android client simply displays three ultra-ugly buttons that send requests to a (hard-coded, no less) IP and Presto! I can skip tracks and pause my music!

It’s barely working yet and the design is atrocious, but I’ve posted the initial version to github for peer review and patches storage.

I really just wrote this for myself, the fact that I’m releasing it is mostly because a) I have a blog now and b) I have a github account now.

I’ve got several things on my to-do list, most importantly improving the client interface. I want to add volume control as well, and the ability to return the current song whenever an action is invoked. I might even add a polling feature to update the displayed song on the phone. I also need to do some config stuff, hard-coding the url may actually not be that flexible.

Todo List

I’ve spent a lot of time thinking about the proper way to design a calendar and to-do list application.  The irony: I never got around to putting ‘write to-do list application’ on my to-do list.

The best to-do list I’ve seen was designed by Kim Hoyer with input from myself and another developer. Its part of Kim’s proprietary Pursuits XRM System, a comprehensive sales and company management system. Oprius also has a terrific to-do and appointment management system. Google’s Calendar, on the other hand, seems to have done everything all wrong, by my standards.

I’ve read about several of the web-based options and discarded them for various reasons, usually too much complexity. Remember The Milk is a notable exception in that its complexities can be easily ignored. However, its still due-date based, and that’s not the way I work.

Stephen Covey’s well-known ‘The Seven Habits of Highly Effective People’ describes a slightly over-engineered, but otherwise workable paper-based to-do system that really jives with the way I think.

I’ve tried numerous solutions and always fall back to writing stuff on a scrap of paper. I’ve been actively monitoring exactly how I really do things (instead of trying to imagine how I should do things) in the 5.5 months since getting a day-book for Christmas. I’m ready to design a to-do list. I’d probably have sat down and started coding by now if I didn’t have this blog thingy to lay out some ideas. Just a little groundwork.

Day-oriented, not due-date oriented

When I plan what I want to do, its always about what I want to do today. I don’t care that the due date of a task is in two weeks, I care only about choosing whether I am or am not working on that task today. When I’m done working on the task today, I cross it off my todo list, even if the task isn’t complete. If its not complete, I add a NEW task for the next day. Its good to break big tasks into bite-sized sub-tasks, but often I just write the same task down for each day that I work on it.

Only plan a few days in advance

I need to be able to add, reorder, and move tasks between all days, but typically I won’t have tasks listed for something more than a week in advance. Unless I’m specifically meeting someone or planning a vacation, I don’t have stuff filled out for two months from now.

Area for planned but scheduled tasks

I currently add tasks I intend to do in the future for other days and then ‘move’ them by crossing out and rewriting under another day. This is suboptimal. I want a separate section for tasks that I don’t want to forget. It needs to be easy to move them into a specific day.

Recurring Tasks Suck

Most of the tasks I do on a recurring basis don’t happen at the same date and time each week. I just know I need to do them once a week. Having them auto occur makes me easily ignore them.

Instead, I need an area (possibly same area from previous point) to store tasks that I do repeatedly. These would be generic tasks and whenever I need to put one on a specific date I can just select it and add a date.

Super minimalist

I don’t need to attach much info to a task. I don’t need priorities, descriptions, notes, durations, locations, contacts. This shit clogs up the interface and the task name itself usually helps me recall all I need to remember about this stuff. Maybe if I was a sales person with 90 contacts per day that I can’t remember their names and faces I’d need those details, but in my life, its just extra cruft.

Task Ordering

On any given day, I want the completed tasks at the bottom of the list. Uncompleted tasks are at the top in a semi-ordered fashion. Currently when I sit down at my daybook, I cross out the last item I did and pick another one based on my current priorities. Sometimes I draw numbers beside them to note the next three things I’m going to do. In software, I want to use either drag and drop or tap-to-raise to easily order the next few things I plan to do. When I finish one, I want it to be easy to change my mind about what I’m doing next. Keep it agile!

My Phone

I expect I would make this a web app in the long run so I can access it anywhere, but I definitely need to be able to access it on my phone (Android Dev Phone). Since I want to play with the android APIs anyway, my first attempt is going to be for Android. Later I’ll tie it up to a mobile-oriented webapp similar to Choncho.