This was originally supposed to be a post on predictions. But as the founder of a mobile app development company myself, my focus is more on specific opportunities that exist for a boutique company such as ourselves in this space.

First let’s look at some facts:

Now take a look at some major trends:

• HTML5 Mobile: The browsers from every big player are getting more powerful. The open source tools are getting better and better. And with the Flash war finally having ended, Adobe is finally getting on board as well.

• Cross Platform Tools: These tools make it possible for the app developer to write-once-and-run-on-multiple-platforms. Or at least they try to make that possible. Multiple acquisitions and fairly large VC investments have happened in this space.

• Hyper-Local-Mobile: The early movers in this space are continuing to grow or have been acquired. But the new players are doing well as well.

• Cross Device Testing as a Service: With more than 300 Android handsets now available from various manufacturers, it is next to impossible to manually test an application across all these devices. There are now multiple services on the cloud that aim to solve this problem for you by automatically testing your Android applications across a wide array of devices.

Keeping the above in mind, here are a few opportunities for 2012:

• “Hybrid” Cross Platform Apps: The cross platform tools I’ve referred to above, allow for native platform API [Application Programming Interface] calls as well. These are useful when you have an application that has a combination of native components and other “content” components which most likely consume web services [and can be built with HTML5 and CSS3].

An example of such an application is the Onion iPad app. The application is written in HTML5 for the most part – but uses falls back on native API to play video. This is probably because of some of the issues related to HTML5 video tag support on iOS. The Onion plans to roll out the app quickly on the Android platform as well – and with mostly the same code [pdf].

Main Challenges:

• Cross Platform Tools are not mature yet: The API documentation is sparse, support is patchy and the community is still nascent. So which platform should you bet on? Unfortunately, the answer is, “it depends” – on multiple factors such as whether you need a native look and feel (which Appcelerator and Rhodes provide – but PhoneGap does not), the number of platforms you need to support, the technical skills of your dev team etc.
• The Mobile Web is Slow(er): Performance optimization is key if you want your site to look pretty and be snappy on mobile devices. There are many good resources available to get you started in the right direction.

• Low Cost Solutions for Mobile Optimization: While purely content based sites can choose to rely on the Mobile Optimization Services I’ve mentioned above, there are a lot of other verticals that don’t have such an option – yet. For example, there are a lot of E-Commerce sites out there that are not mobile optimized. Especially those being run by small business owners or startups.

Main Challenges:

• The data has to kept in sync with the original systems – in a seamless fashion
• Mobile payment gateways are still far from mature - especially in a country like India.
• Oh, and the Mobile Web is Slow – but I said that already.

Main Challenge:

• Add default.properties in the library project and add android.library=true in the same
• Run the command in the main Android Project android update project –path . –library ../path-to-the-library/Note: This always has to be relative path.
• Now running ant release should build the library project too.

Note: The android command mentioned in the second step adds an entry in the default.properties file. If you need to override that in different environments, override that in the local.properties. Even there, it has to be relative path, the absolute path will not work.

Image via Wikipedia

A couple of days back I watched an interview with Joel Splosky on Mixergy.com. Joel Spolsky recently launched a new product “Trello”, an online collaboration tool. In this interview he explains a few strategies/tips that went into building and launching a new product based on his experience.

Here are a few takeaways which I think are worth summarizing:

• Delivering Continuously

Trello follows a process of continually delivering the product in small, tiny pieces. So instead of big releases that happen every month or so, the product is instead shipped everyday [maybe even multiple times each day]. To achieve this, the pipeline of work starting from the designer to  developer to tester and finally to the customer is always “in motion”.

• Pivoting endlessly in the early stages

You build something quickly for the first version. Then you try getting real users’ feedback. You can fail early here and this will force you to change direction multiple times while building the product. This is what is called Pivoting. By pivoting you’ll eventually take the right direction and get to product-market fit. At this point the product is actually creating great value to your users by giving them what they wanted.

• Knowing your marketplace

One of the reasons that most products fail is that they do not fit into the marketplace. They are simply built because it was imagined to be useful and what the customers might actually want would be something very different from your product. Joel says, a product must be created by keeping the “need” in mind. If your product solves a customer’s problem, then you know your marketplace.

• Getting early feedback from the users

One of the best things one could do is getting to use the product internally i.e., within a closed circuit of users in the very early stages of the product. By watching them use the product and getting to know what they think, would be a great way to improve and polish your product.

• Launching your product for free

The classic mistake that we often commit while launching a product is that we charge the users from day one. This will actually drive away your customers from using your product.

Users are not ready to pay for a product if they find that have to pay something for just trying it out even if it is dirt cheap. So it is more important to get the attention of a customer towards your product. And, once the customers find that your product is highly useful, advertising your product becomes easier.

Joel points out a few reasons for giving away his product for free:

• Giving away for free is itself a form of advertising your product.
• Getting the audience/users to use your product is the most important thing and this can be achieved only by this form of advertising.
• Later when you make it paid, you’ll still have users who are getting real value out of your product.

