buru on brails

Technically, both Maemo and Android run on Linux kernels. However, Maemo is a full Linux distro, based on Debian, while Android is a sole kernel with a few programs on top of it (namely, Dalvik virtual machine and Sqlite database). On Adnroid all applications run within Dalvik virtual machine, which is heavily optimized and modified version of Java virtual machine (JVM). I tried to analyze the benefits of each platform from the perspective of a software developer, as well as platforms' current "strategic position". If you are too busy to read all the details, there is a short summary paragraph at the end of each chapter.

Android vs Maemo from developer's perspective

Development.

Maemo SDK is Linux-only. It's not a problem for me (as Linux is my OS of choice), but it may be a problem for many developers. SDK works best on Debian or Debian-based distros (e.g. Ubuntu). Maemo is also a Debian-based distro, so SDK simply uses Scratchbox cross-compilation toolkit to build for both x86 and ARM architectures.
Maemo applications are developed in GTK+ using Hildon application framework. Naturally, the primary language of Maemo application development is C. Other languages can also be used, as GTK+ has bindings for many programming languages, including C++, Java, C#, Ruby etc. However, most applications will be developed in C, mainly due to performance constraints, which are especially actual for mobile devices. GTK+ itself is a bit archaic by today's standards, and although Hildon is specifically targeted for touch-screen interfaces, most of work is still done in GTK+ and good old C. Thus, the development platform is not on par with modern mobile application development environments such as iPhone SDK, Android SDK, or Palm WebOS Mojo SDK. This may change with Maemo 6 release (codenamed "Harmattan") when Qt libraries will be supported and Qt will become Maemo official application development framework. But this will happen somewhere in 2011, so for now Maemo application development is a step behind that of Android.
Update: As multiple commenters pointed out, Qt should be already used for Maemo application development. It's a modern way to develop cross-platform apps that will run on both Maemo and Symbian OS (as well as Windows/Mac OS X/Linux, although it may not be practical to use similar UI for both desktop and mobile software). The earlier Qt becomes official application development framework for Maemo and Symbian OS, the better.

Android SDK is available for Windows, Linux, and Mac OS X. Applications are developed in Java and the development platform is really easy to get into. It features XML (DSL) for GUI interface building, easy strings internationalization, app storage within SQLite database, background processes management etc. To make a long story short, it's how modern mobile application development platform should look like. The only downside is that all applications are in Java, and for some developers Java became the synonym of slowness (although it's not that slow on Android, as Dalvik VM is specifically optimized for running on it). For such developers, there is an option of using Native Android SDK, although its capabilities are very limited, especially in hardware access department.

Porting existing applications.

In this area, Maemo has a huge advantage over Android, as it's a full Debian based distro. With the help of Scratchbox Cross Compilation Toolkit many open-source tools can be compiled for ARM architecture. A number of command line utilities can be ported with a simple cross-compilation, GUI apps usually require UI rewrite, but anyway it's much easier to port open-source app to Maemo than to write it from scratch. Some of the famous open-source apps are already ported to Maemo: MPlayer, Pidgin, Gnumeric, Abiword and many others.
On Android, porting an open-source app from x86 Linux is almost as hard as porting an app from any other platform: all UI and logic has to be rewritten from scratch.

Summary: Development is easier on Android platform, while porting existing apps is easier for Maemo platform. 

Strategic position

