Building iPhone and Android apps with HTML/CSS/JS

Wednesday, December 2nd, 2009

Just a few days ago we had a chance to look at Appcelerator platform and its  Titanium family of products.
We looked primarily at Titanium Mobile, as both Android and iPhone  are of a significant interest for us – we do lots of development for these platforms.

So we’ve played quite a bit with Titanium Mobile and here’s quick summary of our opinions:

Pros:
• Same code that works on iPhone and Android platforms. As Android market gets traction, the option to “kill two birds” with one code-base looks like really cool.
• Enough to know html/CSS/js to develop. This is important. Especially for iPhone. While we regard Android Java SDK as a very good development platform and our J2EE engineers just love coding for Android (although they quite shun from J2ME)  iPhone Objective C is pretty different story. It is difficult to learn, it is bug-prone. It has quite weird callback logic. In fact, it is literally impossible to train Java or Ruby or Python engineer into iPhone engineer. Titanium Mobile opens iPhone apps world to even more light-weight technologies, and this is just great.
• Easy to install and to use.
• Free and open source.

Cons:
• Optimality of generated native code and native SDK coverage is questionable. Our experience shows that all such translator solutions (and another example is Adobe’s Action Script – 2 Objective C builder) do not cover complete set of native SDK functions. Honestly speaking we did not run into such situation with Titanium Mobile, but our gut feel is that there should be some limitations.
• Ability to quikly support new SDK releases. Apple’n'Google naturally are enhancing their SDKs all the time. Ability of appcelerator to quickly follow these changes is questionable.

That said, here’s our current view on how Cogniance may use Titanium Mobile: it is definitely useful when quick’n'dirty prototyping should be done or when app functionality is pretty straightforward and simple. But, if the task is to create state-of-the-art app which utilizes many advanced SDK features we will probably not risk to go with Titanium Mobile and go straight to native layer.  Yet, we appreciate that Cogniance is not exactly target consumer for Titanium Mobile, as we’ve already got both iPhone and Android engineers and Mobile targets web developers w/o native layers knowledge.

Written by:  Sergii Gorpynich

Posted in Mobile technologies, Uncategorized, Web 2.0 technologies | 2 Comments »

Mobile Applications Testing (Part 2)

Tuesday, August 11th, 2009

No surprise that testing of mobile applications is a much more painful task than testing the Web ones. Mobile phones can differ from one another dramatically, and this will radically change the way people see and use mobile applications and websites. There are a lot of different cases and dependencies that need to be considered for every single mobile device. I’ll point out several of them to cast some light on the problem scale.

First of all, it’s all about the application type – it can be native, cross-device, sms-powered, and a web application. Then, we need to consider carrier, handset manufacturer, model, OS and a browser. All these can give us the information about screen size (small vs. large), screen layout (portrait vs. landscape), input device (numeric keypad, QWERTY keypad, touch-screen), etc.

Here, at Cogniance, we experience each type of mobile applications testing, but the most exciting and bright experience was with Native applications development/testing. The application under test was Brew Mobile Client connected to the social network. It was developed for a predefined range of devices under Verizon Wireless carrier. I’m not going to describe the whole testing process and methodology, but the main bottlenecks were numerous certifications, signature files, application testing under a real network, using DeviceAnywhere Studio to cover required set of devices, and a lot of other extremely expensive procedures.

I would suggest moving towards the mobile Web applications. Think about it: If you’re creating a website, you don’t have to get permission from a carrier. You don’t have to get something certified by anyone. You don’t have to beg for being placed on the deck, and you don’t have to pay half your revenue to a reseller. In fact, the carriers, handset and OS vendors probably won’t even be aware of your existence. It will just be you and the user, communicating directly.

“The business of making native apps for mobile devices is dying, crushed by a fragmented market and restrictive business practices. The problems are so bad that the mobile web, despite its many technical drawbacks, is now a better way to deliver new functionality to mobiles. I think this will drive a rapid rise in mobile web development, largely replacing the mobile app business. This has huge implications for mobile operators, handset companies, developers, and users.” Michael Mace, a product planning and marketing executive in Silicon Valley.