You also make it less sweet for others to compete with you and helps you get a longer runway. This particular point was not said by Joel in the interview, but something I saw in the comments. And I think it made enough sense to include here.

Tried and Tested By Others

Some of the above techniques have been used by others like the team which created Pivotal Tracker, an application with some similarity to Trello – but more specific to Agile Software Project Management..

One of them is what Joel asks every team, that is, to “use your product internally”. The team that built Pivotal Tracker used it within their team members in the early stages of the product. They improved the product based on the early feedback from the users.

Also, Pivotal Tracker was launched for free initially and later the pricing was included for their product.

Learning and following what great teams have done is a good way to reduce risk of failure and increase odds of getting it right the first time. Or at least the second

OpenGL is widely adopted as the graphics API of choice for real-time interactive 3D graphics applications. OpenGL is easy to understand, but its simplicity and orthogonality enable many interesting possibilities. One such possibility is image processing.

Using “OpenGL” for Image Processing enables us to completely utilize the power of Graphics Processing Unit (GPU) hence the image processing will be faster also it reduces the load on CPU. This can be crucial for Image processing applications, especially in mobile environment where the resources available are relatively lesser.

In this post we will be discussing how to use OpenGL Shader Language to manipulate pixels and create Image filter effects.

As with any OpenGL app, we will start with setting up the view.

The next step is to load an image into the texture, This texture can be mapped on to the surface of a square, which will then be drawn on to the screen.For Image processing, we will require only 2 dimensions so we will set up the view in orthographic projection and will also discard z axis by keeping it to 0.0 most of the times.

But before drawing to the screen, there are many intermediate operations that are done by the graphics hardware, which are now directly programmable in OpenGL ES 2.0 using Shader Language (GLSL).
We will be concentrating on Vertex and Fragment processing phases in OpenGL pipeline. We will go through a simple fragment shader program and will explain how it works. Both of these programs are written in GLSL. GLSL is a ‘C’ like language which gives direct control over the  graphics pipeline without having to use assembly language or hardware-specific languages.

Vertex shader

uniform mat4 uMVPMatrix;
attribute vec4 aPosition;
attribute vec2 aTextureCoord;
varying vec2 vTextureCoord;
void main() {
  gl_Position = uMVPMatrix * aPosition
  vTextureCoord = aTextureCoord
}

The Vertex shader is executed for each vertex that is to be drawn. Here, we are drawing a square and mapping the texture on to that.

This calculates the transformed coordinates of the square by multiplying the given coordinates with MVPMatrix [ MVP -  Model * View * Projection ]. Other than this we are also storing corresponding texture co-ordinates in variable ’vTextureCoords’ so that it is available in the fragment shader.

Fragment Shader

precision mediump float;
varying vec2 vTextureCoord;
uniform sampler2D sTexture;
void main() {
   vec2 cen = vec2(0.5,0.5) - vTextureCoord.xy;
   vec2 mcen = -0.07*log(length(cen))*normalize(cen);
   gl_FragColor = texture2D(sTexture, vTextureCoord.xy-mcen);
}

Fragment shaders are executed to calculate the color of individual pixels. This is where the actual image transformation happens. Instead of mapping the corresponding texture coordinates to corresponding pixels, we can map different coordinates of the texture to different pixels which will distort the image in some way. In the above example the texture co-ordinate to fill each pixel is chosen based on the calculation in line no 6. The actual movement depends on the distance of the texture coordinate from the center. This creates an effect which is similar to what is shown in the below picture.

Although this is a very simple effect, the intention here is to just show potential applications of OpenGL in Android apps.

Generate the build script for test

The suggested practice is to have 2 separate projects for android, one the source and the other for the tests. The following command will generate a build.xml for the test project. Replace the with the path of the source path.

android update test-project -m ../<project-path> -p .

One problem I’ve seen is that, it does not break the build even if there are failures in the test. Issue is reported here:

http://code.google.com/p/android/issues/detail?id=14241

I had to override the run-tests target as mentioned below to fix this issue:

<target name="run-tests" depends="-install-tested-project, install"
description="Runs tests from the package defined in test.package property">
    <echo>Running tests ...</echo>
    <exec executable="${adb}" failonerror="true" outputproperty="tests.output">
        <arg value="shell" />
        <arg value="am" />
        <arg value="instrument" />
        <arg value="-w" />
        <arg value="-e" />
        <arg value="coverage" />
        <arg value="@{emma.enabled}" />
        <arg value="${manifest.package}/${test.runner}" />
    </exec>
    <echo message="${tests.output}"/>
    <fail message="Tests failed!!!">
        <condition>
            <or>
            <contains string="${tests.output}" substring="Error" />
            <contains string="${tests.output}" substring="Fail" />
            </or>
        </condition>
     </fail>
</target>

You can change the ant commands to clean run-tests release in Jenkins to run the tests as part of packaging.

Next I will be writing about how to start emulator from Jenkins while running the tests.

Image via Wikipedia

We constantly try to provide accurate estimates that we can defend with confidence. But there are situations where we end up making mistakes. And this post describes one such situation.

One of our clients asked us to estimate a feature. As usual, we sent back an estimate without much delay.

