Thanks,
Amar.

All applications are developed at the request of customers and no one is available in App Store, for example.

All applications meet the standards and pass through an internal process of quality first, and then external.

All customers are satisfied, especially when their applications meet the requirements requested.
While the applications meet the requirements requested by the customer, the customer is satisfied, regardless of whether such
application has gone through the JavaVerified process.

Nobody in the world’s interest that an application complies strictly with the UTC if it does not support the functionality originally requested.
No one I can tell your client: “Your application does not do what you asked, but rest assured! Your application meets with UTC!”

For example, a client asked for an application to perform a task in the background. The application should have no graphical interface and had to work
transparently to users. The application had to connect to a server to transfer data. If at some point the connection
was cut, for example, the application just had to wait to connect again … provided transparently to the user

The example application could never be certified because it violates some key points of UTC, for example:

-> AC1: Unable to create a flow of application that you can understand if the application has no graphical interface.
-> UI1 – UI2 – UI3 title, logo, help, about … are screens that my client does not want. Etc. Etc.

However, the application has been developed on another platform, is ethically and legally correct in my country and also meets quality standards and international processes.

I keep saying, as I said earlier, that our freedom of expression as programmers, on many occasions, is affected by this process.
I repeat: JavaVerified not know my customers and do not know what they intend, then, as it intends to ensure the quality level?

In conclusion, JavaVerified can check that our applications meet certain standards as the platform or device on which will work, but
can not speak so deeply about quality, because the quality of our applications are evaluated by our customers.

The example I gave is pretty extreme, but an example nonetheless. Could dal several more examples, but I do not achieve anything.

Only 30 or 40 opinions about an issue that should affect thousands of developers … Like the previous blog … not too little? no wonder why?

Greetings. Excuse my poor English.

Sebastian

Just to address the specific Java Verified point: you say “Java Verified is a racket: You pay money each time just to have your app rubber stamped, with a minimum of scrutiny.” This is an interesting point as Trusted Status is aimed at getting away from the developer paying money to go through an official testing route. We hope this will help. As far as the ‘minimum of scrutiny’ part is concerned, the scrutiny is all in the Unified Testing Criteria. This is the document we’re looking at reviewing, to make sure that the level of scrutiny is absolutely right. Once the app has passed the tests outlined in the UTC, it is ‘rubber stamped’: signed by Java Verified. The costs of doing all of this is exactly what we’re addressing within Trusted Status.

Regarding use prompts, again, we are hoping to address this, and fortunately some manufacturers, such as Sony Ericsson have found usability alternatives of how to handle prompts in a more efficient way. This is also available in the latest Nokia Symbian devices.

Just to make it clear: Trusted Status is not for a selected few. It’s for anyone who can prove that their apps meet the tests in the UTC on a regular basis.

Anyone who has problems with any of the 3 test houses needs to raise them with Java Verified through contact@javaverified.com. It is Java Verified who will make the final decision about whether or not the app should pass or fail. When you get the test results from a test house there is always the option to talk to them about the results, and if you are not happy with the outcome, it is important that you raise these concerns with Java Verified. Please do take this opportunity.

The reason for having the UTC is to make sure that every app is of a high quality *before* it goes out to the consumer so that the consumer is not faced with an app that has a poor user experience from the start. Over the last 3 months we have hopefully made a lot of progress in lowering the costs for developers to test their apps, starting with Simple App Testing and now moving onto Trusted Status. The reason we are now asking for comments about the UTC is so that we eliminate any confusion about what constitutes a ‘pass’ and ‘fail’ and remove any tests that shouldn’t be in there. In your case in particular, it sounds as if there were ‘grey’ areas, and it’s these areas we need to know about. What were they? What didn’t you agree with? Please let us know either via this blog or directly via contact@javaverified.com. This is exactly the kind of thing we need to know.

And finally, you state that yuo had to remove a lot of functionality from your app. It would be very interesting to understand exactly what you had to remove, as this sounds most unusual. Please let us know. Many thanks for your input.

Your comments about 3rd party testing are interesting, as all 3 Java Verified test houses test against all devices listed on the Java Verified website. We will contact you directly to find out more about your experience with the test houses, as presumably you didn’t end up getting your app Java Verified-approved for some reason? Thanks again. Very valuable.

- Some guidelines are given that make the app consistent to the user. For example, on touch screens, one tap or two taps to bring up the keyboard? UTC had this in the document. So all UTC apps can provide a consistent user experience. That is valuable.

As to submitting for 3rd party testing. That was not really a good experience. Firstly I had to do a screenflow diagram in one JPEG. My app has many screens, and one JPEG is really not enough. Hopefully this has changed now.

I submitted to one company who replied that they were not prepared to test the app as they were Sony Ericsson only. When the device I had tested on was Nokia. So I tried another company, who weren’t very responsive. In the end I gave up, bought Thawte and Verisign certificates and submitted to Sony and Nokia directly. They tested it very well, and highlighted issues with certificates on certain devices, memory issues on others, which helped me fine tune the range of handsets I could support. The latter is the toughest. I subscribed to deviceanywhere to gain access to many handsets, this was expensive, and the handsets on offer did not really cover all the handset categories Nokia and Sony Ericsson have in their submission process.