Tag Archives: android

adobe, development, flash, mobile, professional, software development

Hands On with Adobe Flash Builder 4.5 for Android

2 Comments

I have been trying several cross-platform development tools for mobile, and today I set out to create an Adobe AIR app for Android using the new Flash Builder 4.5, available separately or as part of the Creative Suite CS5.5.

I made another calculator app, which may seem boring but gives me a chance to compare like with like.

You get started by running up Flash Builder and creating a new Flex Mobile Project.

image

The disappointment here is that only Android is supported, so it is not all that cross-platform. According to Adobe’s Andrew Shorten:

An update to Flash Builder, scheduled for June 2011, will provide additional options to package Flex applications for Apple iOS and will include built-in support for packaging both Flex and ActionScript applications for BlackBerry Tablet OS.

so we have not got long to wait.

Flash Builder is based on Eclipse. The IDE is slow at times, for example when switching to visual design mode, but the platform is familiar to many developers and it feels reassuringly enterprise-ready. I find it a productive environment.

I laid out a screen with buttons and a label to display the output. The alignment tools work well although I made them a little too small as you will see shortly. Then I started writing code. The language of Flash Builder is ActionScript, which is based on JavaScript.

Here I met my first little annoyance. You can easily create a click handler for a button by right-clicking in the designer and choosing Generate Click Handler, or by clicking Generate Event Handler in the properties window. However, I thought it would be smart for most of my buttons to share the same event handler. All I need to do is to read the label of the button which was clicked, and pass it to my addnum routine that processes the input:

protected function btn_clickHandler(event:MouseEvent):void
{
    var theButton:Button = Button(event.currentTarget);
    addnum(theButton.label);
}

This works fine, but the IDE does not let you select an existing event handler for a button. You can paste it in, or add in in the source code editor, which is what I ended up doing. The source code editor is rather good, with excellent code completion, hover-over help for keywords, and so on.

image

The second annoyance was with the label. I wanted to add a border. I selected the label but could not see a border property. I went to the full list of properties and found exotic things like dominantBaseline in the style list but still no border.

Then I found this in the reference for a label:

Borders are not supported. If you need a border, or a more complicated background, use a separate graphic element, such as a Rect, behind the Label.

I wondered if a panel would work, and started to type it in the editor:

image

Well, it looks as if Panel is overkill for simply getting a border, but it was interesting to see the editor report that “Adobe discourages using Panel when targeting profiles: mobileDevice”. I decided to do without a border for the moment.

I finished the coding and successfully ran the project in the Android simulator. Next, I attached a device and created a new Run Configuration for a device attached via USB. I plugged in my HTC Desire running Android 2.2. Provided USB debugging is enabled on the device, this works well. Not only could I run on the device; I could also set a breakpoint and debug on the device. Everything was a bit slow in debug mode but it worked.

image

Finally, I built a release version using Export Release Build on the Project menu. You have to sign the package, but there is a wizard to create a certificate for testing.

Here it is on the device – as I mentioned, the size of the buttons needs a little work:

image

So how is performance, bearing in mind that the app is trivial. Well, the good news is that performance is OK, though launch is a little slow, except for one thing that I have not figured out. Sometimes I touch a button, and see the graphic effect as the button depresses, but the input does not register. It seems most prone to this just after launching, and usually a second tap works fine.

The vsize reported for the app process by the Dalvik Debug Monitor is around 200K, similar to that for the PhoneGap version.

Overall I am impressed, though I would like to understand the button issue, and I am beginning to wonder if my year-old HTC Desire is a bit under-powered for AIR. Device performance is improving rapidly, and Flash optimization is part of the design process for mobile graphics chips, so my guess is that AIR will be more than viable as a cross-platform toolkit for mobile. You also get the benefit of all those lovely Adobe design tools.

apple, gadgets

Google seeks to automate the home

Google made a bunch of announcements at its Google I/O keynote today. It showed off the next version of Android, called “Ice Cream Sandwich”; it announced its Music Beta, a service which looks a lot like Amazon’s Cloud Player, in which you upload your music collection to the cloud; it announced movie rentals.

The most intriguing announcements though were about how Android devices will be able to connect to other devices in future. The Open Accessory API lets manufacturers create devices which talk to Android over USB, and in future over Bluetooth, in a standard manner. The idea is that if you have an Android-compatible device – Google demoed an exercise bike – you can attach your smartphone and do some clever stuff, such as controlling it, analysing its data, or whatever is appropriate.

A related idea is called Android@Home. Google has developed a new lightweight wireless protocol which will let manufacturers create household devices that can communicate with Android:

We previewed an initiative called Android@Home, which allows Android apps to discover, connect and communicate with appliances and devices in your home.

image

The automated home is a grand concept where almost any device, from a light to a coffee maker to a fridge or a door becomes available to control and program. However, the examples Google gave were not exciting: playing a CD by waving it at a player, coding an alarm clock to turn the light on gradually. Big deal.

It is not really a new concept. Sun had ideas to develop Java as a universal runtime and language to automate the home. Microsoft has similar thoughts, maybe using the .NET Micro Framework. So far none of these efforts have come to much – will Google’s initiative be different?

Probably not; but there is something else going on here. I travel a bit, and it is now common to find an iPod dock in your hotel room. If you have an Ipod or iPhone you just plug in and go; if you have a non-Apple device, you are out of luck. That is a kind of pressure exerted on every guest, a hint that they might be better off with an Apple device.

Google wants to do the same for a variety of other devices, but with respect to Android. Here is a refrigerator, and by the way, if you have an Android device you can do this other clever stuff like, I don’t know, alerting you if the temperature goes too high, or letting you peek at the contents from your smartphone so you can see if you need to buy milk.

Same with the Open Accessory API. If Google can sign up enough manufacturers, it will be increasingly difficult for non-Android devices to compete.

That said, we did not hear much about Google TV at today’s keynote. Why? Because it has flopped; a reminder that not all Google’s efforts succeed.

development, mobile, professional, software development, web authoring

Mobile developers follow the users; PhoneGap most popular cross-platform toolkit says survey

2 Comments

Web Directions has published a State of Mobile Web Development based on input from around 1300 professional web developers. Note that this is a survey of web developers not app developers, which must skew the results if you are interested in the overall app picture, but it is still interesting.

One result deals with developer platform decisions. What are the factors that count when choosing a platform to develop for? New and minority mobile platform players will study this with interest, since getting a large number of developers on board is a high priority.

Here is the ranking of factors based on how many developers consider each one “Very important”:

  1. Number of potential users of your app: 68.55%
  2. Platform capabilities: 60.36%
  3. Ease of development: 58.55%
  4. Worldwide reach of marketplace: 40.02%
  5. Assistance in marketing your app: 23.40%

The message for the likes of Microsoft, HP and RIM is that the best way to attract developers is to sell lots of cool devices. Ease of development matters, but not as much as a large market.

Another section asks which toolkits are preferred if you are developing native apps with web technologies (note the exact question):

  1. PhoneGap 47.6%
  2. Appcelerator 26.5%
  3. Other 15.6%
  4. Adobe AIR 7.8%
  5. Apparatio 1.2%
  6. Rhomobile 1.2%

The sample here is rather small, with only 79 of the 1300 using PhoneGap, for example. I also quibble with the definitions here. Rhomobile’s Rhodes framework compiles Ruby to native code and I doubt it counts in the category “developing native apps with web technologies”. I am even sure whether AIR belongs alongside PhoneGap and Appcelerator, since AIR is Flash whereas the other two are HTML 5. Incidentally, Appcelerator is the company name and what should appear here is Titanium, which is the name of the cross-platform toolkit. Apparat.io is in private beta so its low take-up is not surprising.

Still, it is a good result for the top two. If you are interested in these toolkits don’t miss my recent interviews with André Charland at Nitobi (PhoneGap) and Jeff Haynie at Appcelerator.

adobe, development, javascript, professional, software development, web authoring

Dreamweaver CS5.5 PhoneGap apps: performance issues on Android

1 Comment

This is a follow-on from my earlier post about building a simple PhoneGap app using Adobe Dreamweaver CS5.5. I built it on Windows targeting Android. I liked the development experience up to the point of trying the app: it looks great, but performance is terrible. That is, you tap a button and there is a perceptible pause before the app responds. It is worse in the emulator than on my HTC Desire, but still poor.

I had thought it was a configuration setting – though Dreamweaver makes it rather hard to access the build settings – but I am now wondering if jQuery mobile plus PhoneGap is just too demanding for most Android devices out there right now. Admittedly my Desire is a year or so old now. See this thread for example:

JQuery Mobile on Android is definitely slow. (Tested A2 and A3Pre on Samsung Galaxy S, HTC Desire, ZTE Blade (edit: 2.2 Froyo) – with PhoneGap, stock browser, Opera Mobile)

Something has to be done. The experience is low quality.

It is worth noting that PhoneGap is not yet a version 1.0 release – I was told it may be done by July. Further, you do not have to use jQuery Mobile with it in Dreamweaver; it just happens to provide a great set of user interface widgets. It may be better on Apple iOS; I have not tried that yet.

