Category Archives: adobe

adobe, development, facebook, flash, microsoft, mobile, nokia, professional, software development, windows

Windows Phone “Mango” shown, looks good but still no Adobe Flash

4 Comments

I attended the London press briefing for Windows Phone “Mango”, also known as Windows Phone 7.1. This will be on new phones in the Autumn, and will be a free update for all existing Windows Phone 7 devices.

image

Microsoft showed a bunch of new features, including Internet Explorer 9 – which, we were told, is built from the same code as the PC version – improved social media integration now including Twitter and LinkedIn as well as Facebook, Hotmail, Exchange, Messenger and Gmail; and multi-tasking support.

Hold down the back key for a moment, and all running apps appear in a tiled view. Just tap the one you want.

We also saw text-to-voice and voice-to-text demos. The presented spoke the reply to a text message, though admittedly he chose to do a one-word reply, and sent it successfully.

Microsoft also announced three new OEM partners, Acer Inc., Fujitsu Ltd. and ZTE Corp.

It looks good; but I did have a sense that Microsoft is ducking the hard questions. One of those concerns Adobe Flash support. At a separate developer briefing, I asked developer relations guy Brandon Watson about Adobe Flash support, observing that when Windows Phone was shown in detail pre-launch at the Mix 2009 conference in Las Vegas, it was clearly stated that Flash would be on the phone, and that Adobe was being allowed to build the Flash runtime in native code, but that it would not be included at launch.

“It does not run on the phone”, said Watson. Then he added, “It does not run on the phone.” Finally, he said, “It does not run on the phone.”

Silverlight does not run in the mobile browser either, so perhaps the problem is with mobile IE – clearly not all the code is included. Or maybe Adobe is hanging back; I asked Adobe about this at Mobile World Congress earlier this year and got an answer that was warmer but no more informative. Or maybe Microsoft is thinking, Apple does not need it, so we do not need it either.

It is a shame though, because there is a perception that Flash is one of the advantages of not going the Apple route.

On the developer side, the beta tools for Mango were released today. You can target either Windows Phone 7.0 or 7.1 with the tools, so if the beta tag does not put you off you can get going straight away. There is a ton of good stuff for developers, including the SQL Server CE local database, and the ability to mix XNA and Silverlight in a single app. We saw an app from British Airways that makes use of this to show a 3D view of an aircraft cabin when choosing a seat; I am not sure how much real value this adds but it demos nicely.

The new emulator includes accelerometer support, so you can simulate movement to test your app’s response.

There is also a profiler which shows your app’s performance in various views. Code that you wrote is highlighted in blue in the graphical view, so you can tell what you can optimise, as opposed to slow system calls that are outside your control.

The developer tools are great though, and having played with a number of mobile developer toolkits I would say that Microsoft’s is among the best and above average, though I would like to see an option for native code development. “We hear that a lot,” Watson told me.

The problem though: developers want a big market, and so far Windows Phone has not delivered it. It is almost invisible on the high street, and all the current operators and manufacturers have other phones that they are more concerned about. That will change when Nokia devices appear, but in an intensively competitive market (not forgetting HP WebOS and RIM Blackberry/QNX/PlayBook) it will not be easy for Microsoft to gain ground.

After the event I discussed this with some of the Microsoft folk. Maybe the company can better exploit the Xbox link, and sell the phone to that community. Maybe Nokia will save the day. Maybe when Microsoft comes out with a fully professional iteration of Windows Phone, tightly linked to Active Directory and group policy, and with additional developer features aimed at line of business apps, maybe then it will take off.

One positive thing I heard today was an anecdotal report that returns on Windows Phone 7 are among the lowest because users like the device so much.

The social features in Windows Phone are already good and will be better in Mango – though bear in mind that by the time Mango phones appear in the Autumn, Microsoft will likely have iPhone 5 and many tempting new Android devices to contend with.

Years ago it used to be said that Microsoft had average products (or worse) but excellent marketing. With Windows Phone, the product is good but either the marketing is lacking or the task is too great. Of course there is still time, and this industry is full of surprises, but it will take more than Mango to make Windows Phone fly.

adobe, cloud computing, google, mobile, professional

Chromebook: web applications put to the test, and by the way no Java

2 Comments

