I live on at the top of the Big Hills in Ottawa (sort of SanFranSkatchewan height). It is a David Suzuki-approved pleasure to throw the 6speed in neutral and coasting down at a leisurely 40km/h , saving the world by getting 1.5L/100km mileage for at least a few hundred metres. That was until speedbumps were installed last week, changing the whole sweet situation.
Flash platform is like that hill – it can be efficient and fun when there are no speedbumps, and most of those are our own fault. Fortunately, optimization of your code can go a long, long way to speeding things up, and after reading Adobe’s latest revision of the Guide (PDF), you may feel a bit dirty knowing parts of your code could run 25-50% faster. The examples contain timer data, so you know just how much performance is enhanced. It’s a 15 minute read and well worth it, especially now that mobile apps set the baseline back to 1998 processor power again, and FlashPlayer 10.1 has some new tricks to take advantage of.
Still looking for more tips? Grant Skinner (Go, Edmonton!) has an excellent presentation here (Flash).A theme of his which I like (as does your mobile device) is being a Good System Citizen – be courteous, don’t hog, clean up after yourself and all those good common sense behaviours.
The scare this year has been that you, as a developer, would have to choose a platform and focus on it. Noone minds a bit of focus, but the fact that seemingly artificial barriers to re-use of code and effort were being introduced; the mobile platforms were making it necessary to choose a side, because learning all the platforms was a big reach. Blackberry, Android, iOS, Flash Platform, each with its own SDKs, IDEs, frameworks, and of course, time destroying tricks and gothas. But things are looking a little brighter: Continue reading →
Insightful article by David Green, who developed the same app in both Android and iOS and shares his experiences and contrast the two methods from a developer’s perspective. Great read, but read the comments section to for some good counterpoints.
The Nexus 1 from Google is one of the few mobile devices with a stock build of Android.
It is the exception to an unfortunate rule where manufacturers are skinning Android with their own UI components at the expense of users.
Most of these interfaces are a personal matter of choice whether the user likes them or finds that they actually increase the usability or utility of their handset.
One thing that is not arguable however is that the Manufacturers who choose to do this are effectively becoming gatekeepers for Android updates to these Users. Need to Update to Androis 2.2? You will have to wait until you manufacturer has updated their skin and chosen to push the update to the User’s phone. The time for this is not exactly days and can be months, or never.
This differentiates mobile from desktop and notebook, where manufacturers could add some bloatware to Windows, but it could be removed and essentially made stock. This option is not available in the Android situation, unfortunately.
Manufacturers ideally should either make the turnaround times for updating phones much tighter (the update delay from from Android 2.1 to 2.2 is infuriating), or make their skin not stand in the way of defaulting to a stock install, or for that matter a whole market of 3rd party skins. If the User chooses to keep it, great, then the Manufacturer has actually made a piece of software front-end that enhances the stock UI. From recent reports this is often not the case, but because bypassing the custom UI is either prohibited or difficult, the Manufacturers are simply letting Google do the heavy lifting while they simply stand in the way of what android does best – promote rapid innovation.
Competition through exclusion of alternatives has never benefited customers.