Both platforms are aimed at the same vertical market: smartphones – MIDs – netbooks. Maemo is backed by Nokia alone, while Android is backed by Open Handset Alliance, whose members include Google, Samsung, LG, Motorola, HTC, Acer and others. Nokia may be the largest mobile phone and smartphone manufacturer on the planet, but it cannot compete with such a might. Thus, it's obvious that in the nearest future Android devices will outnumber Maemo devices by a large margin. There should be 18 Android devices released by the end of the year, while there will be only 4 Maemo devices released by that time (Nokia N770, N800, N810, N900). Even if N900 and new Maemo MIDs, and finally netbooks will sell better than their Android counterparts, the total install base of Android devices will grow faster than that of Maemo devices. The larger install base, the more OS is interesting for developers (assuming, it has a decent app dev platform). Nokia's main competitors - Samsung and LG - will use Android as a competitive advantage, and throw their development and marketing efforts behind this platform. Motorola is trying to save itself with its MOTOCLIQ aggressive pricing and MOTOBLUR Android software, and it has the chances to succeed!. Under the circumstances, Maemo becomes Nokia's main competitive advantage, so the company should throw its efforts behind it or lose market leadership. The position of fierce competition ensures the bright future for both platforms. However, which platform will finally win is another question, and perhaps the most interesting one. The logical winner is Android: it'll have larger install base in the nearest future; more developers will work on apps for Android; it is backed by powerful corporations, mighty Google among them. Nevertheless, there is a single power that can keep Maemo up float and possibly even make it prevail in the long term: open-source community. You'd argue: both Maemo and Android are open source. It doesn't matter. What matters is whether the platform could benefit from countless man-years of efforts, done by open-source community. Android benefits only from Linux kernel development and a small number of other open-source projects, all Android apps have to be written from scratch. Contrary to that, any open-source project which runs on Linux indirectly contributes into Maemo software ecosystem (as it can be relatively easily ported). Maemo has to use this to its own advantage, or it has no chance against Android. Thus, Maemo core developers should make this advantage even bigger by easing the process of porting open-source apps to Maemo, which can be achieved by migrating from ARM to x86 at some point.
Another advantage of Maemo is that it's more suitable for larger devices - MIDs and netbooks. Maemo was designed to run on MIDs, and it already proved its worth in this area. Being a Debian-based distro, Maemo will probably fit well on touchscreen netbooks as well. Android looks good on smartphones, but it remains to be seen whether it will be enough for netbooks. There is a chance that Android will succeed on smartphone market, while Maemo will prevail on MIDs and netbooks.

Summary: Android has better strategic position at the moment: Android devices will outnumber Maemo devices in the nearest future, it will also have more developers (better development platform + larger install base). Still, Maemo can win after all if it plays nicely with open-source community and utilizes its tremendous work. Another Maemo advantage is that it's better for MIDs and netbooks.


Post scriptum

Either Android or Maemo, Linux will win after all :)

Post post scriptum

As much as you may prefer Android, Maemo, or other smartphone OS, the ideal situation for smartphone market as a whole would be healthy competition between a few major platforms, not a single platform dominance. Maemo and Android are both open-source and overly good operating systems, so it will be good if they become those dominate platforms, not killing each other, but competing in equilibrium for years, bringing innovation along the way.


Update

For more insights and opinions on topic, please read the comments below and the article's discussions on Reddit, and Maemo Talk.
Summarizing the opinions, I've listed the following advantages of each platform:

Android advantages:

1. Binary compatibility between releases. Technically, it's byte code compatibility in Android's case. Maemo lacks it, which means hard time for developers with every new release.
2. Android is better positioned at mid-end smartphone market, where it will compete with Symbian OS.

Maemo advantages:

1. Better game development, especially cross-platform game development.
2. Qt can (and should!) be used for cross-platform development for both Maemo and Symbian OS, which equals developing with modern app dev framework for the largest smartphone install base.

Yet another update


The article was translated into Russian and posted on Habrahabr by one of it's users, and triggered an interesting discussion there (Habrahabr is Russian Slashdot-like community). So, if you know Russian, you might be interested in reading the discussion here.

While developing Facebook application I got stuck with "Session key invalid or no longer valid" error. Googling for it gave me lots of results, but not a single solution! So, after finally dealing with it, I decided to blog about it to help fellow Facebook developers and not to forget about the solution myself.

First of all, check out whether your app is authorized with Facebook by going to the following address in the browser window where you got the exception:

http://www.facebook.com/login.php?api_key=YOUR_APP_KEY&next=RETURN_URL

After that, you have to create Facebook API object to work with. Here's the example in C# (using .Net Facebook Developer Toolkit), principles for other platforms remain the same:


facebook.API api = new facebook.API();
api.ApplicationKey = "YOUR_APP_KEY";
api.Secret = "YOUR_SECRET_KEY";
api.SessionKey = HttpContext.Current.Request.Cookies["YOUR_APP_KEY" + "_session_key"].Value;
int userID = -1;
int.TryParse(HttpContext.Current.Request.Cookies["YOUR_APP_KEY" + "_user"), out userID);
api.uid = userID;