Yesterday Google announced the availability of the first commercial Chromebook, a Linux computer running the Chrome browser and not much else. There are machines from Acer and Samsung which are traditional laptop/netbook clamshell designs, with an Intel Atom dual core processor, 16GB solid state storage, and a 12.1” screen. Price will be a bit less than $400, or organisations can subscribe from $28 or €21 per month in which case they get full support and hardware replacement. There are wi-fi and 3G options. Nobody is going to be excited about the hardware.

image

The Chromebook may be the most secure computer available, if Google has got it right. The OS is inaccessible to the user and protected from the browser, and system patching is automatic.

The strength and weakness of the Chromebook is that is only runs web applications – the only exception being utilities that Google itself supplies. Are we ready for a computer that is little use offline? I am not sure; but this will be an interesting experiment.

The Chromebook is a compelling alternative to a traditional PC with its susceptibility to malware and dependence on locally installed applications and data. If you lose your PC, getting a new one up and running can be a considerable hassle, though large businesses have almost cracked the problem with system images and standard builds. Lose a Chromebook, and you just get another one and sign in.

You sign into Google of course, and that is a worry if you would rather not be dependent on a single corporation for your digital identity and a large chunk of your data.

The problem for the Chromebook is that Apple’s iPad and numerous Google Android tablets and netbooks offer security that is nearly as good, and local applications as well as web applications, for a not dissimilar cost. These devices are also easy to restore if they break or go missing, slightly less so than a Chromebook but not much.

The choice looks a bit like this:

  1. Chromebook: Web applications only
  2. iPad/Android: Web applications and local apps

Put like that, it is difficult to see the advantage of the Chromebook. The subscription scheme is interesting though; it is a new business computing model that brings the cloud computing principle of operating expenditure instead of capital expenditure to the desktop.

The offline issue may be the worst thing about a Chromebook. When I travel, I frequently find myself without a good internet connection. The word “offline” does not feature in either the consumer or business frequently asked questions – a question Google would rather you did not ask?

Yet there is 16GB storage on board. That is a lot. In theory, HTML 5 local storage should solve the offline problem, but few web apps, including Google’s own, make this seamless yet.

A few other observations. While there are no user-installable client apps, Google is adding some utilities.

VPN is coming:

We’ve heard from our pilot customers that VPN is an important feature for businesses and schools, and we’re working very hard to bake this into Chromebooks soon. Support for some VPN implementation is already in the product and we’ll both extend support for more VPNs and get these features to stable soon.

Remote desktop access is coming:

we are developing a free service called Chromoting that will enable Chrome notebook users to remotely access their existing PCs and Macs.

Apparently this is based on Citrix Receiver.

There is a bias towards Adobe Flash:

Chromebooks have Flash support built-in, but they do not support Java or Silverlight.

Another blow for Java on the client.

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.

adobe, development, iphone, mobile, professional, software development

Hands On with RunRev LiveCode: rapid development for iOS, Android, Mac and Windows

3 Comments

RunRev LiveCode is a cross-platform development tool for Mac, Windows, Linux, Web, Apple iOS and, from this month, Google Android.

image

It is an individualistic tool inspired by Apple’s original (but now obsolete) HyperCard and HyperTalk, in which the building blocks of your application are stacks and cards. A stack is like a window, and a card is like a panel overlaid on that window. Unlike HyperCard, LiveCode is not a virtual card stack where each card can represent a record in a database; it is simply a means of building a graphical user interface.

A key attraction of LiveCode is that it now supports the two dominant smartphone platforms. I have been looking at a number of different approaches to mobile development, most recently PhoneGap; how does LiveCode compare to the competition? In order to get some hands on experience I set out to create my simple calculator application in LiveCode.

Coming almost new to LiveCode, I found that building this application took longer than it had done in PhoneGap, which uses HTML and JavaScript. I created a new stack and dragged some buttons onto it easily enough, but found that the approach to coding took some getting used to. There are lots of tutorials, but I found the easiest way to learn was to read through chunks of the user guide [pdf], which does a better job of explaining how to code.