Nevertheless, this looks like a significant issue if you planning to dive in and deliver Android apps using the tools in the new Dreamweaver.

adobe, professional, software development

Hands on: Building a PhoneGap app with Dreamweaver CS 5.5

25 Comments

One interesting feature in the new Adobe Creative Suite 5.5 is that PhoneGap is integrated into Dreamweaver. What this means is that you can build a mobile app for Google Android or Apple iOS from within Dreamweaver.

I have just installed the new suite, so decided to give it a try. My project: to create a working calculator app and install it on an HTC Desire (Android 2.2).

I started by creating a new document based on the PhoneGap Mobile Starter.

image

Next, I created a new site with the name “Calc”, in a folder called Calc.

I saved the page as index.html. When I did so, Dreamweaver prompted me to copy a bunch of JQuery Mobile stuff into the folder.

Then I selected “Configure Application Framework…” from the Mobile Applications option on the Site menu.

image

This menu is pretty much all you get for PhoneGap support. The Configure option lets you select the Android SDK or install it. Mine was already installed.

image

If you want to build for iOS, you need to run Dreamweaver on a Mac, though I guess you could code on Windows and build on the Mac using PhoneGap in the normal way.

The next step was to write the application. I mostly used the code view. DreamWeaver has a handy Insert panel which you set to jQuery Mobile. Drag controls from here into your code or design view.

image

Beware: the design view is a bit hopeless for jQuery Mobile apps, unless you have Live view switched on. Here they are side by side:

image

I built probably the world’s worst calculator. Assembling the user interface was easy though. I used a jQuery Mobile Layout Grid for the buttons. I wrote some quick JavaScript with no error handling whatsoever. I used Firefox and its error console for simple debugging.

When I was done, I selected “Application Settings…” from the Mobile Applications menu. Here you can set a few properties including the version and the icon.

image

Build and Emulate from the Mobile Applications menu.

image

This installed the app in the Android emulator. I could run it successfully, though it was mighty slow. You click a button, then after a noticeable pause the app updates to show the value you clicked. However, my app worked.

image

Next, I attached my Desire phone, and copied across the calc-debug-apk package which had been built. I detached the phone and tapped the app. Again success – but the app, while faster than the emulator, is still slow.

image

That is possibly because it is a debug build. But how do you specify a release build? I cannot find a setting for it in Dreamweaver, which seems a striking omission. I am hoping it is possible to tweak the PhoneGap build properties in the generated source, but it looks like I will need to consult the PhoneGap documentation for this.

On the one hand I am impressed. The UI looks nice considering how little time I spent on it, thanks to jQuery mobile. Further, the application works, and I was able to build it entirely in Dreamweaver. The code completion in Dreamweaver’s editor is decent.

On the other hand, documentation is terrible. This article is almost all I can find – beware the dud link to abobe.com:

image

I am not complaining about the PhoneGap docs or the jQuery Mobile docs, but the Adobe docs for using this in Dreamweaver. I hope that more will come.

Update: I spent some more time on this trying to fix the performance issues. The fact of being a debug build should not affect performance as far as I can tell; it merely signs the app with a debug key. I moved the project to the standard Eclipse tools and built it there in case Dreamweaver was messing up the build in some way, but performance is just as bad. More research throws up threads like this one:

I’ve been using Phonegap & JQM on a real device and it is also very slow (HTC Hero, upgraded to 2.1), but it flies on an ipod touch 4th gen. I guess the HTC is just getting old but I’d like to try it on a more modern device.

My initial conclusion then is that a jQuery Mobile/PhoneGap app on an HTC Desire running Android 2.2 will never perform well. It sounds like it might be OK on iOS; I guess I should try that next.

See also my interview with Nitobi president André Charland about PhoneGap.

apple, google, microsoft, mobile, nokia, professional, software development, sony

Developers and mobile platforms: lies, damn lies and surveys

I’ve been reading the IDC/Appcelerator developer survey about their attitudes to mobile platforms. The survey covered 2,760 Appcelerator Titanium developers between April 11-13, so it is certainly current and with a sample just about big enough to be interesting.

The survey asks developers if they are “very interested” in developing for specific platforms, with the following results, and with comparisons to 3 months ago:

  • 91% iPhone (fractionally down)
  • 86% iPad (fractionally down)
  • 85% Android phones (down from 87%)
  • 71% Android tablets (down from 74%)
  • 29% Windows Phone 7 (down from 36%)
  • 27% Blackberry phones (down from 38%)

The survey is titled:

Apple shines, Google slows, and Microsoft edges RIM in battle for mobile developer mindshare.

Is that a fair summary? It is not what I would highlight. I cannot read the exact figures from the chunky graphic, but it is clear that the iOS figures are also fractionally down, maybe by just 1%, but hardly much different from the Android figures on a sample of this size. Both are pretty much flat.

The figures for Windows Phone 7 and Blackberry are more dramatic; though we should at least note that Appcelerator Titanium is a cross-platform toolkit that does not currently support Windows Phone 7, and that its support for Blackberry is only in preview. That was true last time round as well, but I’m not sure that asking developers about their plans for a platform which the toolkit does not currently support is the best way to gauge overall interest.

Another question that interests me: is developer interest a cause or an effect of a mobile platform’s success? A bit of each, no doubt; but personally I think the “effect” model is stronger than the “cause” model. Developers pick a platform either because they have immediate customers for apps on that platform, or because they think they can make money from it.

Nurturing a strong developer community is definitely important for a platform provider; but I doubt it ranks as highly as other factors, like building a strong retail presence, delivering excellent devices at the right price, and focusing on usability and a good end-user experience.

If you are interested in Appcelerator Titanium you might like to read my interview with the CEO at Mobile World Congress; and this discussion on whether Titanium really builds native apps.

microsoft, mobile, professional, software development, web authoring

Is Appcelerator Titanium native? And what does native mean anyway?

7 Comments

Of course we all know that Microsoft’s IE9 and the forthcoming IE10 are native – VP Dean Hachamovitch said so many times during his keynote at the Mix 2011 conference earlier this week. That has sparked a debate about what native means – so here is another interesting case.

Appcelerator’s Titanium cross-platform tool for mobile development is native, or at least that is what it claims:

image

Now, I am not sure that native has a precise definition, but to me it suggests a compiled application, rather than one interpreted at runtime. So this description of how Titanium executes JavaScript – its main language – is surprising:

In a Titanium Mobile application, your source code is packaged into a binary file and then interpreted at runtime by a JavaScript engine bundled in by the Titanium build process. In this guide, you will learn more about the JavaScript runtime environment that your code runs in. Titanium runs your application’s JavaScript using one of two JavaScript interpreters – JavaScriptCore on iOS (the interpreter used by Webkit) and Mozilla Rhino on Android and BlackBerry.

So a Titanium application is actually interpreted.

Native is a vague enough term that Appcelerator can no doubt justify its use here. “Native UI” is fair enough, so is “Native capabilities.” Native performance? That seems to me a stretch, though JavaScript performance is good and constantly improving. Appcelerator even has a web page devoted to what it means by native.

Titanium is also open source. Anyone doubtful about how it works need only consult the code.

In the light of Microsoft’s statements, it is interesting that what Appcelerator really means by native is “not a web page”:

Build Native Apps … Everything else is basically a web page.

So can an application be both native and interpreted? What about Silverlight apps on Windows Phone 7, are they native? Adobe AIR apps, surely they are not native? Google Android has a Native Development Kit which is introduced thus:

The Android NDK is a companion tool to the Android SDK that lets you build performance-critical portions of your apps in native code.

The implication is that byte code executed by the Dalvik virtual machine, which is the normal route for an Android app, is in some sense not native code. Which also implies that Appcelerator’s claims for Titanium are at least open to misunderstanding.

adobe, java, professional, software development

RIM announces Java and Android runtimes for the Playbook, beta of native SDK

RIM has announced several new options for developing apps for its PlayBook tablet.

RIM will launch two optional “app players” that provide an application run-time environment for BlackBerry Java® apps and Android v2.3 apps. These new app players will allow users to download BlackBerry Java apps and Android apps from BlackBerry App World and run them on their BlackBerry PlayBook.

In addition, RIM will shortly release the native SDK for the BlackBerry PlayBook enabling C/C++ application development on the BlackBerry® Tablet OS. For game-specific developers, RIM is also announcing that it has gained support from two leading game development tooling companies, allowing developers to use the cross-platform game engines from Ideaworks Labs and Unity Technologies to bring their games to the BlackBerry PlayBook.

It sounds as if the Android runtime will not be perfectly compatible with real Android:

Developers currently building for the BlackBerry or Android platforms will be able to quickly and easily port their apps to run on the BlackBerry Tablet OS thanks to a high degree of API compatibility.

Nevertheless, this will be an attractive route for Android developers looking for a quick way to port to the Blackberry.

The native SDK is currently in “limited alpha release” but RIM is promising an open beta for this summer.

