About

mFabrik Blog is about mobile and web software development, open source and Linux. We tell exciting tales where business, technology, web and mobile convergence.

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.

Native mobile application development with Plone, WordPress and Python

Posted on February 9, 2011

We have just released two mobile applications backed by Plone, WordPress and Python middleware code. In this blog post I’ll tell some background information what we have learnt with mobile applicationand Python development.

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

Open source contribution agreement template

Posted on August 24, 2010

We are looking for creating contribution agreements for few new open source projects. IANAL, but hiring a real lawyer is freaking expensive.

The thing is that we, us a company, want to guarantee that all code coming into the project is “clean”. We also want to guarantee our right to change the license in the future (GPL -> BSD, GPL -> Apache, etc.)

Thus far, the best free, as in freedom and in beer, contribution agreement template we have found is Sun Contribution Agreement 1.5 which is available under  Creative Commons Attribution-Share Alike 3.0 license. It is at least used by high profile Phonegap project (Nitobi as the company) if you don’t count OpenSolaris anymore as open source project.

IANAL, but if I understood correctly, the agreement basically says

  • the company can do whatever it wish with your contributions (joint ownership)
  • the company is entitled to release your contributions under open source license – perfect for GPL’ed projects. The exact wording is terms. Any contribution we make available under any license will also be made available under a suitable FSF (Free Software Foundation) or OSI (Open Source Initiative) approved license.

Since I couldn’t find the orignal document in editable form (PDF was the best I could get) I made OpenOffice.org ODS document out of it with easily replaceable identification information.

Comments welcome.

The agreement text pasted below.

YOURPROJECT Contributor Agreement

These terms apply to your contribution of materials to the YOURCOMPANY ("us"/"our"), and set out the intellectual property rights you grant to us in the contributed materials.  If this contribution is on behalf of a company, the term "you" will also mean the company you identify below. If you agree to be bound by these terms, fill in the information requested below and provide your signature. 

Read this agreement carefully before signing. 

1.  The term "contribution" means any source code, object code, patch, tool, sample, graphic, specification, manual, documentation, or any other material posted or submitted by you to the project. 

2.  With respect to any worldwide copyrights, or copyright applications and registrations, in your contribution: 

you assign to us joint ownership through this document, and to the extent that such assignment is or becomes invalid, ineffective or unenforceable, through this document you grant to us a perpetual, irrevocable, non-exclusive, worldwide, no-charge, royalty-free, unrestricted license to exercise all rights under those copyrights. This includes, at our option, the right to sublicense these same rights to third parties through multiple levels of sublicensees or other licensing arrangements;
you agree that each of us can do all things in relation to your contribution as if each of us were the sole owners, and if one of us makes a derivative work of your contribution, the one who makes the derivative work (or has it made) will be the sole owner of that derivative work;
you agree that you will not assert any moral rights in your contribution against us, our licensees or transferees;
you agree that we may register a copyright in your contribution and exercise all ownership rights associated with it; and
you agree that neither of us has any duty to consult with, obtain the consent of, pay, or give an accounting to the other for any use or distribution of your contribution. 

3.  With respect to any patents you own, or that you can license without payment to any third party, through this document you grant to us a perpetual, irrevocable, non-exclusive, worldwide, no-charge, royalty-free license to: 

make, have made, use, sell, offer to sell, import, and otherwise transfer your contribution in whole or in part, alone or in combination with or included in any product, work or materials arising out of the project to which your contribution was submitted, and
at our option, to sublicense these same rights to third parties through multiple levels of sublicensees or other licensing arrangements. 