One annoyance is that each object, such as a button, has its own script window, which appears as a tab in the editor. Although my calculator is simple, it does have a fair number of buttons, so you end up constantly switching between tabs. If you amend some code, you have to remember to click Apply before the change takes effect. If you forget, you run the application and puzzle over why it seems to be running an old version. The environment is strongly GUI-centric; you will not like it if you are an enthusiast for Model-View-Controller architecture.

The environment is dynamic, so you can test the stack you are working on at any time simply by switching it to browse mode. This is why it is called Live Code. In this respect it is similar to the Live View in Adobe’s DreamWeaver.

image

I had to get used to writing:

put firstNumber * secondNumber into theResult

instead of

theResult = firstNumber * secondNumber

I was impressed by LiveCode’s ability to change types on the fly and to work out correctly whether you wanted to do something with a string value or a numeric value.

The language is more English-like than most languages, though I am not sure if it really easier. The language minimises use of punctuation which helps readability. Cases in switch statements fall through, C style, unless you remember to include break statements, which is traditionally a common source of bugs.

I got my calculator working on Windows. I tried building for what RunRev calls Web, but was put off by the plug-in requirement:

image 

I then moved the project to a Mac to try it on iOS. Everything still worked, but I spent some time resizing the stack and repositioning the buttons to look half-way reasonable on an iPhone. I may be missing some tricks here, but scaling and positioning controls does not seem to be a strong point for LiveCode.

LiveCode does feel that bit more at home on a Mac, reflecting its origins.

image

I was impressed with how easy it was to build the app for iOS. The way cross-platform works in LiveCode is that you open a dialog called Standalone Application Settings. There is a tab for each supported platform, in which you specify options specific to each platform. The options for iOS are extensive, including supported devices, hardware access requirements, orientation options, external libraries and so on. You can then test immediately on the simulator. For on-device testing, you use the Organizer in Xcode to copy the compiled app across.

image

The good news is that the app ran well, much better than than the PhoneGap/jQuery Mobile version, though it did not look as nice and in fairness the other app’s performance issues are likely more to do with jQuery Mobile than PhoneGap itself.

Although I found it a bit of a hassle getting started, nevertheless I was able to build a working app for Windows, Mac and iOS in a few hours, so I should not complain.

Of course there is a lot more that LiveCode can do. It has database libraries, graphical effects, an embedded web browser on some platforms, XML and text processing support, and more. It is also extensible; there is probably not much that cannot be achieved with sufficient effort.

I have not tried the Android support as my version does not include it; though I did notice that the Android options dialog is basic compared to what is available for iOS.

My first impression of LiveCode is positive, but with reservations. It looks to me like a viable and productive route to cross-platform development, or you might use it just as a quick route to app development for iOS, but I did not enjoy working in the IDE which feels quirky and unsophisticated compared to other modern IDEs. My little app works well though, and that suggests it would be worth trying it for something more advanced.

adobe, apple, iphone, professional, software development

Building a PhoneGap app for iPhone with Adobe Dreamweaver CS5.5

3 Comments

After trying out Adobe’s new Dreamweaver CS5.5 for building a PhoneGap app for Google Android, I was keen to try the same for Apple iOS. In particular, I wanted to see if the performance problems with jQuery Mobile and PhoneGap on Android were also an issue on iOS.

This turned out to be more complex than I had imagined. Bear in mind that I have not done a lot of previous iOS development; but I reckon that makes me a good test case for Adobe’s market here. Ideally you should be able to use Dreamweaver alone to build your app and make a fortune on Apple’s popular app store.

I installed Dreamweaver CS5.5 without any issues and copied my Calculator example from PC to Mac. I am not going to repeat the steps that were the same as for Android; read my earlier post. I will mention that I puzzled over the setting for the IOS Developer Tools Path. After trying various sub-directories I eventually discovered that simply entering /Developer here works. One of the issues I have with this stuff is that clicking Help generally does not help. I resorted to watching one of Adobe’s videos and checking out the screen there.

My app worked fine though and I was able to run it up in the iPhone simulator. However I really wanted to test it on the device itself. The problem: this is all you get in Dreamweaver in terms of application settings:

image

I have not yet found any documentation from Adobe concerning what to do once your PhoneGap app is ready for on-device testing, though there may be some somewhere.

My solution was to download a separate install of PhoneGap, picking the latest version which is 0.9.5. Then I downloaded Xcode 4 and the latest iOS SDK; I had not previously installed this as I have only just signed up for Apple’s paid developer program.

