I can haz commit access and other updates

I can haz commit accessIn this week’s update on Kivy and Plyer, I have been granted commit access to the repository. Yay! And thanks everyone in the community for considering me responsible enough 😛

As a result I did some obligatory maintenance work and clean up the repo post my code merges. Doing that I also realized that we need a git hook to do all code style checking before any push. I think the standard Python PEP8 checker should suffice. I will work towards adding it in the coming week.

Also, I worked on a new battery status facade on Plyer. I have implemented the lowest common denominator set of features for now and we can query whether the device is connected to a power supply and its battery’s charge percentage. I also have access to some platform information which can be added as well if need. May be under extras or a specially marked category.

If you have been following my updates, you’d have noticed that I haven’t made much progress on iOS as yet. This is because we haven’t had any success running Kivy on a simulator and I don’t have access to a real device. Brousch and I have decided to get community help for any tips on this issue.

Mid-summer Progress on Kivy and Plyer

This week I worked on retrieving a Unique ID depending the the hardware your program is running on. This involves querying some platform specific unique IDs that are suitable for this purpose. For example, you could use the IMEI number on an Android device or the serial number of the machine when running on a desktop. While none of these methods are foolproof and can be spoofed, they can still be useful in primitive fingerprinting and probably even seeding a random number generator. You can check out my pull request here.

The week also marks the end of five weeks since I have started working on the Kivy project. I have been making steady progress towards improving Plyer, a cross-platform library to handle all the common platform dependent things you need while writing python applications that can run on Android / iOS / Linux / Mac or Windows.

Here are the links to my previous blog posts describing my progress each week:

  1. Kivy for all your GUI (or NUI) needs!
  2. Kivy Updates from the First Week
  3. Mid-Midterm Activities on Kivy, and
  4. PyJnius to rule them all!

I started my work with a critical bug that was blocking further progress in the first week. Although it is only recently that Inclement has been able to propose a fix for it, we were able to find a quick work-around that did not stop the development on Android platforms.

I also did some review of existing pull requests in Plyer that were pending to be merged. I also implemented the accelerometer facade on MacOS by writing a small library using ctypes to make the API calls. I then re-wrote some of the existing sensor facades on Android using the support provided by the PyJnius project. This made access to the platform specific APIs more simple and very clean. We decided against using the sl4a compatibility layer and stick with using Pyjnius for accessing Java classes on Android.

You can find a list of all the pull requests in Plyer here. In summary, these are the facades that were either added, modified or reviewed since the beginning of the project:

Platform Android iOS Windows OSX Linux
Accelerometer X  X  X
Camera (taking picture) X X  X  X
GPS X X
Email (open mail client) X X X X
Vibrator X
SMS X
Play Sound X X X X
Compass X X
Gyroscope X X
Unique ID X X X X

I also added some example applications using Kivy to demonstrate the use of these facades. And also made a point to include one with most of the new facades that I wrote.

I believe that I have made some significant progress till now but there are still some tricky facades that are left to be implemented before the end of summer. I hope to carry this momentum forward and add many more facades in the coming weeks.

Kivy Plyer Updates

This week I looked into a pending facade’s implementation on Mac and worked on some new ones as well. In other news, we have a functional #plyer channel on Freenode. It is not very active at the moment but is fully equipped with all the basic amenities (:D), ie. logging and a google-group to contact the folks offline. The idea behind making a separate channel was to reduce the noise on the main channel and also allow the relevant people to focus on project specific updates here.

We have had a camera facade in the queue for quite some time now. We wanted to model something on the lines of what is available on Android OS. It should provide a simple API to  capture a picture from the default camera on the platform. We had tried two different unsatisfactory approaches previously and were on the lookout for a lighter (without many dependencies) method to get it working. I am of the view that we could do with tools in the public-domain like ImageSnap, for each platform. This is in line with the Plyer’s philosophy of trying not to re-invent the wheel and use external libraries wherever possible. I have created a pull request to get feedback on this approach and I am waiting to hear back on this from the community.

The other new facade that worked on is called “Play Sound”. As its name, it would be used to play a short clip of an audio file on command. It also relies on existing standard libraries and tools. I have made use of the Sound Pool API on android, NSSound on MacOS, WinSound on Windows and on Linux, I launch a command line player (play or aplay) for now. I may update that in future if I can find a better method to achieve that. Here’s a link to the PR.

I think slowly and steadily I have been reaching my mid-term goals and have been checking off items in my easy list. I think now would be a good time to gather some feedback on the PRs I have proposed till now. Some suggestions on them would help fix any issues with them and continue with new facades.

PyJnius to rule them all!

Last time I described how I would be rewriting some of the Plyer facades. I had some confusion about the how to go about this after listening to varying opinions from different Kivy community members. I even had a plan to study the sl4a style of doing things.  But finally after a discussion with  tito [1] and the rest of the group, we decided to drop that approach altogether and stick with using Pyjnius on Android.

In my introductory post to Kivy, I had described the motivation behind the Pyjnius project:

 … a Python module to access Java classes as Python classes using JNI. The idea behind Pyjnius is completely different from other frameworks offering similar functionality of providing device independent access to hardware features. Instead of having to write specific “interface” code using Android SDK to make calls to the device APIs.

Pyjnius let’s you autoclass any of the Java classes and even implement abstract classes that act as API interfaces. To illustrate this with an example, I’ll consider the accelerometer facade in Plyer that I re-worked upon:

Yes, it’s actually as simple as that! You can access any of the Android APIs just by specifying the corresponding Java classes.

Implementing an abstract class takes slightly more effort as you have to declare an interface with the methods that need to be implemented:

Except hashCode, the rest of the portions are quite self-explanatory. Wikipedia has the following to say about the hash code function in Java:

In the Java programming language, every class implicitly or explicitly provides a hashCode() method, which digests the data stored in an instance of the class into a single hash value (a 32-bit signed integer). This hash is used by other code when storing or manipulating the instance …

You would probably want to refer to http://pyjnius.readthedocs.org/, if you are interested in using Pyjnius yourself.

I think after this first accelerometer facade, implementation other similar features (other sensors) would a be a trivial task. I hope to make some good progress on them in the coming week.

Footnotes

  1. I must acknowledge that a most of the content in this post has been derived from this discussion. ^

Mid-Midterm Activities on Kivy

This week I continued our Plyer development. I worked on implementing the accelerometer, gyroscope and magnetometer sensors facades.

Although after a discussion with the community on IRC with tito and tshirtman, we realized that we may need to rework on some of these implementations to avoid the dependencies that we currently have. We intend to completely avoid any Java and Objective C code to access the platform APIs. Instead, we’d let Pyjnius (and Pyobjus) to directly use the classes provided by these operating systems.

But not all was lost. By working on these implementations I was able to have a better understanding of the architecture that we are aiming for and re-writing the specific portions from here would be much easier.

Apart from that, I was able to bring the accelerometer implementation on OS X to a closure. It was quite interesting to be read the sudden motion sensors available on Macbooks (mostly to safeguard the hard-disks) and use it as an accelerometer sensor:

Accelerometer on a Macbook
Using the sudden motion sensor on a Macbook Pro as an accelerometer.

I see that our list of pull requests has grown to a considerable size. In the coming week, I hope to resolve the problems pointed out with some of these and be able to merge them as well.

Kivy Updates from the First Week

As I announced in my previous post, I will be working with the Python Sotware Fundation to contribute towards the Kivy’s Plyer project this summer. And I’ll be posting regular updates about the developments here.

This week, I had to spend a significant amount of time trying to debug this nasty bug in python-for-android. It was critical bug to fix, as it was blocking me to try out kivy apps on Android. After a few blind attempts to tackle this problem by trying to find any missing dependencies or looking for any regression with the Kivy code, we finally narrowed it down to be a P4A issue with the build directories. After long hours of debugging quanon, brousch and I were able to find a temporary work-around for the problem. We should soon expect a fix on this from quanon.

Next, I reviewed some of the Plyer’s pending pull requests about the SMS facade, and providing email support on desktops. I think all four of these PRs are now ready to be merged after a couple of minor changes that I suggested.

Finally, I worked towards implementing the accelerometer facade on MacOSX. While, it happens to be a simple task on Linux, being an awesome OS; it was a bit hacky to do so on Mac by making use of the sudden motion sensors. Currently, we have kept this PR on hold to think about cleaner ways of providing support on different kinds of portable macs. So along with the camera facade, this is the second feature PR on which waiting on better ideas for implementation.

That’s about it from me till the next update!

 

Kivy for all your GUI (or NUI) needs!

I work on projects in the area of intelligent user interfaces. This involves building UI prototypes that run on devices of different shapes, sizes and forms.

I think most of you would agree when I say that Python is one of the best languages  for prototyping anything as a CS student.

More often I have found myself switching back and forth between using Python on my desktop for doing the core part of the project and using mobile specific frameworks for the making the user facing components. For example, I would create partially complete apps on the phone to collect the data on the phone and do all the processing on my desktop. Unfortunately with this approach, you have to dive into understanding the API of the platform you are building for in its “favorite” programming language. It’s even more of a mess when you target your studies on more than one such platform.

What if I tell you that you could do everything in Python and enjoy all of it benefits (read modules 🙂 ) while building cross-platform applications?

Recenty, I was introduced to this library called Kivy:

… an open source Python library for rapid development of applications
that make use of innovative user interfaces

The best part about using Kivy is that your same code runs on Linux, Windows, OS X, Android and iOS.

It also takes care of most of the input devices and has native support for things like multi-touch.

If this sounds interesting, you can check out a couple of kivy examples, talking to people on freenode #Kivy (testified by many as one of the friendliest communities on IRC :D) and following these wonderful introductory videos:

You can also find apps with a variety of innovative user interfaces built by independent developers in the Kivy gallery.

While Kivy provides you with a framework for building apps, it is supported by complementary projects such as PyJnius, PyObjus and Plyer.

PyJnius is a library for accessing Java classes from Python. So instead of trying to build communication layers for each of the API feature of a device, PyJnius on Android (and PyObjus on iOS) lets you access all the device specific APIs on mobile devices. This python code is converted to C using Cython and can be then interfaced with the Android OS using the native development kit (NDK).

But this still needs you to know about different platform APIs and mind the differences between them when you build cross-platform applications.

To solve this problem, we have the Plyer project which gives you a set of common APIs for accessing things like Camera, GPS, Accelerometer and other other sensors; and takes care of making the appropriate PyJnius and PyObjus calls in the background.

This summer, I’ll be working to contribute towards the development of this library. Hopefully as the support for these libraries grows, I would be able to manage my own projects with more ease and also help others in the community who were looking for a solution like this.