The key line of code here is the one when you're setting API session key. It is tempting (and natural!) to take the session key from request by using Request["fb_sig_session_key"], but for some mysterious reason this results in "Session key invalid or no longer valid" error. The only way to circumvent this ugly bug that I'm aware of is to take session key from cookie, not from request. That's it, after setting session key to "YOUR_APP_KEY_session_key" cookie I had no problems with this issue.
After that, just use the API object as usual. For example, in terms of .Net Facebook Developer Toolkit, use the following code to get a list your friends ids:


api.friends.get();


1. Fast. Vim may be hard to learn, but when you master it, you'll be editing fast, very fast. Typing with all 10 fingers, ultra fast navigation within file, numeric modifier for commands ("10dd" - cuts 10 lines), repeated commands with ".", macros, and zillions of key-combos at your disposal - all this makes Vim by far the fastest editor on the planet.
2. Good for health. With Vim you do not have to use mouse at all. Even if you're using Vim's graphical implementation like gVim or MacVim, you absolutely do not need to touch you mouse at all, everything is much easier and faster to do from the keyboard. Considering the fact that you use mouse very frequently in most of other programs, your right hand tires much faster than your left hand. With Vim, you may balance load on your hands - they will do similar things and tire in parallel. Thus, you'll avoid potential right hand joyents problems, which arise from frequent use of mouse.
3. Available everywhere. Vim is cross platform. It runs natively on UNIX and Linux. There are also GUI versions, adopted for major operating systems: gVim for Windows and MacWim for Mac OS X, they look and feel like native apps for these platforms. Thus, you can edit files with Vim on your Linux/Mac/Windows system, then ssh to Solaris or FreeBSD server and edit files with Vim there. It is so nice when favourite editor is available anywhere.
4. Extensible. Visit vim.org and see yourself - Vim has zillions of plugins readily available to greatly extend it's functionality. For example, vimfiles plugin extends Vim with all of the neat features of TextMate editor (like bundles, project browser, fast file search etc), effectively turning Vim into the best editor for Ruby on Rails programming (as it combines features of both Vim and TextMate). Vim has its own scripting language for extensions, and it is quite easy to create Vim extension yourself.
   
5. Cool! The coolness of Vim is like the coolness of Linux. It is hard to master, but when you do it, you feel like you've just got an elite status, a status which is impossible to gain with money, just to achieve with intellect and hard work. Surely, such kind of coolness is valuable only for geeks and nerds alike :)
   

During my doctorate studies I came to the notion of totally-dynamic system. In order to imagine what totally-dynamic system is, first think of a simple plain-HTML website from late 90-ties: such a system is static by data (its contents can be manually modified only by its programmers); static by hardware (it runs on a number of servers and this state of affairs can be manually changed by system administrators and usually requires full system restart); and static by software (its software does not change during system runtime, can be modified manually by its creators). So, in runtime, such a system is totally static. Now let us look at modern data-driven application, for example, any web 2.0 service: it is dynamic by data, as its behavior changes depending on data, generated by its users during system runtime; as for other parameters - hardware and software - it is static. Most of modern applications, be it web , desktop or mobile applications, are dynamic by data. Nowadays, systems with dynamic hardware are becoming very popular. Basically, there are two types of such a systems: ad-hoc networks and services that use cloud-computing. Ad-hoc networks are usually dynamically-formed networks of mobile devices like cell phones or smarpthones. The hardware of such a network is the whole set of mobile devices, which are currently connected to a network, and thus, it is constantly changing. As for services that use cloud computing, they receive additional hardware from cloud computing service provider (like Amazon EC2 or Joyent Accelerator) in times of peaks in their load. It is a widely accepted opinion that systems with dynamic hardware are going to flourish in the nearest future, as they are more cost effective in comparison to their hardware-static counterparts. Thus, it is likely that hardware-dynamic systems will replace hardware-static, just like data-dynamic systems replaced data-static. You should also note that all modern hardware-dynamic systems are also data-dynamic.