4.  Except as set out above, you keep all right, title, and interest in your contribution.  The rights that you grant to us under these terms are effective on the date you first submitted a contribution to us, even if your submission took place before the date you sign these terms. Any contribution we make available under any license will also be made available under a Free Culture (as defined by http://freedomdefined.org)  or Free Software/Open Source licence (as defined and approved by the Free Software Foundation or the Open Source Initiative).

5.  With respect to your contribution, you represent that it is an original work and that you can legally grant the rights set out in these terms; 

it does not to the best of your knowledge violate any third party's copyrights, trademarks, patents, or other intellectual property rights; and
you are authorized to sign this contract on behalf of your company (if identified below). 

6.  The place of performance is the registered seat of

	YOURCOMPANYNAME
	YOURCOMPANYADDRESS1
	YOURCOMPANYADDRESS2
	YOURCOUNTRY
	YOURCOMPANYBUSINESSID	

Any disputes concerning this agreement including the issue of its valid conclusion and its pre and past contractual effects are exclusively decided by the competent court in YOURHOMECITY, YOURCOUNTRY or, at our discretion, also by the competent court is whose district you may have your residence, your registered seat, an establishment or assets.

If available, please list your YOURPROJECT username(s) for the YOURPROJECT systems.

Username(s): __________________________________________________________________

_______________________________________________________________________________

Your contact information (Please print clearly) 

Your name: ____________________________________________________________________

Your company's name (if applicable): __________________________________________

Mailing address: ______________________________________________________________

Telephone, Fax and Email: _____________________________________________________

Your signature: _______________________________________________________________

Date: _________________________________________________________________________

To complete this agreement:
email a scanned copy of a signed agreement to
fax a signed copy to + .....; or
post a signed copy to:

	YOURCOPMANYNAME
	YOURCOMPANYADDRESS1
	YOURCOMPANYADDRESS2
	YOURCOUNTRY

This agreement is based on version 1.5 of the Sun Contributor Agreement, which
can be found at:

http://www.sun.com/software/opensource/contributor_agreement.jsp

This document is licensed under a Creative Commons Attribution-Share Alike 3.0
Unported License http://creativecommons.org/licenses/by-sa/3.0

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

Developing and distributing QT applications for Nokia… not yet!

Posted on May 4, 2010

This information was posted to Phonegap Google groups also.

Next N900 release (PR1.2) will include QT 4 in the default install. It has been delayed due to various problems observed in the leaked beta.

Also, N8  will be the first device supporting Qt out of the box. It is not shipping yet.

Nokia Qt SDK should allow unified Qt apps for Symbian and Meego:

It is not yet possible to deploy Qt apps through OVI store, so targeting third party apps to Nokia Qt is kind of pointless. If you need to develop to Nokia using a web framework, don’t rely on native QT Webkit, but target to Nokia WRT  instead.

Nokia bought Qt in January 2008. It has taken over two years to ship the first Qt enabled mobile phone. Meanwhile, Apple has released App Store and risen to be the leading smartphone provider with its iPhone…. talk about slow development and the lack of leadership. So the hype around “QT will solve everything” is still just hype… they still don’t have nothing solid out there.

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

Why C# / Javascript will be allowed and Flash won’t be as App Store programming language

Posted on April 13, 2010

All the Flash developers of the world wet their pants on 8th April 2010 when Apple announced that Flash based application won’t be approved in the Apple’s App Store. This essentially destroyed the easy opportunity to monetize existing Flash development skills and the huge Adobe expansion potential into mobile markets, pissing a lot of folks who had bet on Adobe’s technology, leading developers’ rage on Internet forums.  Bad news for those who had already building iPhone apps on Flash CS5 even before it was released…

Unfortunately it was not only Adobe and Flash who got in the line of fire: popular frameworks like Appcelerator, Unity 3D and Monotouch apps are theoretically excluded to enter App Store by the new developer agreement which states that the original source code of the application must be C, C++, Objective-C or WebKit/Javascript.

I belive Apple does not hate certain programming languages. Apple does not either want to force you to use their development tools. Only by understanding what Apple really meant with the infamous 3.3.1  clause in the developer agreement, we can start building a bridge to get MonoTouch et. al. to be Apple’s favorites again.

History of Flash (Lite)

Adobe (Macromedia) and Flash have been into mobile business far before iPhone was published. The thing is called Flash Lite run-time. It runs on billions of phones.

The problem of Flash Lite is that it does not very well integrate with its host environment. It does not even have so simple user interface component as a “menu” out of the box. Which means that every developer must create their own menu implementation. Which means that there exist hundreds of shitty Flash Lite menu implementations out there, each behaving differently and each not resembling the native menu component. This is not a very nice thing if you consider the user experience of the application and iPhone  is all about user experience. Note that this is not so big thing for games, as games have radically different user experience anyway.

Flash does not communicate with its host platform either. You wouldn’t be able to access native API features even if you fully controlled the deployment environment of Flash application, as Flash is a binary blob into which you cannot plug-in more parts. There even exists a product for mobile Flash whose sole purpose is circumvent the limitations of  Flash by using a localhost TCP/IP socket connection and a native server application. If developers choose Flash they choose to lock themselves into Flash and what Adobe gives for them.

This crippling of your platform potential with Flash is not limited to Flash Lite and mobile. I have personal experiences from a project done with Adobe Air for Windows. We wisely chose Adobe Air as a desktop application development platform, because it would guarantee the future portability of our code. However, this nice idea did not really interest in the point when we noticed that we e.g. couldn’t control how File Open dialogs behave (file mask, remember start folder, etc.), severely reducing the user experience of the application.

So, Steve Jobs definitely is on something when he says “intermediary translation or compatibility layer” is bad for your platform.

Note that the same limitation concerns Java ME also. Desktop Java has JNI interface for building extensions, but mobile Java doesn’t.

How other frameworks differ from Flash

Let’s take a MonoTouch for example. MonoTouch is Novell’s open source Mono project based development tool which allows you to create iPhone applications in C# language. Compared to Objective C, development using MonoTouch  has several advantages for certain audience: you don’t need to learn new programming language, C# is closer to traditional Java/C++ languages than Objective-C, you can leverage the full potential of existing C# ecosystem out there, the standard library has more functionality and of course, it is easier to port the core of the application from a platform to another.

Note that the porting part concerns core i.e. application logic only. MonoTouch does not try to separate you from Apple’s platform. It does not reinvent platform services or user interface building blocks, or force something like Windows user interface into your shiny iPhone. In fact, MonoTouch seamlessly integrates with Apple’s platform. You even need to use Apple’s own Interface Builder tool to create user interfaces, which will be exposed to MonoTouch’s C# code. Binding with native API is breeze: below ten lines of code guaranteeing that whenever Apple releases a new platform feature it will be instantly available for all MonoTouch developers.

MonoTouch embraces the platform. You can pick Objective C or C# depending on taste. The resulting source code is similar in idea, different in syntax. There is no “compatibility layer” so to say. Not even technically, as C# is compiled to native ARM binary. There is no way how a person could distinguish a MonoTouch application from an application build using Objective-C.

Open source philosophy and platforms

Appcelerator, PhoneGap and other open source / Javascript frameworks are also protected from Apple’s wrath. They are open source which means that you can tap the full potential Apple’s development platform as long as someones writes a little binding code. Also, they try to use native look and feel and components as much as possible, just to make the applications slick. The frameworks do not have conflicting interest with Apple; the frameworks provide portability to a certain point, but they do this respecting their master.

Flash does not enjoy this freedom; developers can’t change Flash or venture outside Flash’s sandbox.

The Future

There is no point of technically counter App Store’s developer agreement, like saying “hey I’ll just compile all my Flash source code to C so it is C code.” It’s Apple’s game. Apple can do anything they wish and they can also change the developer agreement. So when Apple sees something happening in its ecosystem which might damage it, it simply pulls the rug under your feet again. But Apple can also change the agreement in a positive way. PhoneGap has already went through process of becoming App Store approved framework once. I hope that development communities will not burn its bridges with Apple, but try to communicate this matter with a meaningful manner and come to a development agreement resolution based on ideas given in this blog post. Below is my proposition (IANAL. It is left to the reader to come up with something smarter):

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be written using Apple’s guidelines and best practices to express Apple’s intend how the application should behave.

iPhone is not a monopoly. You are free to build and run your Flash application on a device like N900 on any day and sell it in Nokia’s OVI store. If this is a problem for your business then maybe you should reconsider your business model to be less iPhone centric and promote heterogenicity of mobile platforms and application stores.

Until Flash is fixed so that you can mix-in native code, instead of it being a barrier between the expression and the hosting platform, I find it unlikely any company based their reputation around the user experience would allow Flash on their platform.

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