After few days, our client asked us to implement this feature. When we started to think about implementing the feature we found that it would take at least double the time that we’d earlier estimated. We’d put ourselves in a bad situation. It would of course be very hard to convince the client as to why there was this much deviation – considering we discovered this even before actually starting to implement the feature. We did the 5 why’s to get to the root of the problem.

We discovered the following reasons:

• We hadn’t gone through the usual process of breaking down the feature to the desired level of granularity. Digging deeper, the following root causes emerged:
  • The project had been on ‘pause’ mode for a couple of weeks and we had gotten busy with other things in the meanwhile.
  • The value of the feature [to the end user] was not completely obvious to us.

The solution? We’ve decided to ask ourselves the following question before sending across an estimate to any client in the future:

Is this a confident estimate? Can we defend the estimate with proper reasoning?

The above will force us to think again about the estimate and help us become more consistent.

Oh, and one more thing. Ask the stakeholder as to what value the feature is going to add – if it is not obvious. Don’t assume that you’re right!

If you’re curious on what the client’s reaction was, when we sent across the revised [and much larger] estimate, ask us in the comment below We’d love to hear from you!

We’ve set up our CI server for building android apps. We use Jenkins as our CI server, but the same steps can be applied to any CI server.

Setup Android Environment on CI server

You need to first install the android SDK and platform tools on the CI server. The steps are well defined here. You can run the command android update sdk --no-ui if the CI server is in an headless environment.

Generate Build script

Using android SDK tool , you can generate build script for the android project which contains the standard steps for building the app such as clean, compile, release, install etc. The following command will generate the build script, replace <appname>, <target> and <project path> accordingly.

android update project -n <appname> -t <target> -p <project directory>

This will create build.xml file under the project directory. You need to create build.properties file with the following contents:

key.store=path-to-keystore
key.alias=[alias]
key.store.password=[pw]
key.alias.password=[pw2]

You can generate the key file using keytoool or you can generate the key file from eclipse. Run the command  ant clean release, which will compile the files, and generate the apk files (it generates signed, unsigned and unaligned files). The signed version can be used for uploading to Android Market or for installing directly on any device. Couple of stuff to be noted here are:

• Ant version has to be 1.8.0 or higher.
• Put the external libraries in the libs directory. Build script automatically picks up the libraries put under libs directory, otherwise the script need to be changed to look at a different classpath.

Checkin the build.xml, build.properties and the key file into the repository.

Setup the CI server

The CI server has to run the ant script for building the app. One more setting what we’ve done in our Jenkins server was to archive the apks as artifacts (available in the post build action). In upcoming posts, I will cover how to do the following:

1. Running android tests
2. Running code/test coverage tools
3. Actual deployment

References: http://skaug.no/ingvald/2011/09/android-app-with-jenkins/

For this problem there are two possible solutions. Take some time from your project schedule to rewrite some part of your test suite. Although this is the ideal solution to the problem, this might not always be an option for you because of delivery deadlines. The other alternative is to throw more hardware at the problem and this is where TLB comes in to picture.

One approach to solving the problem is to partition your spec suite in to different sets and then run them paralley in different machines. The problem with this approach is that it will take a lot of trial and error before you end up with partitions that takes almost equal time to finish. Also mainting these partition as you add more tests become a head ache. This is the exact problem the TLB fixes.

A detailed description of how to setup the test load balancer is available here. It should give you a very good idea about how TLB works and also about how do add load balancing to your build.

We are using jenkins as our CI server, so we will be concentrating on how to setup TLB on Jenkins. I am assuming that you already have the job [ to which you want to add load balancing ] configured in Jenkins.

The TLB setup has two main two components

Setup TLB server

Download the TLB server and install it on your CI server host [ again for detailed instruction look here ]. Optionally add a service startup script so that the TLB server starts up each time you restart the server.

Add balancing to your build

For Rspec TLB distribution comes with a ruby gem you can install this. Also the balancer requires a hook in to you build invocation process this too is available as a rake task in TLB docs, add this to your project.

Create Job Partitions

The setup for the jobs which run in different partitions are exactly same, only difference between the partitions are only the subset of test executed in each partition.

Create as many copies of the existing job as the number of partitions that you want to run. Additionally you can name each of these jobs as <job-name-n> where n refers to the partition which this job is going to run. Create an dummy job and configure the post build task so that all the partitioned jobs will be triggered simultaneously.

One option that might be required after setting up a build pipeline is the provision to redeploy an earlier version by click of a button. This can become handy when we find a bug in the production and want to see when the bug got introduced. For that we will have to redeploy the earlier version to the staging/UAT environment and test the same.

Jenkins by default does not allow to rerun any of the earlier jobs. But you can achieve this by the Rebuild plugin. It allows you to rebuild any job provided its parameterized build. It also allows you override the parameters. It will show the “Rebuild” button at the left side as shown below when you go to a specific build page:

This is not a replacement for revert build, because it does not take care of reverting DB. But this can be extended to do the same.

Note: It will show the Rebuild button only for those builds which occurred after installing the plugin. I took some time to realize this and it is not very clear in the documentation.