Written by Alexey Koval

Tags: mobile testing, Quality Assurance
Posted in Mobile technologies, Quality Assurance and testing | 6 Comments »

Mobile applications testing (Part 1)

Thursday, June 11th, 2009

Under the current subject there will be series of posts prepared by Cogniance experts involved into mobile applications testing and end-to-end scenarios verification process.

First one is mostly about iPhone applications because at this moment it is the hottest trend in mobile development and testing.

iPhone applications testing

Cogniance has been a trusted end-to-end software contractor and technology services partner in Mobile and Web 2.0 space since 2006. As an expertise consultant and QA team crew member at Cogniance, I’ve seen how mobile projects are getting progress and complex as more and more mobile applications that are new arise on mobile phones day by day. Three years ago, projects for mobile platform had very low ratio with web in about 1 to 6. Today it changes for 1:2 and even more frequently the target platform for mobile testing is iPhone OS. I will focus on such projects here.

First of all iPhone OS has strong support as integrated development environment, simulator, special tools suite like performance instruments, interface builder, etc. But the main basis of popularity projects for iPhone OS is Apple’s App Store, precisely this are few clicks effort from user to get wanted application directly to iPhone.

Apple’s App Store does not have any test services like dedicated QA (staging) servers or some closed App Store for developers to testing purpose. So to perform full test cycle for iPhone’s projects, especially to test application installation directly to iPhone device we use Mobile Provision Profiles approach to add application under test into iTunes and then synchronize with iPhone. It’s not official and legal way to add applications into iPhone, but it is one as simple and effortless approach.

How are you currently testing your iPhone’s application? How are you making sure correct installation through Apple’s App Store before release? I’d love to hear about your projects or thoughts on this post.

Written by: Anton Derkach – Senior Software Tester/QA Engineer at Cogniance

Tags: iPhone applications testing
Posted in Cogniance life, Mobile technologies, Quality Assurance and testing | 1 Comment »

J2ME vs. Symbian C++. Which one to choose from?

Wednesday, June 10th, 2009

Our experience with development for Symbian-based phones shows that very strong trend of last years is to base apps for this system not on native Symbian C++-based SDKs, but on J2ME/MIDP2 because of the next reasons:

1. Development in J2ME is significantly faster (in our estimations up to twice as fast) than development in native Symbian C++.
2. J2ME developers are generally more available than C++ Symbian programmers – you can implement same functionality with regular Java Mobile engineer, but only with senior Symbian engineer
3. C++ code is not even close as portable as Java is. Not just your Symbian C++ code will run only in Symbian phone, but you will also have to target several different versions of platforms with different code base(Series 60 0.9, 1.2, 2.1, 2.6, 2.8, 3.0, Series 80). J2ME is much more portable, even although total port cost is somewhat above zero. After you’ve got Java version for (let’s say S60) – you comparatively easy port this version to Samsung, Sony-Ericcson and other mobile platforms.
It does NOT impact.
4. Java virtual engine for Symbian phones, (which hosts j2me apps) supports majority of phone extentions – such as LBS, camera, motion and sound functions. These are supported starting from S60 3rd Edition platform.
5. The fact that C++ provides better speed and lower memory consumption compared to Java becomes more and more negligible for modern phones with optimized processing speed and better and better Java virtual machines.
6. The fact that C++ provides better access to native Symbian OS functions compared to Java is negligible for modern Java virtual machine versions. This perceived advantage is even more negligible as there are Symbian-specific extentions over MIDP2 on the market – one can easily plug these extentions into the app as required.
7. And the last but not the least… – Symbian J2ME apps can be published to Nokia OVI store, same as native Symbian C++ apps.

In summary, general suggestion which we’ve researched at our engineering team is to target Symbian powered phones not with native Symbian apsp, but with J2ME based ones.

Posted in Mobile technologies | 10 Comments »