I might have been better sticking with Xcode 3.x, as it turns out that PhoneGap’s support for Xcode 4 is still work in progress. I used Shazron Abdullah’s script which creates an Xcode 4 PhoneGap project from the command line. Then I copied my Calc application and the jQuery mobile directory into the project and opened it in Xcode 4.

Nothing worked and I had to do a number of things to get it to build. Most problems were solved using this guide by Cameron Perry and the comments which follow. Here’s what I recall doing:

  • I removed a red link to PhoneGapLib.xcodeproj and added it back from ~Documents/PhoneGapLib
  • I added i386 to the list of Valid architectures in build settings, for both the PhoneGapLib and my Calc project
  • I added an entry for PHONEGAPLIB to the Xcode 4 Source Trees, set to /Users/username/Documents/PhoneGapLib/ using the full path and not the ~Documents abbreviation.
  • I obtained an ID for my app from Apple’s developer portal and pasted into the project as the Bundle identifier (info section).

At this point the project almost built but I still got two Apple Mach-O Linker errors relating to PhoneGapDelegate:

image

I tried a couple of things to fix this. I added the PhoneGapLib project as a target dependency for Calc, which did no harm but was not a fix. Then I went to the Link Binary with Libraries section of Build Phases and added a reference to libPhoneGapLib.a

image

The odd thing is that libPhoneGapLib.a now appears in my project in red, suggesting something missing, but the project now builds fine; I am sure an Xcode 4 guru can advise.

So here is my app running on a real iPhone 4:

image

I slightly modified the design to fit the iPhone 4 screen.

Now for the bad news: performance is still not really good enough. To be clear, the problem is a slight pause between tapping a button and the number being entered. One bad symptom is that if you are in a hurry and tap several numbers quickly, some may not register. The iPhone 4 runs the app slightly better than my HTC Desire, but I would still not be happy releasing it with this performance – leaving aside the fact that a better calculator app comes free with the iPhone.

I tried specifying a release build in Xcode 4 but it made little difference. I suspect performance could be improved either by not using jQuery mobile, or by configuring it to reduce the richness of the buttons it creates.

Leaving that aside, it seems to me that Adobe has some work to do in making it easier to get from a Dreamweaver project running in the emulator, to an app that you can test on a device and deploy to the app store. Although the steps I took seem arduous, it is not really so bad once you get it working. You could create a much more complex app entirely within Dreamweaver, and then the work involved in moving it to Xcode would be pretty much the same as I had to do for my simple calculator. So I am not going to say that the PhoneGap integration is no use, just that it needs better documentation. Maybe in the next version we will get fuller integration that will do device build and deploy as well as building for the simulator.

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.

adobe, mobile, professional, software development, visual studio, Web, web authoring

Native apps better than web apps? That’s silly talk says PhoneGap president

1 Comment

When I attended Mobile World Congress in February one of my goals was to explore the merits of the various different approaches to writing cross-platform mobile apps. One of the key ones is PhoneGap, and I got in touch with Nitobi’s president and co-founder André Charland. As it turned out he was not at that particular event, but he kept in touch and I spoke to him last week.

PhoneGap works by using the installed HTML and JavaScript engine on the device as a runtime for apps. That is not as limiting as it may sound, since today’s devices have high performance JavaScript engines, and PhoneGap apps can be extended with native plug-ins if necessary. But aren’t there inconsistencies between all these different browser engines?

Sure, it’s kinda like doing web development today. Just a lot better because it’s just different flavours of WebKit, not WebKit, Gecko, whatever is in IE, and all sorts of other differentiation. So that’s definitely how it is, but that is being overcome rather quickly I’d say with modern mobile JavaScript libraries. There’s JQuery Mobile, there’s Sencha Touch, there’s DoJo Mobile just released, SproutCore, which is backed by Strobe, which is kinda the core of Apple’s MobileMe.

There’s tons of these things, Zepto.js which is from the scriptaculous guy, Jo which is a framework out of a Palm engineer, the list of JavaScript frameworks coming out is getting longer and longer and they’re getting refined and used quite a bit, and those really deal with these platform nuances.