Now, one last step to totally-dynamic is software-dynamic system: a system, whose software modifies itself during system runtime, adapting to ever-changing environment. Software-dynamic system is not as futuristic as it might seem: such systems were created as early as in 1960-ies during early experiments with artificial intelligence. The key here is the programming language of the software: the more high-level it is, the easier is to create software-dynamic system with it. Probably, the most suitable language for software-dynamic systems is LISP, as its code is actually its main data type – list (LISP function is actually a list, whose “head” (CAR) is function name and “tail” (CDR) is function arguments); thus, LISP program can easily feed its code to itself and modify it during runtime. However, industry-standard languages are moving towards LISP's reflective capabilities, and now some of such a languages are reflective enough to be suitable for software-dynamic system creation. For instance, Ruby, the foundation of Ruby on Rails framework, has very high reflection capabilities and is quite suitable for writing self-modifying programs.

Imagine the system, which is data-dynamic, hardware-dynamic and software-dynamic at the same time. Such a system will behave differently depending on data generated by its users; its hardware will be constantly changing, growing or shrinking; its software will constantly modify itself, be it making good use of newly connected advanced devices or adapting to changes in system's userbase. This is the system I call totally-dynamic. I claim that software engineering is moving towards totally-dynamic systems, and this move is right from the evolutionary standpoint. Animals are natural analogies of totally-dynamic systems: they change their behavior in accordance to data they get from the environment (data-dynamic); their “hardware” change depending on what they do, e.g. their muscles grow due to intensive hunting (hardware-dynamic); their “software” also change during their lifetime and from generation to generation due to evolutionary mechanisms (software-dynamic). Humans are also totally-dynamic systems, just more advanced. Thus, its obvious that totally-dynamic systems evolve under certain conditions. It means that should we create totally-dynamic system and place it in some sort of genetic algorithm, one day it may evolve to an intelligent system, just like intelligent animals evolved from unintelligent ones. This may be the road to artificial intelligence creation. We hadn't much success with the creation of AI within our labs, but who knows, maybe AI will come out of an unexpected place. Maybe the next generation communication service (the descendant of Facebook, Twitter, or FriendFeed), which will be a totally-dynamic system, will one day evolve into an intelligent being.

In recent Computerworld analytical article Mary K Pratt tries to accurately predict what the PC would look like by the year 2019 by aggregating the predictions of leading hardware and software researchers and developers, as well as a few prominent computer scientists. According to the author, the PC of the future will resemble todays smartphones in portability and will have all the valuable data and applications stored "in the cloud" (distributed internet storage, accessible from anywhere). These future PCs will be people's mobile phones, laptops and PCs at the same time; they will be "the context machines", switching data and application contexts in accordance to person current task. Such a prediction is in line with the recent trends of "computing in the cloud", "SaaS" (software as a service) and the move from specialization to general-purposeness in mobile devices evolution. The combination of "huge computational and storage resouces in the cloud" and "portable devices with constant internet connectivity" is the only combination of factors that can give users both power and portability at the same time, assuming technologies won't change drastically in 10 years. However, Pratt's opinion seems to be biased towards SaaS and mobile devices development trends. It worth nothing that all of the mentioned trends appeared less than 10 years ago, and thus in the next 10 years they may as well disappear, giving a way to something completely new. Also, I wouldn't recommend to underestimate the survivability of traditional PC: there were a lot of predictions of their failure during the past 20 years, but the PC is still there, it remained conceptually unchanged contrary to all predictions. Another thing that Pratt didn't put into equation is ultimate users stupidity: typical users have been mindlessly wasting most of their PCs computational power for the past 10 years on running viruses and antiviruses, and I don't think someone would stop them from doing it for another decade. Yet another factor that can prolong current PC state is the opposition of hardware companies, that are not interested in disappearance of huge PC manufacturing business in merger or even complete replacement by smartpone hardware business. Just like oil corporations suppress the development of alternative energy sources, PC manufacturing corporation may suppress this kind of PC evolution process, and thus slow down the progress in this area.

In my opinion, the typical PC of 2019 will be almost like our today's PCs, just much more powerful and with most of software and storage moved to the web. SaaS and cloud computing growth seems inevitable, as it solves all of the majour problems of packaged software: cost, piracy and complexity of upgrade. However, I believe, there still will be some non-SaaS, packaged software installed on PCs, e.g. games, multimedia players; even word processors, as archaic as they look even now, may survive for another 10 years. As for "the context machines", they will exist and will be used by many, they just won't be so advanced as an article states; and as they won't be the evolution of PC, but rather that of smartphone, this kind of devices surely won't be called PCs in 2019. However, only time will tell the truth.

