Tag Archives: ios

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.

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.

apple, mobile, professional, software development

The mobile app ecosystem before Apple – was it really this bad?

2 Comments

For some time I have been meaning to post about a talk I heard at Mobile World Congress, by Rovio (Angry Birds) CEO Mikael Hed. What interested me about this talk was not so much the Angry Birds app itself – now downloaded over 75 million times – but rather Hed’s thoughtful perspective on what it is like to be a software company in the App era. “It’s been a year of transformation not only for us but for the whole industry,” he told us.

image

Hed started his talk by describing life as a mobile games developer before Apple launched the iPhone in 2007. Rovio was founded in 2003, and did 51 titles before Angry Birds, encompassing “every type of game,” he said.

Before the iPhone came along we were on feature phones only. That market was completely different from the iPhone market today. Looking back on it, it’s a small miracle that there were any game companies in that ecosystem.

Why? Several reasons.

In order to have a game commercially available on a feature phone, you would have to make that game, and make probably nine other strong games in order to be interesting to the carriers. And the carriers would only take your game if you could support all the handsets that their customers had. That meant hundreds of handsets.

Dealing with the carriers was a huge headache.

You would have to make an agreement with each carrier in each country, and you had to have an all-day sales team working for you to do any business at all. It was really expensive.

After all that, the revenue share and payment system was loaded against you.

All operators would take more than half of the revenue that you would make, and then pay you a long time after your game is out. They would report quarterly, and once you get the report you send them an invoice, then they have ninety days to pay. So if by some miracle you manage to get your game onto their devices , the earliest time you would see your money would be six months later.

The system was poor for consumers too.

It was also very difficult for consumers to find these games. It varied a lot across the different carriers, how you find the games. You might have to send an SMS somewhere and get a link back, click on that, download the game, and then hope that the game would actually run on your device; and probably at the end even if you had the latest and greatest phone it was made for the lowest common denominator so it would not use any of the nice features of your phone. So you would get a poor experience, if it worked at all. That was the past ecosystem.

Ouch. Was it really that bad?

The immediate conclusion is that while Apple’s closed and dictatorial iOS ecosystem has drawbacks, it is at least one that works, whereas what existed before was badly broken.

So how are things for app developers now, in the Apple era? Look out for a follow-up post soon. And by the way, it is still by no means easy.

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.

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.

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.

apple, mobile, rants, smartphones

Escaping Apple: trying to switch away is hard

3 Comments

Mark Wadham posts his Thoughts on switching to Android. Last week he sold his iPhone 4 and switched to an HTC Desire S. I found this interesting, since I have an iPhone 4 and an HTC Desire.

The motive behind Wadham’s switch was to escape Apple’s “over-controlling ways”, rather than immediate dissatisfaction with its products, and there is mild disappointment running through his whole piece:

So in summary, android isn’t really /that/ far off the iPhone. It’s missing the cleanness of the user experience, consistency in the user interface and the glorious wealth of apps, but hopefully that will all come in time. This is a great little phone and I’m happy I made the switch. It’s not as fun to use as an iPhone, and if you’re a real UX freak you should probably stick with the iPhone at least for now, but if you’re someone who likes to tweak and customise and play around with your device android seems much more suited than Apple’s offering.

There is also some irony: HTC’s offering is not as free as he would like.

I would have loved to get rid of HTC Sense and install one of the modded roms like Cyanogen, but that currently isn’t possible due to restrictions HTC has placed on these new handsets …The good news is that, according to the research I’ve done, the root for the Desire S (and the incredible S) isn’t far off.Actually the worst thing about this phone is that it comes with a Facebook app that I can’t remove until it gets rooted.

Still, there is no question that Android is a less tightly controlled platform than iOS. The fact that you can install apps from outside Google’s Android Market is all you need to know.

In usability though, Android falls short. It lacks the obsessive attention to design that characterises Apple’s devices and software; and once you are used to iOS it is particularly hard to switch:

Eventually I got the hang of it, but even now after two days of playing and installing apps and tweaks, the UI still feels counter-intuitive and I have to consciously remember how to do things rather than it being obvious and simple like iOS.

One thing I have noticed since getting these two phones is the impact of Apple’s dock connector. There are countless iPhone/iPod docks and although there is often an option to use a non-Apple device with a mini-jack cable it is not as convenient or elegant. You cannot easily build a generic Android dock because there is no exact equivalent.

Another issue is apps. Once you have purchased a bunch of apps, you can transfer these to another iOS device. If you switch to Android, you have to start again.

There is also iTunes to think about. Let’s say you have got used to iTunes and have your music stored there. While it is possible to transfer non-DRM music to Android or other non-Apple devices, it is not necessarily obvious how to do so; and iTunes itself will only sync to Apple devices. Personally I am not a fan of iTunes; but I can see how it tends to encourage users to stick with Apple.

The bottom line is that escaping Apple requires some determination, once you are hooked into its ecosystem.

.net, adobe, apple, flash, google, mono, professional, software development

Adobe AIR 2.6, MonoMac 1.0, cross-platform is not dead yet

It is a busy time for cross-platform toolkits. Adobe has released AIR 2.6, and reading the list of what’s new you would think it was mainly for mobile, since the notes focus on new features for Apple iOS, though AIR is also a runtime for Windows, Linux and desktop Mac. New features for iOS include GPU rendering – a form of hardware accelerated graphics – access to the camera, microphone, and camera roll, and embedded Webkit for apps that use web content. On Google Android, you can now debug on devices connected via USB.

There is also a new feature called “owned native windows” which lets you have a group of windows that remain together in the Z order – this lets you have things like floating toolbars without odd results where toolbars get hidden underneath other applications.

Asynchronous decoding of bitmaps is another new feature, allowing images to be processed in the background. This seems like a stopgap solution to overcome the lack of mullti-threading in AIR, but useful nonetheless.

Since the Flash runtime does not run on iOS, Adobe has a packager that compiles an AIR application into a native app. This is now called the AIR Developer Tool or ADT. You can use the ADT to target Windows, Linux or Android as well; however platforms other than iOS still need the AIR runtime installed.

Adobe is dropping support for the original iPhone and the iPhone 3G. iPhone 3GS or higher is needed.

If you want to build a cross-platform app but prefer .NET to Adobe’s Flash and ActionScript, the Mono folk have what you need. I’d guess that the Mono team has a small fraction of the resources of Adobe; but nevertheless it has delivered MonoTouch for iOS and is working on MonoDroid for Android. Just completed in its 1.0 version is MonoMac, for building Cocoa applications on Apple OSX. Mono is not fully cross-platform, since the GUI framework is different on the various platforms, but you do get to use C# throughout.

I am happy to agree that true native code is usually a better solution for any one platform; but at a time when the number of viable platforms is increasing the attraction of cross-platform has never been greater.