The general response to the recent security leak in Facebook mobile apps seems to be “why don’t they just encrypt the password or access token before storing”. But is that really the solution?

Basically any encryption that happens on the device without user interaction has to have all parameters for the encryption/decryption available on the device. It’s not that much more secure as just storing plaintext as any user/app with root access can get access to all necessary parameters for decryption.

A secure way to handle passwords/tokens would be to
a) not store them at all  and make the user login each time or
b) store them in an encrypted keystore that requires the user to enter a keystore password every time the  the app needs access.

Users generally don’t like these options for 2 reasons.

1. users don’t like to enter passwords frequently on their mobile devices
2. it makes background calls to the server when the device is not used harder to implement because the app cannot access the password/token without user interaction.

In the end, app developers will have to make a trade-off between security and user-friendliness or support both secure and less secure ways of storing credentials and have the user decide which level of security he is most comfortable with.

I woke up this morning to an article in my twitter feed titled Fragmentation is a bad excuse. Here’s a follow up with my views on Android fragmentation as a developer who has put food on the table for over two years by doing nothing but Android development work.

Yes, Android is fragmented based on screen size, hardware specs and OS versions but it’s not a huge problem like a lot of people say it is. On the contrary it’s a feature of the platform. Probably the most important feature responsible for the success of Android.

Android was built from the ground up to be compatible with multiple screen sizes and hardware specs. Because of this we now have the luxury of being able to buy an Android device suited to our specific needs. It doesn’t matter if you prefer a large vs a small screen, a hardware keyboard vs software input, a 1Ghz+ quadcore vs a 600Mhz single core, a device from an A brand vs a Chinese copy or maybe you just want the best available phone for you specific budget. There will be a device available for your needs. This is only possible due to the so called “fragmentation”.

Version fragmentation

If I got a penny for every time someone says “but Android 4.0 only runs on 0.x percent of devices”, I would be rich by now. It’s true that manufacturers are quite slow in adopting new Android versions for new and existing devices. But as with hardware fragmentation, this is not a big deal. As of march 2012, 92% of devices are running Android 2.2 (Froyo) and higher. The Froyo feature set is a really good base line for most of the applications. I challenge you to find a new feature in higher versions that you really need to have in a general purpose app. (and is not already in the compatibility libraries)

Developer tools

Also for developers the situation isn’t that bad. If you have spent at least 5 minutes on the Android developer site you should have noticed that the SDK is full of tools to help apps deal with all these different configurations.

• Developers can provide different graphics for different screen sizes
• There is an emulator and UI builder that can emulate any Android version, screen resolution and pixel density combo
• RelativeLayout component to scale your layouts
• The ability to override layouts for specific configurations (for example to rearrange or remove buttons when screen space is limited)
• Compatibility libraries that bring important new features to older versions
• The ability to call new api methods while remaining compatible with older versions
• and more

Games

There is one area where fragmentation leads to some problems and that is game development. Due to different hardware specs in the CPU/GPU department developing games for Android can be challenging. For example some shaders are not supported by hardware type A, are not working at all on type B or have inconsistent behavior on type C and D. But this behavior is not new. Windows game developers have had these problems for over 10 years and managed to deal with it.

With all that said, if you’re not a game developer, fragmentation shouldn’t be an excuse for not writing Android apps.

If you’re a consumer, you should be glad that you have the ability to choose a device that tailors to your specific needs and aren’t forced onto one configuration that fits “most people”.

If you’re one of those people saying “Android sucks because it is fragmented” or “Android 4.0 runs on 0.x percent of devices” I congratulate you on reaching the end of this post and hope that you learned something today.

You should follow me on twitter here

In the past week I’ve been playing with the git-svn bridge because one of my new projects is using Subversion as VCS. It turns out that even with Subversion as the central server, you can still use most of the fun features git has to offer. This post is a short introduction to the tool. Continue reading →

Ever since I got a smartphone I have been suffering from the “popcorn brain” syndrome. Having popcorn brain means being so used to the fast-paced, always changing and always connected way of life in the online world so the offline world becomes too slow.

I became aware of my “condition” when I noticed that every time I had a dead moment, I grabbed for my smartphone to check twitter/facebook/mail/whatever. It even got so bad that when I stopped at a traffic light, I checked twitter, it became green so I moved and 500meters down the road I stopped again and almost like a reflex my hand grabbed for my phone again. Continue reading →

Last week Mark Shuttleworth introduced the Unity HUD for the upcoming Ubuntu 12.04 release. It’s a total revamp of the traditional menu bar. Instead of using the mouse to point-and-click your way through the menu structure of an application, you can bring up the HUD with a keyboard shortcut, start typing the action you want to perform and the HUD will auto-complete the possible menu items.

As a power user I love this functionality. It allows me to invoke any action with just a few keystrokes and my hands don’t even have to make the expensive context switch between keyboard and mouse (and back). I already use a similar concept in two applications that implemented the same behavior themselves. One is emacs the text editor where I can press alt+X and type the name of the command I want to invoke. The other is Intellij the Java IDE where I can press Ctrl+Shift+A and start searching for any command and associated shortcut.

Intellij action search

For average users however, there is still a problem with the current HUD implementation: discovering unknown menu actions. For the past 30 years we have been trained to quickly find what we want in the menubar. With just a mouse click a list of possible actions was presented. One click more and the desired action was executed. With the HUD there is currently no way to display all possible actions so the user is forced to guess the correct name of the action he wants.

Currently the Unity developers solve this problem by still showing the original menu bar in addition to the HUD. But the Unity roadmap shows that this is a temporary measure. I am very curious to see how the developers will implement this discovery functionality into the HUD. If done well I can see the HUD becoming the new standard for interacting with applications so we can finally get rid of the 30 year old menu bar.

About a year ago I released and app on the Android Market called Bookmark to Desktop. It is a simple read-it-later app that allows the user to send a link from his phone to his desktop browser (chrome/firefox) for later reading. Along with the release I wrote a blogpost explaining how and why I wrote the app. The article also explained why I chose Google AppEngine for hosting the service.

The app has been running fine for a year. The growth of users and shared bookmarks increased every month but never so much that it exceeded the free quota for the AppEngine hosting. Which was nice, as I had no intentions at all for monetizing the app. As I explained in the article, I wrote it because I needed it myself, and because it did not cost me anything to host so I shared it with the world.

Last week, I received an email stating that GAE will go out of preview soon and will update its pricing scheme in September. Attached was a link to the estimated cost of my app under the new pricing scheme. It turns out running the service as of September would cost me well over 100 euro/month, which means I would be providing the service at a loss.

Given this new pricing scheme, I am forced to monetize my app or scrap the project. Killing the project is the last thing I want to do. I started trying to monetize my app just to get break-even but as I have no experience at all with this, it is not going well. (The app does not have recurring screens to put ads on and features are basic so there is not much extra to offer in the paid version)

For now, the only option I have to keep costs down to a minimum is to scrap the biggest feature. The push to desktop feature. As that feature alone is consuming most of my quota. By disabling this feature, I feel like I am screwing my users by providing them a feature as a selling point for my app and then take it away.

I am sure that I am not the only app developer with this problem. It would be nice if the new AppEngine pricing scheme provided a kind of free plan for projects like mine. For example like GitHub does, their service is available for free as long as your app is open source. Having a plan like this can keep small projects alive.

Twitter 
Google+