Netbooks are perfect devices for web browsing, but there are times when they have to face much more serious challenge.

I'm satisfied with my nebook performance (Acer Aspire One, Linux/SSD version). I've modified default Linpus Linux Lite, stripping all the Acer's soft, and replaced it with bare-bones xfce4.4 + compiz fusion with all sorts of fancy effects + my favourite linux programs, compiled from source. Nevertheless, I preserved the default kernel and kernel modules to ensure all hardware works just fine. As a result, system boots in ~15 seconds, feels fast and impressive (due to compiz fusion).

This setup proved to be suitable for web browsing, occasional word processing (I tend to use Google Docs for word processing, so use OpenOffice only when I'm offline), ssh-ing and Ruby on Rails development with Vim. I even used netbook to develop some J2ME applications with Netbeans 6.5. The powerful IDE feeld snappy, emulator booted quickly, the only real annoyance was the lack of "Home" and "End" keys on the keyboard.

But then I faced the need of some Android development on a netbook. Normally I use my desktop for Android development. However, I'm currently teaching a University course of application development for mobile platforms, and I had to demonstrate Android development to my students. For my lectures, I usually take a netbook with me, connect it to multimedia projector, and program something there to demonstrate how this or that mobile platform programming goes. I was so assured in the netbooks performance that I hadn't even tested Android development on it, just set the environment. The environment was a typical one: Android SDK and Eclipse Ganymede with ADT plugin.

So, after a talk about Android architecture principles I supposed it was time to demonstrate some of them in practice and started Eclipse. It feeled slow, to say it mildly. "Nothing special", I thought, "Ecipse feels slow even on my desktop, it is slow by design!". I've created an Android project with ADT plugin and then came the next annoying thing - netbook screen appeared to be just too small for all Eclipse panels, they occupied almost all of the screen space, leaving only a tiny fracture of it for source code editing. After closing almost all of the panels, I was able to free some screen space for code editor, so it became acceptable. Having explained the project directory structure to my students I decided to run the project to show them how Android emulator works. Then came the worst part: Android emulator loaded terribly slowly, it had been loading for 5 minutes or even more, bringing netbook to it's knees in the process. Another issue which I noticed during the emulator load - default emulator skin (HVGA-P), that Eclipse starts, doesn't fit netbook 1024x600 screen resolution and there's absolutely no way to resize it to fit the screen. The most vital parts of Android emulator - it's "menu" and "home" buttons - don't fit in the screen, rendering emulator almost useless! (see screenshot below)

Note that in addition to emulator and Eclipse I was running Adobe Reader with ~6M pdf file loaded and Firefox with 5+ opened tabs. This made my netbook super-slow, sometimes it simply hanged for 5-10 seconds. Not to say, those lecture wasn't very productive: apart from architecture overview, the only thing that we were able to examine was simple "Hello, World!"-type application...

Naturally, after such a failure my first thought was that netbook is completely unsuitable for Android application development. But what seems to be an impassable obstacle for normal person is an interesting challenge for a true geek! So, I decided to optimize my Android development environment until it becomes usable on a netbook. My idea was to avoid using Eclipse (as it is a CPU and memory hog), resize emulator to fit the screen and disable Compiz Fusion (as it tended to make emulator much slower in my experience). Speaking in advance, I was able to implement this idea with little effort, so I decided to write a little guide so that my geeky readers could try to set up such an environment for themselves and happily develop Android applications on their powerful netbooks:

First of all, you should tune Android emulator to fit 1024x600 netbook screen. For this, start the emulator from command line with the following options:

emulator -no-boot-anim -verbose -skin QVGA-L

Here "no-boot-anim" is used for faster boot time, "-verbose" is to see if everything goes smooth and "-skin QVGA-L" is to call skin with smaller screen resolution than default one (320x480 portrait HVGA-P vs 320x240 landscape QVGA-L). Such an emulator perfectly fits the small netbook screen; the only thing that doesn't fit the screen is a part of QWERTY keyboard, which doesn't matter anyway as you may use regular keyboard instead. As a side note, "HVGA-L" skin also fits the standard netbook screen, so you may use it as well. Personally, I prefer QVGA-P for it's geeky look and for the fact that "-no-boot-anim" option actually works for it, so it boots much faster than "HVGA-P" device.