Software is changing the world; QCon aims to empower software development by facilitating the spread of knowledge and innovation in the enterprise software development community; to achieve this, QCon is organized as a practitioner-driven conference designed for people influencing innovation in their teams: team leads, architects, project managers, engineering directors.
Yes, sure. I am Andrea Giammarchi, I am a software engineer with Nokia, working mainly in mobile HTML development, right now we are focusing on mobile HTML5 maps applications, API and UI framework component.
Both support and performance because when you try for example to accelerate some layer, on some devices you have completely unexpected behaviors. So you have to be careful, at some point we were thinking we should just drop transitions for this kind of devices because there is no way we can control them, it was completely wild and unpredictable. This is something we fixed right now but we are still thinking how to really bring the same look and feel all over the place, also other browsers, not just the one we are supporting.
I’m not sure, I think CSS3 is good, but I think CSS is taking a weird direction because it’s not in charge of the view, the presentation anymore. There are few new things, like this calc or function invoke, so it’s starting to become what was CSS expression in Internet Explorer a while ago. I thought that was cool, but everybody said don’t use them because they slow down the rendering and you cannot possibly know when these are invoked. I’m not sure if that is true because I’m pretty sure those are invoked every time there was a repaint or reload of the page. So, it’s good to have native power behind CSS3, it’s not that good if you cannot control this power, so still I do not see any facility to understand really what is going on, to be notified about some property or to rely on some behavior. With CSS3 we sometimes had transitions that were supposed to act but never happened or events, web kit transitions, that on some devices it wasn’t fine at all. And sometimes it was. And to make this happen you have to touch the screen at least once, which is kind of weird, it’s about visual stuff, what has the touch to do? So these are the main problems we faced, we keep facing all this time, but we found a few things that are consistent and those are things that we stick with right now, because we do not want to put too much, but we are also investigating about some 3D transition, which look really cool, but they are not widely supported, but let’s see what we can do.
We are using emulators but we know emulators are not that good, so emulators are ok, just the fact that you are using the mouse for the emulator that is already something different. You can simulate in some emulators even multi touch and stuff like this, but in some emulator you cannot and also I think the GPS was sometimes unreliable, so there are a few things that on emulator do not run very well or it looks ok and then on the real device it’s just different, it’s just not working or something is just different, tiny, winy differences that compromise our release. In the team, somebody for example is using Chrome, somebody is using Safari, I personally use WebKit Nightly, I use WebKit Nightly because WebKit is behind all the browsers that we are supporting and I would like to know in advance if something will break at some point, so if they introduce some new feature, I know it’s not the most stable thing, but if they introduce some new feature or something that breaks our logic, our code or even CSS, that’s for me a way to know in advance "Ok, guys, we need to change, to refactor here because this won’t work in the next update for Android or something, or a browser". So the very first test is there because we have all these tools in the browser that we cannot really do anything without those tools. They are essential to monitor, also to profile performance also to check to have the DOM under control or see what’s going on. So the very last step is to deploy to the device and give it a spin. We do, let’s say, continuous integration and we branch every little feature that we would like to release and we test this feature in isolation. So branch per branch and see if everything is fine, then we usually merge with the rest to see that nobody broke somebody else’s code. At that point we have unit test, acceptance test, integration test, functional test, any sort of test, we do all of them, it takes quite a while, but it pays back, because as soon as something is broken we will know and we can quickly fix. So far it has been good, we have been quite fast to bring new features.
9. You mentioned WebKit Nightly as your environment of choice for browsing and probably the developer tools it has, what other tools or libraries do you find exceptionally important in your work and valuable?