Thursday, November 29, 2012

Watching/monitoring CSS attributes with jQuery

I needed to monitor dimension and size CSS attributes for a AAC switch-access library I'm developing. (A separate blog post on that when it's ready. It's already on github, but there are some annoying bugs, and only support for single switch elements, and no groups...)

After testing jquery-resize (, jquery-watch ( and a few others, I found that they were almost what I was looking for, but not exactly what I needed.

My requirements where:

  • Monitor one or multiple CSS attribute
  • Use custom functions like 'outerWidth(true)' to get the full width including border, margin and padding. 'css('width')' would only return the element width.
  • Use requestAnimationFrame instead of setTimeout if available.
  • Either jQuery events or direct callbacks
Since I didn't find any existing jQuery plugins, jquery-csswatch was born.

The plugin is written in CoffeeScript.

Thursday, October 25, 2012

Rails 3.2 and virtual attributes

I was fighting with virtual attributes for a few hours, and I'll share what I did wrong:

Here's a model with one virtual attribute as well as a text field

class User < ActiveRecord::Base
  attr_accessible :sanity_level
  attr_accessor   :sanity_level

  validates_presence_of :sanity_level, :on => :update

I would expect the following to work:

user = User.create(:name => "Leif") => 5)
# => false # What?
# => Errors show: Sanity Level cannot be blank... but it is 5?
user.update_attributes(:sanity_level => 5)
# => true

I expected both to work, but it doesn't by design. After looking at activerecord and mysql2 source, it is easly spotted that save calls create_or_update without forwarding the hash, so of course it will fail!
To summarize and remember for the future:
  1. Use update_attributes when updating with a hash for the attributes to update
  2. Use save after setting attributes manually
  3. Use create when creating new records
  4. Use build when building new records with a hash and saving later
And a note to myself again: Don't use save when updating attributes.

Friday, June 29, 2012

Why I might move away from Qt

To begin with I loved Qt, and I still do for some projects. However, things have changed a lot the last 5 years in the tech industry, and Qt has fallen a bit off the grid after Nokia took charge.

Key points why I am reluctant in using Qt on future projects:

  • Android
  • iOS
  • Windows RT
  • Windows Phone
  • Still struggling to support meego, and symbian. Big waste of resources!

I think that should be quite self-explanatory, but let me dig a bit deeper.

At one point Qt was on the cutting edge of new platforms, then symbian and meego wanted to join in. I knew already than that it meant trouble, because both were already dying platforms. 

I've been using Qt successfully on quite a number of projects over the last 7-8 years, and it has been a pleasure.

Now I don't know if my next few projects will be Qt based at all, even though they will be both mobile and desktop applications.

Qt can support XP/Win7/Win8 Desktop and OS X, but not metro style WinRT (MS ARM based tablets). Qt cannot help me with mobile so I need a different framework here.

So I started looking this way. How many frameworks do I need to write the same software for iOS, Android, OS X, Win XP, Win 7, Win 8 and Win RT ?

I hoped to keep the number down to three, and with Qt, it still might be possible. But there are other frameworks lurking around as well now. 

Example: Mono/.NET:

I can use C# and write common code for all platforms that have Mono or .NET.
Well. All platforms both mobile and desktop has either .NET or Mono. I have to write the GUI for Desktop (OS X, Win XP/7/8) as one, mobile needs one for iOS and one for Android. I would actually have 1 "base" code and 3 derative guis on top. That is managable.

Example: Qt:

I can use C++ to write common objects for both mobile and desktop using STL. The GUI for OS X, Win XP/7/8 can be written in Qt, while the desktop for WinRT have to be written in C++/XAML. Android and iOS need a separate framework.

By choosing Qt, I end up having a C++ base and at least 4 gui implementations in various languages? It's almost doomed to fail. By choosing .NET/Mono I can have 3 gui implementations that actually use parts of each others code, so I save 1 framework/gui implementation. If that is 1 month of work, it's worth using a different framework.

I hope that Qt and the Trolls will open their eyes and make all non-gui parts of Qt compatible with more platforms. It's impossible to have the same GUI code for all the platforms we have today. Even thought it's possible, it will feel "Qt" on top of a native GUI, which isn't really user friendly...

Mobile framework comparisons will be continued

I've been on paternity leave, which is great, and therefore I've tried to keep the blog level down, as the mobile framework is closely related to my work. Paternity leave means stay with your kids, don't press keys on your computer... At least it does for me.

I will do a couple of frameworks next week.

I'm glad I've been a bit delayed, because of the launch of Win8 RT + Microsofts surface tablet changes the gameplan a bit. There aren't any frameworks that support Win8 RT yet, but I expect a few to be able to do so. (At least marmalade and other low level frameworks)

Thursday, March 29, 2012

Choosing a mobile framework: Investigating Moai SDK

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the ninth step -  Investigating each framework. Here we look at Moai SDK. I'll go through each of the steps from the common post for all the frameworks.

Is it easy to get started?

I downloaded the SDK and compared to the previous tested frameworks, it isn't as "tool-centric". Use any editor you like, and use the command line to compile. Even if you don't know anything about the lua language, you should be up and running within 30-60 minutes, depending on your installation/setup skills.

Is it easy to extend the library?

As I originally started with C, assembly and moved onto C++, I would say that it is really easy to extend this library. However, if you don't know C++, you are stuck. There is some documentation on extending here, although it's more a reference than an example. If you are familiar to C++, check the source on github, and you should be able to extend the library without too much hassle. (Just be sure you don't write platform dependant C++ code... use std libs, don't use MS/Apple/Google c++ libs.)

Features I need for my project

Drag and Drop

There is no "native" drag and drop, so it's a matter of writing routines that handle graphics and touch. Moai has good routines for both 2d and 3d. As I need 2d, I can use Box2d in order to handle collisions, which again can be used for drag and drop. Should be ok to implement.

Text to Speech

No support for that, so have to extend the library.

Basic image manipulation

Rotation and scaling, which is the basics. I do need some filters (Gray, inverse, opacity), which might need to be c++ extensions, depending on performance. Lua is usually quite fast, but it depends on the framework, and compiler.

Basic access to camera

When I saw the MOAICamera Class, I thought: cool, native camera access. But that was the camera "viewing" your objects. So this has to be written as an extension.


Here is where MOAI is really easy. As long as you know how to program your paiting/drawing, it's just to use the MOAIdraw class.

JSON support

Has built in parser for parsing between json string and a lua table. Read about MoaiJsonParser here.

HTTP(S)-request support

MoaiHttpTaskBase does all the http magic. And if you need a cloud for your data, there is Moai Cloud as well. Looking at the cheap pricing for Moai cloud, I'm starting to consider if that is a better option than running my own service on a VPS.

Custom user interface placement and user interface elements

Nothing as of now, so you have to paint/draw, or use images. It is on the roadmap.

Audio playback (simple)

The audio engine in Moai is Untz open-source library, which seems quite capable from what I found about it. Retronyms is behind it and they do create some great audio applications. Playing a file was as simple as load, setting volume, setting looping, and then play. This is the kind of audio playback I like to see in a framework. Not too fancy, yet really powerful.

Deployment to supported platforms

Both Android and iOS deployment is quite straight forward. You need a mac for iOS, and either mac or PC for Android.


CPAL license! That's really impressive. Such a powerful framework is released under CPAL! You can ask them to buy a commercial license if you need to modify the framework and you don't wish to release your changes.

Direct access to APIs

No. You need to write extensions. Wrap them as small as possible, and you will soon have access to what you need.

Programming Language

Lua and/or C++. C++ isn't recommended as the main language, as it does require some changes to the framework. Most likely both C++ and Lua is needed when you hit the wall on what the framework can do.


They are working on the docs/wiki, and that is somewhat needed. Although the samples in the SDK should be enough for most of your questions. The API documentation is OK, but it still needs a bit of work.

Supported platforms

  • iOS (3.0 and above)
  • Android (2.1 and above)
  • Chrome (The browser)


Moai is a mature, and going forward, and has a proper Roadmap (Not all frameworks do). I think Moai has the potential to be one of the leading cross-platform frameworks. It really depends on where they go from now. I hope they consider native Windows/OS X as platforms as well, as having one codebase for both mobile and desktop is ideal. Although it's fully possible to use chrome on both platforms, it's not really the same as having native apps on desktop.
For Mobile, I think Moai is a winner, both in pricing, features and future roadmap. It's quite powerful and feature-rich, and it's likely to become even more powerful and feature-rich.

Wednesday, March 21, 2012

Version numbers on software with git, tags and sed

After I moved from svn to git, I started doing some version numbers manually, as I felt I never had the time to figure out a good way to set version numbers using git. However, it's much easier and simpler than in svn, when done right.

Usually I use version numbers like this: 1.0.290, where 1 is major, 0 is minor and 290 the revision number.

I wanted to keep the same pattern when using git, as a lot of the software I maintain is moved from svn, where the revision was used directly from the svn repository.

Instead of having automatic revision numbers, I'm only going to increase them when I want to. That makes it possible to commit without increasing the revision number, which is really want I wanted to do.

Here's a quick and simple way to do it:
Tag your repository v1.0.290 (or similar)

To get the major, minor and revision number, git hash and number of commits since that tag:

echo "major:"
git describe --tags --long | sed "s/v\([0-9]*\).*/\1/"

echo "minor:"
git describe --tags --long | sed "s/v[0-9]*\.\([0-9]*\).*/\1/"

echo "revision:"
git describe --tags --long | sed "s/v[0-9]*\.[0-9]*\.\([0-9]*\).*/\1/"

echo "commits since tag:"
git describe --tags --long | sed "s/v[0-9]*\.[0-9]*\.[0-9]*-\([0-9]*\).*/\1/"

echo "git_hash:"
git describe --tags --long | sed "s/v[0-9]*\.[0-9]*\.[0-9]*-[0-9]*-g\(.*\)/\1/"

It should give an idea on how to get the data needed to update a project with the corresponding version info.

Wednesday, March 7, 2012

Choosing a mobile framework: Investigating Appcelerator Titanium

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the ninth step -  Investigating each framework. Here we look at Appcelerator Titanium. I'll go through each of the steps from the common post for all the frameworks.

Is it easy to get started?
Installing Titanium Studio is very simple, and if you know how to write javascript, you should be able to create a project and be up and running within minutes after installing.

Is it easy to extend the library?
You can write modules, which is fairly simple. There are thorough guides on how to do it here: (

Features I need for my project
Drag and Drop
There are several discussions on their forum (here), but nothing is native. Since it's javascript you can usually try the usual suspects (jquery drag and drop, sencha etc) to see how they perform. I found drag and drop performance to be way below par on slower android devices, as well as on iPhone 3GS.

Text to Speech
You have to write and extension, which is quite simple.

Basic image manipulation
There is some manipulation options through the image view, however, you cannot modify the image source, only how you view it. If that is what you want, you are all set. (Read about it here: Titanium.UI.ImageView)

Basic access to camera
Yes, through the Media module. Would probably be better if it was in a separate module, as I see the connection between media and Camera, but I also feel they should be separate.

You can use a webview with a canvas, or write it in javascript. See this example for how to write an animation: ( Or there is the paint module found here: I found this module quite easy to use, and it seems updated quite frequently. I think Drag and Drop might be better to implement through the paint module, as it will probably give better performance than using UI widgets in a view.

JSON support
Supported in the framework (Titanium.JSON)

HTTP(S)-request support
Supported in the framework (Titanium.Network)

Custom user interface placement and user interface elements
Yes, either through extending a UI widget, using a webview, or just paiting directly. You probably have to extend on per-platform basis, depending on how you implement it.

Audio playback (simple)
Through the Titanium.Media.Sound object. It's limited by formats supported by the platform as well as the number of channels supported by the platform.

Deployment to supported platforms
This is one of the great things about Titanium. If your code isn't too complicated and isn't using too many 1-platform-only calls, you should be able to load up your project from either a mac or a PC and recompile/process for the platform you need to. It's then a matter of following simple guides on how to sign your app and submitting to each of the respective markets.

It's free to get started, however you will probably end up looking at their $49 per month indie pricing, as you are given access to some modules that might come in handy. Paypal module, urban airship, brightcove (to mention a few.

Direct access to APIs
Through writing modules/javascript wrappers. You should be able to use most native apis that way, but some might be harder to implement than others.

Programming Language
JavaScript and/or CSS/HTML5 for hybrid apps. Javascript for pure native apps. For desktop development, ruby, php and python is also supported. Although if you are creating an app for both desktop and mobile, you are stuck with JavaScript.

This is one of the strong points for Titanium. The documentation is really good, well sorted, easy to navigate, and if you need more information there is always the forums. However, people seem to be a bit reluctant on helping each other out compared to other frameworks. That might be because the platform is still quite new, and needs to establish a "core" developer fanbase.

Supported platforms
  • iOS
  • Android 
  • Bada (beta)
  • Windows (Through their desktop SDK)
  • OS X (Through their desktop SDK)
I only wish Windows Phone 7 was on that list, but that probably comes when MS accepts using native code on Windows Phone 7.

Other features
Marketplace: (
Quite a few modules on github: ( and there are plenty more if you search for appcelerator modules)

All inn all a really well documented and supported framework. If I was going to write a business app, I would probably choose it, but for a project that is partially game/app, it's not suited. Their target audience is information and media rich applications. E.g. apps connecting to facebook, twitter, flickr, or another web service, and giving you information, or letting you interact with it. If you are looking into apps that are somewhere between a game and application, you can use the framework, there is just other options for you that are better out there.

Thursday, March 1, 2012

Choosing a mobile framework: Investigating Marmalade SDK

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the ninth step -  Investigating each framework. Here we look at (Made with) Marmalade SDK. I'll go through each of the steps from the common post for all the frameworks.

Is it easy to get started?
As expected, Marmalde should have you up and running in no-time.
Register an account.
Register for a free trial
Download SDK
Open the example project, compile, run simulator. All working within a couple of minutes after download. Note: I already had MS Visual Studio 2008 installed. (

Is it easy to extend the library?
It's quite easy to extend Marmalade through the Marmalade EDK, it's documented enough to get you started, and after an initial attempt to write an simple extension on Windows it was easier than I suspected. I'm guessing it's quite the same for other platforms. There's also a video going through the steps for android and ios.

Features I need for my project
Drag and Drop
Reading from the documentation, what is needed is a combination of S3E Pointer as well as graphics. This is basically what I assumed before looking at the framework, as the framework is pretty "raw" in concepts.

Text to Speech
Must be implemented through an extension.

Basic image manipulation
Marmalade provides two apis for handling graphics Iw2D and IwGx. Both seems quite capable of graphics manipulation, although I had to dig further to find details about image manipulation (docs here). It only documents how to load an image. I do find it somewhat easier to load and work with images through Iw2D. If you are doing 2d games, it might be a good idea to look at IwGame Engine ( It leverages sprite and graphics stuff and makes it a bit easier (and most likely faster) to develop 2d programs for Marmalade.

Basic access to camera
All done through S3E Camera capture. Quite simple and easy to use. It is in Beta at the moment, but it seems to work quite well. (documentation here)

Can be done through Iw2D, IwGX or directly using openGL. IwGame Engine makes 2d drawing a bit easier, although all require quite some work to do what you want. There's also a lot of plugins in the marmalade git repository ( For sprites it might be worth looking at iw2dSprite.

JSON support
None. Since JSON is provided in C, it's a breeze to implement it within Marmalade which already compiles C/C++.

HTTP(S)-request support
IwHTTP handles both and is quite straightforward. You probably want to wrap it in a class to handle your data and server connections, but it's quite capable.

Custom user interface placement and user interface elements
Since marmalade is mostly hardcore drawing using one of the drawing interfaces, this is one of the areas Marmalade is strong. And since it recently implements UI Builder + native UI, you can even combine them.

Audio playback (simple)
Done through S3E Audio. Simple and straight forward sound playback of mp3, wav etc. Usually limited by what the platform supports. For streaming audio, S3E Sound can be used. It streams raw audio directly. There is a warning on using both simultaneously, as the platform usually has limits on how many tracks it handles.

Deployment to supported platforms
There are quite a few steps for each platform, so you probably want to script things up if you are updating your apps on a frequent basis, however, many of the steps are one-off per application, so it's not that much work. Read more in the platform guides,

Free trial/non-commercial. $199 for standard licencse, which gives you a marmalade splash-screen on your apps or pro at $499. both is per seat, per year. Neither expensive nor cheap. You can also get the entire sdk for free for commercial use by applying to thier apps program. If you are unsure on how popular your app will become, go for the apps program, as you might be lucky that it takes off because of other apps distributed through the apps program. However, you get 80% after the store owner has taken their cut. Example: for a $1 app, you get 56 cent. 0,14 to marmalade and 0,30 to the store owner (apple or google that have 70/30 split).

Direct access to APIs
Through EDK, so that's fine.

Programming Language
C/C++, code is compiled and run through a VM. Would most likely give close to native speed. Seems to wrap up openGL on each platform as well as a few other apis into common api.

Plenty of documentation, although it's not really that well organized. You are likely to find documentation for every bit and piece of Marmalade, but

Supported platforms
Now this one is a big plus for Marmalade!
Supported platforms under support agreement:
  • iOS (3.0 and above)
  • Android (1.5 and above)
  • Symbian (Symbian^3 and S60 5th Edition)
  • bada (all versions)
Beta supported platforms (Not under support agreement)
  • LG TV
  • BlackBerry Tablet OS
  • Windows desktop (full-screen and windowed applications)
  • OSX desktop (full-screen and windowed applications)
  • Windows Mobile 6.x
  • Symbian S60 3rd Edition
  • Mobile Linux, generic implementation
Quite an impressive number of supported platforms for being able to write native performance apps. 

Other features
Code Community
Code community with some libraries/plugins etc: /
The community is found on github here:

There is a learning curve to the platform as the API is quite basic. It's a low level framework to give you a common low-level api for multiple platforms. If you are writing a lot of 2d games, you probably want to add a 2d game library on top of Marmalade. Since there are tons of pure c/c++ libraries out there, you should be able to easily incorporate e.g Box2D and similar libraries to make development faster and easier. If you are used to writing everything from scratch, Marmalade offers a lot of flexibility. Comparing the price to the list of features and supported platforms, I would say you get a lot for every penny. However, this is not the library for you if you want a complete ready-to-go game engine or app engine. You have to be prepared to write a lot of the basics from scratch, which you might get directly in other frameworks.

Update 02/03-12: Added other features
Update 03/03-12: Added information about supported platforms,  programming language, documentation and overall summary.

Choosing a mobile framework: Investigating frameworks

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the ninth step -  Investigating each framework. 

I'm not going to look at how simple it is to write a "hello world" app, as that might be very easy, although the framework might be horrible. It's pointless to compare a framework based on "hello world".

For each framework I'm going to look at the following key points:
  • Is it easy to get started?
  • Is it easy to extend the library? (If some functionality is needed cross-platform)
  • I'll briefly investigate these features, as they are needed for my current project:
    • Drag and Drop
    • Text to Speech
    • Basic image manipulation
    • Basic access to camera
    • Drawing/painting
    • JSON support
    • HTTP(S)-request support
    • Custom user interface placement
    • Custom user interface elements
    • Audio playback (simple)
  • Deployment to supported platforms
  • Pricing (Yes, I think pricing is important to look at, although there is always a hidden cost for a "free" framework: usually workload )
  • Direct access to platform APIs or are they wrapped? (sometimes, you need to dig deeper than the framework wants you to....)
The frameworks in details:

Choosing a mobile framework: Web-based, appstore, desktop, mobile?

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the eigth step - Choose if your app should be web-based or an actual app in the appstore or both, should it be mobile and desktop?

As mentioned in the original post, this one isn't always easy to figure out. Usually you want your app/product to target all end-users, no matter what kind of device they are on. Usually you can list up a couple of questions to figure out how to choose target devices/platforms.

Who is your target audience?
For this project I do need to integrate into VLEs (virtual learning environments) at some point, but more customers require the end-product to be accessible on mobile devices. This points me towards a web-page/web-based application, as some of the code most likely can be ported between a mobile app and a VLE integration. My target audience uses both mobile and desktop platforms, so I need to target both.

Should the application be mobile, desktop or both?
Second, I look at what sizes/types of devices I need to target. My current project needs both to be accessible through desktop computers, as well as through mobile devices. Again this points to having a common code-base, so a web-app would be great. Although some frameworks provide this for native as well.

Can the application be a web-page, or do you need it to be native?
So it all comes down to the question of being native on a given platform. That is usually a question of performance, but not necessarily. As there will be some animation, drag and drop, sound, I think from a performance perspective it would be good to have a native app, but if a web-app performs OK, why shouldn't I just wrap that in any of the app-wrappers?

When looking at performance, always test on low-end devices. If you can get your app to perform well there, high-end devices shouldn't be a problem. For instance, I created a small drag and drop test in a web-app wrapper. Works perfectly well on a Samsung Galaxy S2 and Galaxy Tab 10.1, terrible on the iPad 1, bad on an iPad 2, and is totally unusable on a HTC Wildfire as well as on a Samsung Omnia 7.

Basically that is because of the JavaScript interpreter on each of the platforms is different, as well as the raw cpu-horsepower. I'm surprised to see that much difference between iPad 2 and Galaxy Tab, but I know Google and Apple has various JavaScript engines in each of their respective WebKit code bases. As for the Wildfire, I'm not surprised, as it had Android 2.1 and only a 600 MHz cpu, which isn't really that much.

However, the app I created was a quite simple animation, as well as some drag and drop touch gestures, so I suspected it to perform better.

This points me towards a native app instead.

So 2 points for web-based, 1 for native. Although the performance factor is more important than common code-base, so I would say it's a draw for now. I will review this when looking at each of the frameworks later on.

Wednesday, February 22, 2012

Choosing a mobile framework: Make a list over frameworks you do want to look into

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the seventh step -  Make a list over frameworks you do want to look into ?

It is important to list any framework you think it's worth considering, and probably a few that you don't think is worth considering, as it's quite critical to select the right framework in order to save development time after you have learned a framework.

This is not the step where you start looking at every detail about the framework, only find them, briefly read about them, and decide yes/no on the question: Can I consider this framework?

The frameworks I consider for this project are:
You shouldn't even consider pricing of the frameworks at this point, although that might be a major factor to considering a framework.

You might want to consider the platforms you are choosing when looking at various frameworks. For instance, I prefer if a frameworks supports all the platforms I want to target, but for now, I will consider platforms that support at least iOS and Android.

Why don't I include AppInventor, DragonRad, DroidDraw and other click-and-create frameworks? Well... Quite simple: Try to do graphics/drawing/physics in any of them. If you just need forms/push buttons and sending/getting data to/from a website, sure, use any of them, but as soon as you move out of what a click-and-create framework can provide, you should consider a real framework where you can do some actual coding.

If you are going to be a mobile developer, be sure to choose a framework that doesn't limit you from your creative ideas.

Update 7/3: Added cocos2d-x

Friday, February 17, 2012

Choosing a mobile framework: Any programming languages you want to avoid?

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the sixth step - Any programming languages you want to avoid?

It's better to consider languages you want to avoid rather than listing the ones you do want to dig into. If you start selecting a programming language, you will limit the number of frameworks you can consider.
Example: you only want to write in C#, there is Mono/Monotouch and of course MS .net. But what if that platform doesn't support the features you need?

Since the syntax of languages today is barely dialects of one another, you should as a developer/programmer be willing to jump into a new language, just as much as a toddler wants to learn how to walk. (Yes, I have a toddler at home).

When you have learnt 3-4 programming languages, you start seeing the similarities, and the differences, and you usually figure out that most languages are very closely related. It's just another object, a function, a variable, an array here, a hash there etc.

Although working on several languages can be confusing at times, always keep reference manuals close by when you are stuck.

I only have one language I always want to keep away from, and that is VB. I always end up using more time figuring out why on earth Microsoft never put VB out of it's misery...

When you have compiled your list over languages you don't want to learn, go through it again, and consider if you really do want do choose a framework that suits the needs for your project, or suits your programming language skills.

Choosing a mobile framework: Choose the platforms you need to target

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the fifth step - Choose the platforms you need to target

This should be fairly simple, as you just have to list up the platforms you want to support. However, it is a good idea to also consider if the application should be for smartphones, tablets and/or desktops.

Here's a few examples:
  1. You are going to make a game for tablets, but the game would be just as good on a desktop. You should consider if you need to develop the same twice (1 for desktop and 1 for tablet) or if you should have 1 codebase for both.
  2. You are making an app for smartphones, but hope it can be reused on tablets. Should you go all the way to desktop as well, or stick with smartphones only, and perhaps make a minor tweaked version for tablets?
  3. You are going to develop a desktop-only application. My question today would be: why? Wouldn't it be better to do a desktop + tablet or web version?
Basically you end up looking at both platforms and technology, when choosing which platforms to support. I do however recommend just choosing platform and form factors in this step and if needed change when looking at frameworks.

For my project I'm only targeting smartphones and tablets, however I do see that the application can work for desktop as well. So I will try to write reusable code. Reusable code is usually either very low level code or very high level code, while languages that are wrapper for low level quite often end up being quite platform specific.

For instance, VB and C# libraries isn't reusable across platforms, but C and JavaScript libraries is most likely reusable. (JavaScript is depending on the platforms web browser capabilities). There are more factors than only the language, but I've more or less always been able to adopt/port a C library to any given platform.

My conclusion for my current project will be to support in the following order:
  1. Android and iOS
  2. Windows Phone
  3. (Windows 8 Tablets, if released...)
  4. Desktop
For form factors this is my priority:
  1. Tablets (7 inch and up)
  2. Smartphones
  3. Desktop (15 inch and up)
In a matrix to summarize:

Tablet Smartphone Desktop
Android 1 2 -
iOS 1 2 -
Windows (7 and newer) 4 - 3
OS X (Lion+) - - 3
Windows (XP/Vista) - - 5
Matrix for preferred platforms and form factors

Since MS is very likely to release Windows 8 with tablet support, I need to consider that already now, as that might end up being the third major tablet-market player. Why didn't I include Googles chromebook? Currently I have 0 demand for chromebook versions, and that isn't likely to change within the next 12-18 months.

So focus is iOS and Android tablets first, smartphone second, then perhaps desktops (Win 7 + OS X).

Thursday, February 16, 2012

Choosing a mobile framework: Non critical functions

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the fourth step - Chossing/Identifying the features that aren't critical to your app, but nice to have.

It should be fairly simple to do this step, as you should already have an idea of what you haven't written down in either step 2 or step 3.

For my current project it was only Text to Speech that isn't critical. I do want to implement it in my app at some point, but it can come later.

It is recommended to do a bit of research on these features to see how hard they are to implement. If they are easy enough, you might want to implement them instead of adding them to the todo list.

I did quite a bit research on Text to Speech, and it's fairly simple to implement if you aren't using a framework, and are coding native on at least iOS and Android, but for frameworks, it still looks like a no-go. However, there are a few third party companies building TTS engines that might work for my app, so I need to see have hard it is to create a plugin/module for any chosen framework as well.

This leads to adding a feature to step 2:

  • How hard is it to create plugins/modules?

I'm not updating step 2 with this, but I'll keep it in mind when comparing various frameworks.

Wednesday, February 15, 2012

Choosing a mobile framework: Identify which critical functions you think it's OK to implement/write for yourself

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the third step - Identify which critical functions you think it's OK to implement/write for yourself.

It should be fairly simple to narrow these elements down, if you still have something left on the list from the first step. You should always consider each function that you want to implement yourself, if it might be better to let the framework handle it (if it can...).

I need the following to functions in my current project:
  • Basic image manipulation
  • Drawing/Painting

Let's have a closer look:

Basic image manipulation: I need crop, rotate and zoom. These are fairly simple to implement. If the framework has image manipulation, I will weigh towards it, but it's not that critical. My current project can even survive without it.

Drawing/Painting: I need to be able to draw simple figures. I do have some SVG's that I do want to use for drawing some simple images, which should be possible to fill. I've added a google presentation below to show it. This can be implemented as a canvas (html5), opengl, some native drawing wrapper, or other options. I prefer if it has some built in 2d vector functionality, but falling back to opengl is also acceptable. (And would probably perform better as well)

As my app cannot function without drawing/painting, I do feel this is so critical, that it's worth using most of the development time on this area.

Here's what it should be able to do:

Note about the image: I've used images from google image search, so if you do have a copyright on any of the images, please let me know, and I'll be sure to mention you in the post, or remove the image if you don't want it in the sketch.

Some of these features might require quite an amount of work to implement, so always consider if you either learn a great deal about the framework, the platforms, programming techniques, and if you can reuse any of the code in a later project. Also consider if you can use any third party helper libraries to ease your development, and probably speed the development time up as well. However, you are in full control when you write from scratch.

Choosing a mobile framework: Identify critical functions, you don't want to implement yourself.

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the second step - 
Identify critical functions, you don't want to implement yourself.

You need to identify which functionality you don't want to implement yourself, in order to figure out what framework to start with.

This is most likely core functionality of a framework or third party libraries for the framework. I prefer core functions over third party libraries, as you never know when a third party library might stop supporting newer versions of the framework or newer platforms. (Well, to be honest, you newer know this for a framework either, but is usually a risk worth taking.)

What are critical functions you don't want to implement? I mean functions that you shouldn't need to go into native code on each platform supported by the framework. For instance if you do want sound in your application, that is most likely a critical function.

From the list from step 1 I had three functions that the framework needed. As the application I'm working on is a bit larger, and I do want to "future-proof" myself, I expanded the list a bit to the same as in the original post.
  • Drag and Drop
  • Basic access to camera
  • HTTP(S) request support
  • JSON support
  • Custom user interface elements (Must be possible)
  • Custom user interface placement  (Must be possible)
  • Audio playback (simple)

Why I don't want to implement these functions myself?
Let me go through each function:

Drag and Drop: I've done drag and drop before Qt natively supported it, and it was a hassle. I've done drag and drop on the web before there was a properly cross-browser drag and drop javascript library. It wasn't worth the workload.

Basic access to camera: It will be diffcult and timeconsuming to make sure you are up to date on all platforms/devices for this one.

HTTP(S) request support: It's not that difficult to implement if the platform supports tcp sockets, but it's better if it's supported directly.

JSON support: There are tons of libraries for json, so that should be fairly simple to implement yourself, but since there are that many json libs, it's likely that one or another is built into the framework. It's easier and better to choose a framework that already has it.

Custom user interface elements and placement: I do need a bit more than push buttons and text fields. Who doesn't? There are enough text-box-push-button-radio-button apps out there. However for this step it's important to figure out how to implement it. Does it require OpenGL, are there core graphics functions for custom UI elements? Do you use HTML/CSS? How is the performance?

Audio playback: Should be fairly simple to playback a mp3/wav or similar file on the given platform. For this project it's non-critical when looking at latency, but I know already that if latency is critical, Android is currently not possible, however, I know that Google has this on their roadmap, so maybe later.

This raised a few questions for each functionality, which will be addressed when digging into each framework.

Tuesday, February 14, 2012

Choosing a mobile framework: Listing all the feature you need

This is a follow-up for Choosing mobile dev platform/framework and looks closer at the first step - Listing all the features you need.

To figure out what features you need, you need to sketch up your application and figure out what each screen/image does. How you create your sketches is really up to you. I usually use Google presentations, MS Powerpoint, Adobe Photoshop, a simple drawing program, a notepad or what feels right.

I've created a small small sketch one part of the app I'm working on. The rest of the sketches are with pen/paper.

Basic sketch for one of the parts in my project:

Note about the images: I've used images from google image search, so if you do have a copyright on any of the images, please let me know, and I'll be sure to mention you in the post, or remove the image if you don't want it in the sketch.

Basically this part consists of selecting something you want to do and, then you are given a drag-and-drop activity which again gives a reward. This is mostly used for training people with special needs in order to coordinate movement, and/or work with cognitive stimuli. Usually this kind of apps are fun for kids as well.

From these sketches I see that I need the following features:

  • Images
  • Buttons with text
  • Audio playback
  • Drag and Drop
  • Animation or video playback

Now I remove some features which I assume any framework supports, and if it doesn't, it's probably worth skipping that framework.
  • Images
  • Buttons with text

Then there are three functions which is needed:
  • Audio playback
  • Drag and Drop
  • Animation or video playback

The rest of the list from the original post also included : "Basic image manipulation, Basic access to camera, Drawing/painting, JSON support, HTTP(S)-request support, Custom user interface placement, Custom user interface elements."

You now have a feature list for your framework and you are ready to move on.

Monday, February 13, 2012

Choosing mobile dev platform/framework

After going through all the various frameworks, I'm close to finding which framework I will use for some projects, and which isn't really suited.

Here's some steps that will help you to identify which framework to start with for a project, and one example from me

1. List all the features you need
Figure out ALL the features you need for a project, not only the most important ones. Include anything that might be a function or feature.

My feature list for one project is:
  • Drag and Drop
  • Text to Speech
  • Basic image manipulation
  • Basic access to camera
  • Drawing/painting
  • JSON support
  • HTTP(S)-request support
  • Custom user interface placement
  • Custom user interface elements
  • Audio playback (simple)

Choose all the features that you cannot be bothered to implement yourself, which you feel the framework should handle and you . (Or a third party plugin to the framework)

The critical features for one of my current projects
  • Drag and Drop
  • Basic access to camera
  • HTTP(S) request support
  • JSON support
  • Custom user interface elements (Must be possible)
  • Custom user interface placement  (Must be possible)
  • Audio playback (simple)

Basically the opposite of 2. Critical functions that must exist in the app, but you do feel it's ok to write/implement these yourself.

Only 2 things I think I need to write for myself, and can accept doing.
  • Basic image manipulation
  • Drawing/Painting

Any features you think your app can be release without, but they should be there later, bonus for the framework if it's already in-there/supported

Basically the features from 1 that aren't in 2 or 3. For my project that would be:
  • Text to speech

Any platform you do need and/or your target audience uses.
I need to target:
  • Android (both phones and tablets)
  • iOS (both phones and tablets)
  • Windows Phone 7 (currently only phones, but most likely tablets in the autumn)

If there are any languages you don't want to learn, and therefore need to avoid, write them down so you don't end up choosing a framework that only supports a language you don't like.
I only have 1 language I prefer to never write software in, as it usually ends up limiting what you can do on a platform: (And the syntax sucks)
  • Visual Basic/Basic (I've used it way back, and it "does not compute...")

Any framework you think it's worth considering. Later on you will need to consider why you should choose a framework or why you should avoid it. There are many factors worth considering when choosing your framework.

The frameworks I consider for this project are:

This one isn't always easy, as you probably want both desktop, mobile, web-based and non web-based. Consider what your target audience is. Usually it's easy to combine web-based mobile app with an actual app or a desktop app with an web-based app, but making it to all three with one codebase is most likely going to be diffucult, or will require a lot of hacks in your code.

I needed an web-based app for integration in VLE's as well as a actual app in the appstore. As my current target audience are schools with VLE's, but they are moving fast forward into tablets, I found this difficult. I chose to target tablets and phones through the appstore first, then VLE's through web later.

This is the timeconsuming part. You probably want to use a few days for this one, and there are tons of articles to read up on various frameworks. 

Update 14/02/12: I missed a few features I need for the project I'm using as an example

I'll follow up on this post going through each step, and with some links to pages that are worth reading regarding frameworks, as well as how I narrowed down which frameworks I'm considering for this project.

Steps in details:

  1. Listing all the features you need.
  2. Identify critical functions, you don't want to implement yourself
  3. Identify which critical functions you think it's OK to implement/write for yourself
  4. Choose which features that isn't critical, but is "nice" if the framework handles
  5. Choose the platforms you need to target
  6. Any programming languages you want to avoid?
  7. Make a list over frameworks you do want to look into
  8. Choose if your app should be web-based or an actual app in the appstore or both, should it be mobile and desktop?
  9. Start investigating the features of each framework
    1. Marmalade SDK
    2. Appcelerator Titanium
    3. Moai SDK

Friday, February 3, 2012

Convert from svn to git

Time to convert all those old SVN repositories to GIT... I'm using bitbucket for everything now.. On ubuntu do "apt-get install git git-svn" first

Short script to do it all: (it's not perfect, but it does the job...)

# variables:
# existing svn repository
# new git repository
# username

# DO THIS FIRST TO CREATE USERLIST: (just do it manually, and add all users into one big file)
# for getting authors
# svn log $SVNREPO -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" quot;, "", $2); print $2" = "$2" <"$2">"}' | sort -u > ~/svn_convert/authors-transform.txt
#now edit ~/svn_convert/autors-transform.txt

#create temporary git folder
mkdir git_tmp_repo
cd git_tmp_repo
#clone repo to git
git svn clone --no-metadata -A ~/svn_convert/authors-transform.txt . -T $SVNREPO

#optimize repo
git gc
git fsck

# clean SVN sections from Git
git config --remove-section svn
git config --remove-section svn-remote.svn
rm -rf .git/svn .git/{logs/,}refs/remotes/svn/

# add remote
git remote add origin $GITREPO

# push to master
git push -u origin master

# remove temporary git folder

cd ..
rm -rf git_tmp_repo