The BlackBerry Tablet OS NDK will allow developers to build high-performance, multi-threaded, native C/C++ applications with industry standard GNU toolchains. Developers can create advanced 2D and 3D applications and special effects by leveraging programmable shaders available in hardware-accelerated OpenGL ES 2.0.

The deal with Unity is important too. Unity is an increasingly popular toolkit for game development and adding the Blackberry to the list of supported platforms will boost its appeal. Ideaworks Labs makes the Airplay SDK, a cross-platform toolkit which already supports Apple iOS, Android, Symbian, Samsung Bada, HP webOS and Windows Mobile.

Note that the primary SDK for the Playbook has until now been Adobe AIR; and since the UI itself uses the Flash runtime this likely still makes sense for many applications.

RIM is doing a good job of opening up its platform. It is an interesting contrast to Microsoft’s “Silverlight, XNA or nothing” approach for Windows Phone.

google, internet, javascript, professional

Google on innovation – or should that be copying?

7 Comments

Patrick Copeland, Google Director of Engineering, gave the keynote at QCon London this morning. His theme was innovation: how it works at Google and elsewhere.

I was expecting some background on Google’s famous 20% time, where employees spent up to one day a week on something not in their job description, but I don’t think Copeland even mentioned it. In fact, he almost argued against it. There is no shortage of bright ideas, he said, and Google has over 100,000 of them in a database; but what matters is not idea, but innovators who have the ability to take a good idea and make it into a product.

He added that whatever “it” may be, building the right “it” is more important than building “it” right. If what you build is the wrong thing, it will not succeed, whereas the right idea will sometimes succeed despite poor implementation. Twitter and its well-known fail whale comes to mind.

Google’s record on innovation is mixed. You can make a long list of Google projects that have failed, from Lively – a kind of Second Life clone – to Google Wave. “You want to fast fail when things aren’t working” said Copeland, making the best of it.

On the other hand, Copeland mentioned GMail as a positive example. I would quibble a bit with this: was GMail innovation, or simply Hotmail done right?

Copeland also mentioned two other examples. The Chrome browser, he said, had two goals: to streamline the user interface so less screen space was wasted, and to have a fast JavaScript engine to show off Google apps. He also observed that rival browsers have copied both ideas; and it is true that Microsoft’s Internet Explorer 9, which will be released on March 14, happens to have both these features.

What about Android? Copeland said that the Android strategy vs Apple is similar to that of the clone PCs vs IBM in the eighties. He tried to make a point of innovation here, observing that IBM could not compete with innovation from many independent vendors, but this seems to me a stretch. The point about the clone PCs was that they were kind-of the same as the IBM PC but cheaper and faster. It was more about copying than about innovating. I think you can see this playing out with Apple vs Android to some extent, in that there are customers who will end up with an Android smartphone or tablet because it is kind-of the same as an iPhone or iPad but cheaper or with better specifications.

On the other hand, Apple is doing a better job at differentiation than IBM achieved with its PC; and technically iPhone apps do not run on Android so the parallel is far from exact. Many of the same apps are available for both iPhone and Android, so from user’s perspective there is some similarity.

The quick summary then: most innovations fail, and you need innovators rather than simply bright idea. The implication is that successful innovation happens when you have a company with lots of money to spend on projects that will likely fail, and that has a culture which attracts innovators. Google ticks both boxes.

Incidentally, when I asked how Google identifies its innovators Copeland said that you do not need to. They make a nuisance of themselves, so if you have them, you know.

apple, google, mobile

Google fails to protect its mobile platform

The discovery of viruses in apps on Google’s Android Market is troubling. I like the fact that Android is open, and that you can easily install an APK (Android Package) from any source onto your device if you want to. That said, it is reasonable to expect that apps downloaded from the official Android Market will be virus-free, or at least that some attempt has been made to check them for malware.

Another problem which is apparently rampant in the Android market – and also to some extent in Apple’s app store – is app stealing, where someone takes an existing app, copies and re-uploads on their own account. In most cases it seems that the malware was on apps pirated in this manner.

Note that while it took Google less than five minutes to pull the malicious apps from the store, the original developer had apparently been trying for more than a week to get them pulled on copyright violation grounds.

Google takes 30% transaction fee for apps sold in the market. Enough, you would think, to check for malware.

Most seriously for the Android market, the situation for users is that apps on Android Market might be malware, whereas apps on Apple’s App Store are not. That is a big advantage for Apple, and one that you would have thought Google would want to counter.

The only winners here are the anti-virus companies, who will be delighted to inflict their subscriptions on mobile users just as they have on Windows desktops.