At the same time, phone manufacturers, or iOS, Android, WebOS, and now RIM, they’re competing to have the best WebKit. That means you’re getting more HTML5 features implemented quicker, you’re getting better JavaScript performance, and PhoneGap developers get to take advantage of that.

says Charland. He goes further when I put to him the argument made by native code advocates – Apple CEO Steve Jobs among them – that PhoneGap apps can never achieve the level of integration, the level of performance that they get with native code. Will the gap narrow?

I think it will go away, and people will look back on what they’re saying today and think, that was a silly thing to say.

Today there are definitely performance benefits you can get with native code, and our answer to that is simply that PhoneGap is a bundle made of core libraries, so at any point in your application that you don’t want to use HTML and JavaScript you can write a native plugin, it’s a very flexible, extensible architecture … So you can do it. We don’t necessarily say that’s the best way to go. Really if you’re into good software development practices the web stack will get you 90%, 95% of the way there, so that apps are indistinguishable from native apps.

Some of the native features we see in iOS apps, they’re reminiscent of Flash home pages of ten years ago, sure you can’t do it in HTML and JavaScript but it doesn’t add any value to the end user, and it detracts from the actual purpose of the application.

The other thing is, a lot of these HTML and JavaScript things, are one step away from being as good in a web stack as they are in native. When hardware acceleration gets into WebKit and the browser, then performance is really just as good.

Charland is also enthusiastic about Adobe’s recent announcement, that PhoneGap is integrated into Dreamweaver 5.5:

Two things are exciting from our perspective. It gives us massive reach. Dreamweaver is a widely used product that ties in very nicely to the other parts of the creative suite toolchain, so you can get from a high-level graphic concept to code a lot quicker. Having PhoneGap and JQuery Mobile in there together is nice, JQuery Mobile is definitely one of the more popular frameworks that we see our community latching on to.

The other thing is that Dreamweaver targets a broader level of developer, it’s maybe not super hard core, either Vi or super-enterprise, Eclipse guys, you know, it’s people who are more focused on the UI side of things. Now it gives them access to quickly use PhoneGap and package their applications, test them, prove their concepts, send them out to the marketplace.

He says Adobe should embrace HTML and Flash equally.

I also asked about Windows Phone support, and given that Microsoft shows no sign of implementing WebKit, I was surprised to get a strongly positive response:

We have something like 80% of the APIs in PhoneGap running on Windows Phone already. That’s open and in the public repo. We are just waiting basically for the IE9 functionality to hit the phone. The sooner they get that out in public, the sooner we can support Windows Phone 7. We have customers knocking at our door begging for it, we’ve actually signed contracts to implement it, with some very large customers. Just can’t there soon enough, really. I think it’s an oversight on their part to not get IE9 onto the phone quicker.

PhoneGap is at version 0.94 at the moment; Charland says 0.95 will be out “in a few weeks” and he is hoping to get 1.0 completed by O’Reilly OSCON in July.

I’ve posted nearly the complete transcript of my interview, so if you are interested in Charland’s comments on building a business on open source, and how PhoneGap compares to Appcelerator’s Titanium, and what to do about different implementations of local SQL on devices, be sure to read the longer piece.

adobe, professional

All-new Adobe Audition is re-written for cross-platform, some features not yet ported

Adobe’s forthcoming Creative Suite 5.5 includes a significant change to its audio editing support. The Soundbooth application has gone, replaced by a new version of Adobe Audition for both Mac and Windows.

image

I thought this was good news. Audition has always been an excellent product, even back in the days when it was Cool Edit from Syntrillium – Adobe acquired Syntrillium’s technology in 2003. I found it difficult to understand why Adobe had two audio products, especially when Soundbooth is not as capable as Audition. Until now though, Audition was Windows-only, and Creative Suite is cross-platform for Mac and Windows.

Now Adobe’s Durin Gleaves has posted in detail about the history of Soundbooth and Audition. The rationale for Soundbooth was not that suite users required a simpler audio editor, as Adobe had told me previously, but rather that porting Audition was too difficult:

The Audition team looked at the 15 years of legacy Windows code and were not confident the application could be ported quickly enough to satisfy the CS release schedule. As an audio editor was necessary in the suite package, we created Soundbooth which was a simple audio editor built on top of Premiere Pro’s media playback engine. This enabled the team to provide value to the Suite, but the limitations of a playback engine crafted to handle large video files was not ideal for detailed audio production.

