The study looked at the type of Android phone is used to review apps and made the assumption that if a particular phone resulted in significantly higher reviews for a category of apps, then the phone itself is creating some of that user satisfaction. Conversely, if the reviews of that category of app are lower, the phone is creating some of the dissatisfaction.

While this is not a substitute for market share numbers, these can be particularly hard to find. Beyond the “iOS vs. Android” level of statistics, it can be very hard indeed to find numbers at the level of specific devices. Generally the most granular level one can find is at the handset manufacturer level. This is helpful but only to a point – to launch a truly excellent mobile app the developers and testers need to know exactly which devices the customer wants the app to run best on.

Adding uTest’s data about app satisfaction to manufacturer market shares allows you to narrow down your choices – for example, a business app might be best optimized for the Samsung Nexus S which has the highest ratings in that category, and is built by the company that has 25% of the Android market.

Of course, there’s no substitute for direct study of your product’s own market. We often counsel customers to start on Android with a mobile web app using HTML5 which will run virtually the same across all Android devices. The customers you acquire using the mobile web app will give you a sampling of the devices you should optimize for with a native Android app.

Expect more active blog posting with news about our exciting projects and growth, and regular changes to the featured projects and customers. This time it won’t be three years before our next update, we promise! Finally, of course we welcome any feedback from you.

Seats are limited, so check the Facebook event to register.

TPL’s office is located in K300, Tan Binh District:

View Tech Propulsion Labs Saigon Office in a larger map

As you know, Apple doesn’t allow any interpreted or run-time compiled program, that why you don’t see Java, Flash or pure .NET applications on iPhone. Mono Touch is .NET based frame work, so why the application build by Mono Touch can be run on iPhone?  The magic here is Mono’s Ahead-of-Time(AOT) feature, it generates all native code that application could generate at run-time ahead-of-time, so the application deployed to iPhone is 100% native application.

Pros of Mono Touch:

• Developers can use their existing .NET experiences.
• Developers can take advantage of many .NET features like garbage collection, LINQ, web service, OpenTK…
• It includes a great interface builder tool.
• Mono is a cross platform, so it’s possible to port application build by Mono Touch to Android or Windows Phone 7.
• The productivity increases, because C# easier than objective-C.

Cons of Mono Touch:

• It requires a Mac.
• It’s too expensive. Mono Touch costs $1000 for one developer and $3999 for 5 developers with one year free update.
• The size of application is bigger than the same one build by objective-C because it needs to include the Mono framework.
• Apple banned Mono Touch on iOS 4, they have just lifted the ban a few days ago and we won’t know if they will ban it again later.
• Can not use things that it doesn’t support like XNA or Unity3D.

There are a lot about Mono Touch that i have not discovered yet. In general, it’s a cool framework for .NET developers to start making something on iPhone, the most popular smart phone that grow from zero to 80 million devices in only three years. But, in my opinion, i would like to start learning objective-C, because learning new thing is always good for you.

As a TPL .Net developer, I have just researched about StoryTeller for some days. I think this is a good automatic acceptance test tool because it uses the same mechanic as Fitnesse tool(also a BDD test tool), especially it’s built in .Net language. In current version (v1.0), It supports almost some basic features as Fitnesse features, such as:

• Support defining test case as executable specifications.
• Run test case automatically in two modes (local or remote) and export result in visual user interface.
• Support integration test, integrated with source control, and visual studio because it’s built in .Net.
• Manage test-cases in tree level and group in project.

About comparing with Fitnesse test engine, in current version, I don’t see a very big difference in features, except these things:

• It’s built in .Net and cleaner in core code and simpler mechanic (I reviewed its core code and see that not so hard to understand and use it), so there are immediate benefits for newbie to be familiar with writing test automation code.
• It can accelerate the process of creating tests by authored with a client written with WPF.
• In current version, StoryTeller focus on supporting developer to create tests well, not like Fitnesse, It supports tester and business partner to express requirements in wiki page.
• This is an open source tool, and I think it will has more great features in the future, and we also can customize it by our-self.

Anyway, as the author said, building a new BDD test engine, cleaner, simpler and integrated better with .Net environment, also old engine framework is the first goals in current version.

I like this tool and It can be considered to use as quite good BDD test engine in our projects.