To Adobe’s credit, it did not give up on bringing Audition to Creative Suite but has spent two years re-writing Audition in cross-platform code:

So we’ve spent the past two years re-writing Audition from the ground-up, preserving or updating our core DSP, modernizing the code to take advantage of current hardware and operating system technology, and emphasizing increased productivity and speed with every feature.

says Gleaves. The new Audition is optimised for multi-core systems and makes full use of background processing to improve productivity. On the Mac it supports Core Audio and Apple AudioUnit effects, and on Windows ASIO, though there is no mention of WASAPI, the low-latency audio API in Windows Vista and Windows 7. Steinberg’s VST (Visual Studio Technology) is supported on both platforms.

It it is not all good news though. To some extent Audition in CS 5.5 is a new application, and not all the features of Audition 3 have made it across. Gleaves lists the following as features which are not in this version:

  • Tone and noise generation
  • Pitch correction
  • Scientific filters
  • Graphic Phase Shiftter
  • MIDI support
  • CD burning

Most of these are likely to return in a future update.

While it is a shame to see missing features, it makes sense for Adobe to unify its audio development effort on a new and solid base.

One other thing I should mention. Soundbooth has a feature called Analyze Speech for which I had high hopes, as I frequently need to transcribe interviews, but in practice the results were disappointing. I suspect it may work reasonably when there is a script with which to match the audio. That does raise the question though: are there any features in Soundbooth that will be missed following the transition to Audition?

adobe, flash, iphone, mobile, software development, web authoring

Adobe announces Flash Builder for PHP, PhoneGap integration in Dreamweaver

Adobe has stepped up its support for mobile and Flash development with a couple of announcements today.

The first is that Dreamweaver 5.5, part of the new Creative Suite 5.5, has integrated support for PhoneGap.

image

PhoneGap lets you build apps for Apple iOS and Google Android using HTML and JavaScript, taking advantage of the WebKit runtime that is present in these devices. The apps are packaged as native apps and also have access to some device-specific features. This does not mean Adobe is abandoning Flash, but is part of a both/and strategy, which makes sense to me.

There is also a new 4.5 version of Flash Builder which has greatly improved mobile support.

image

 

Flex 4.5 compiles to AIR apps on Android, Blackberry and iOS, as well as desktop Mac, Windows and Linux.

You can debug directly on an Android device connected via USB, or using a new emulator built into Flash Builder:

image

Adobe has also announced Flash Builder 4.5 for PHP, in partnership with Zend. A great feature is that you can debug seamlessly from PHP code on the server to Flex code running in a Flash client, provided you are using Zend server.

The new Flash Builder products will ship within 30 days. The premium edition is part of the Creative Suite 5.5 bundle – an improvement over Creative Suite 5.0 which only bundled the Standard edition – or available separately, while Flash Builder for PHP is a separate purchase at $399 or €319 for Standard, and $799 or €629 for Premium.

I asked Adobe’s Adam Lehman, Flash Builder produce manager, how developers should decide between PhoneGap and AIR for Mobile, given that both are now in Creative Suite.

They’re coming from two different technical perspectives. If you’re going to come in with your HTML skills and try to build an application that way, PhoneGap is better than trying to go and learn ActionScript and Flex from scratch. But from a performance and functionality perspective we believe we’re offering a lot better solution with Flash Builder and Flex.

The other part of it is that our tooling is superior. The sort of workflow that we showed [Design and develop with round-tripping between Flash Catalyst and Flash Builder] isn’t going to be available on the PhoneGap side with our tooling. Dreamweaver might be able to support different layouts and things like that, but it is not going to be a full-fledged IDE. What you’re getting with the AIR runtime and the full tooling stack is far superior that if you were building the HTML-based PhoneGap app. You can always tell a PhoneGap app, you can tell that it is running in an embedded browser. There’s tons of inconsistencies between the devices because the browsers are very different. There’s a lot of advantages to going AIR where you know that the design is going to look exactly the same. But while we love Flash we’re not zealous about it to ignore the fact that you can build with these other technologies as well.

More information on Flash Builder 4.5 here.