Category Archives: software development

Infragistics: upbeat on Windows Phone but also building for Apple iOS, Google Android

I spoke to Dean Guida, CEO and co-founder of Infragistics, at TechEd in Atlanta earlier this week. Infragistics makes components, mainly for Windows but now beginning to support non-Windows clients. There is a set of jQuery controls in preparation, and “Our roadmaps are also going to deliver native on Android and iPhone,” Guida told me. “We have a lot of software companies that use our tools in their commercial apps, and a lot of enterprises, and we feel that we need to do it,” though he adds, “we feel that the best and the smartest business solution is to go mobile web.”

image

Infragistics has a focus on data visualization, and Guida showed me some great-looking components that show animated charts, with a huge range of customisation options, and including geo-spatial and timeline controls.

I was intrigued to find Guida more upbeat about Windows Phone than most commentators, though I make allowance for the fact that his company has a component suite for the platform. “More than half of our customers told us that they’re either building or they will build for Windows Phone in the next 12 months,” he told me.

His view, which I share, is that they key advantage of Windows Phone is to Microsoft-platform enterprises rather than to consumers. “It’s so easy to extend their knowledge of Silverlight and extend apps, that they’ll be able to extend the data and the access to information this way. I think that’s going to be a beachhead for Microsoft.”

Of course Microsoft has marketed Windows Phone to consumers so far, and has told businesses they should continue to use Windows Mobile 6.5, clearly a dead-end. It may be easier when the company is able to move on from this mixed messaging and get behind Windows Phone as a business mobile platform.

Continuing a contrarian theme, Guida is also positive about Windows Presentation Foundation (WPF). “It’s huge, especially in the financial markets. They’ve made big bets on it. They’ve built a lot of their trading apps and a lot of their internal apps on it. We’ve been telling Microsoft this for years,” he says.

The problem I guess is that while WPF/Silverlight makes sense for data visualisation for internal apps where you control the platform, for broad reach apps that are visible to the rest of us, Adobe Flash or some other approach is a better fit.

It is understandable that companies like Infragistics are keen to talk up the Microsoft platform. Their business depends on it. It is true that Infragistics is now experimenting with other platforms like Apple iOS and Google Android, but historically developers on non-Microsoft platforms have not formed a strong component market.

“They don’t get it as much as Microsoft developers,” says Guida. “We used to have a ton of Java components. I was at the second JavaOne conference. We built some of the first AWT components, JavaBeans, Swing components. There’s a lot more pain developing for these platforms than on the Microsoft platform, Microsoft has done a great job with the tooling. Why have that pain? I think there is a distinction between the Microsoft and the non-Microsoft developer, that they have a higher tolerance for, pain’s probably not the right word, but a higher tolerance for taking longer to get stuff done. I can only believe that over time maturity will happen. It’s really about satisfying a business need or a consumer need. These platforms are different, but if we go in and give them the tools, why not? We’re really just this year starting to get there.”

It is a brave hope; but looking at the Infragistics site, there are currently no Java controls on offer, and even the 2008 NetAdvantage for JavaServer Faces (JSF) seems to have disappeared. If the Microsoft client platform does decline, the future will be challenging.

Three questions about Microsoft’s cloud play at TechEd 2011

This year’s Microsoft TechEd is subtitled Cloud Power: Delivered, and sky blue is the theme colour. Microsoft seems to be serious about its cloud play, based on Windows Azure.

Then again, Microsoft is busy redefining its on-premise solutions in terms of cloud as well. A bunch of Windows Servers on virtual machines managed by System Center Virtual Machine Manager (SCVMM) is now called a private cloud – note that the forthcoming SCVMM 2012 can manage VMWare and Citrix XenServer as well as Microsoft’s own Hyper-V. If everything is cloud then nothing is cloud, and the sceptical might wonder whether this is rebranding rather than true cloud computing.

I think there is a measure of that, but also that Microsoft really is pushing Azure heavily, as well as hosted applications like Office 365, and does intend to be a cloud computing company. Here are three side-questions which I have been mulling over; I would be interested in comments.

image

Microsoft gets Azure – but does its community?

At lunch today I sat next to a delegate and asked what she thought of all the Azure push at TechEd. She said it was interesting, but irrelevant to her as her organisation looks after its own IT. She then added, unprompted, that they have a 7,000-strong IT department.

How much of Microsoft’s community will actually buy into Azure?

Is Microsoft over-complicating the cloud?

One of the big announcements here at TechEd is about new features in AppFabric, the middleware part of Windows Azure. When I read about new features in the Azure service bus I think how this shows maturity in Azure; but with the niggling question of whether Microsoft is now replicating all the complexity of on-premise software in a new cloud environment, rather than bringing radical new simplicity to enterprise computing. Is Microsoft over-complicating the cloud, or it is more that the same necessity for complex solutions exist wherever you deploy your applications?

What are the implications of cloud for Microsoft partners?

TechEd 2011 has a huge exhibition and of course every stand has contrived to find some aspect of cloud that it supports or enables. However, Windows Azure is meant to shift the burden of maintenance from customers to Microsoft. If Azure succeeds, will there be room for so many third-party vendors? What about the whole IT support industry, internal and external, are their jobs at risk? It seems to me that if moving to a multi-tenanted platform really does reduce cost, there must be implications for IT jobs as well.

The stock answer for internal staff is that reducing infrastructure cost is an opportunity for new uses of IT that are beneficial to the business. Staff currently engaged in keeping the wheels turning can now deliver more and better applications. That seems to me a rose-tinted view, but there may be something in it.

Mono splits from Novell/Attachmate to form basis of new company

Mono is an open source implementation of .NET, formerly sponsored by Novell, and its future following Novell’s acquisition by Attachmate has been the subject of speculation.

Today Mono leader Miguel de Icaza has revealed new plans. In a blog post, he announces Xamarin, a new company focused on Mono. This company will build new commercial .NET tools for Apple iOS and Google Android, to enable .NET development on those platforms. Note that they will not be called MonoTouch and MonoDroid, the Novell offerings for this, but will be “source compatible”. I am sure there are brand and intellectual property ownership issues here; but de Icaza is no stranger to negotiating tricky issues of this kind, bearing in mind Mono’s relationship with Microsoft .NET. However I am not sure why the new company cannot acquire the existing brands, since it seems that Attachmate will no longer be able to support them.

The plans are not exactly new, but have been forced by Attachmate’s decision to lay off the entire Mono team:

We have been trying to spin Mono off from Novell for more than a year now. Everyone agreed that Mono would have a brighter future as an independent company, so a plan was prepared last year.

To make a long story short, the plan to spin off was not executed. Instead on Monday May 2nd, the Canadian and American teams were laid off; Europe, Brazil and Japan followed a few days later. These layoffs included all the MonoTouch and MonoDroid engineers and other key Mono developers.

Apparently Xamarin has “angel funding” but is looking for more.

The advent of MonoTouch and MonoDroid has been good for Mono, since it gives the project a stronger business model than it had previously. These mobile platforms are hot, and the ability to code for them in C# is great for Microsoft Platform developers. This factor could enable Xamarin to succeed.

On the other hand, Novell’s name gave Mono enterprise credibility as well as the backing of a large company, and these it now lacks.

The curious thing is that Mono is valuable to Microsoft. The company seems at times to hate Mono, because it removes the need for Windows, and at other times to love it, because it extends the breadth of .NET to include Linux and now iOS and Android. Microsoft gave some sort of official status to Moonlight, the Mono implementation of Silverlight, though the company’s support for Moonlight has always seemed hesitant.

So can we expect now that the company which can afford $8.5 billion for Skype, could expend a few million in support of Xamarin? Or will it stand by and hope that Mono fades away?

I have no idea, though I would like to see both Mono and Xamarin succeed. It is no threat to Microsoft, but does take .NET to places that Microsoft will never support. Without Mono, C# is merely a language for programming Windows.

Hands On with Adobe Flash Builder 4.5 for Android

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.

Microsoft’s Azure toolkit for Apple iOS and Android is a start, but nothing like enough

Microsoft ‘s Jamin Spitzer has announced toolkits for Apple iOS, Google Android and Windows Phone, to support its Azure cloud computing platform.

I downloaded the toolkit for iOS and took a look. It is a start, but it is really only a toolkit for Azure storage, excluding SQL Azure.

image

What would I hope for from an iOS toolkit for Azure? Access to SQL Server in Azure would be useful, as would a client for WCF (Windows Communication Foundation). In fact, I would suggest that the WCF RIA Services which Microsoft has built for Silverlight and other .NET clients has a more useful scope than the Azure toolkit; I realise it is not exactly comparing like with like, but most applications built on Azure will be .NET applications and iOS lacks the handy .NET libraries.

A few other observations. The rich documentation for WFC RIA Services is quite a contrast to the Doxyfile docs for the iOS toolkit and its few samples, though Wade Wegner has a walkthrough. One comment asks reasonably enough why the toolkit does not use a two or three letter prefix for its classes, as Apple recommends for third-party developers, in order to avoid naming conflicts caused by Obective C’s lack of namespace support.

The development tool for Azure is Visual Studio, which does not run on a Mac. Microsoft offers a workaround: a Cloud Ready Package which is a pre-baked Azure application; you just have to amend the configuration in a text editor to point to your own storage account, so developers without Visual Studio can get started. That is all very well; but I cannot imagine that many developers will deploy Azure services on this basis.

I never know quite what to make of these little open source projects that Microsoft comes up with from time to time. It looks like a great start, but what is its long-term future? Will it be frozen if its advocate within Microsoft happens to move on?

In other words, this looks like a project, not a strategy.

The Windows Azure Tools for Eclipse, developed by Soyatec and funded by Microsoft, is another example. I love the FAQ:

image

This sort of presentation says to developers: Microsoft is not serious about this, avoid.

That is a shame, because a strategy for making Azure useful across a broad range of Windows and non-Windows clients and devices is exactly what Microsoft should be working on, in order to compete effectively with other cloud platforms out there. A strategy means proper resources, a roadmap, and integration into the official Microsoft site rather than quasi-independent sites strewn over the web.

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

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.

Succeeding in an App Store world: lessons from the Angry Birds story

At Mobile World Congress earlier this year I heard Rovio CEO Mikael Hed address a small group of Apple platform developers on the subject of the changing world of app development. His starting point is that mobile apps and the app store model are transforming the business of software. Of course he has a games industry perspective, but my hunch is that what he says applies more widely. I note that the App Store concept has already come to the Mac, and that Microsoft will follow Apple with something similar in Windows vNext.

What is the effect of an App Store? It combines opportunity and challenge for developers. Opportunity because apps can be found, purchased and installed in a few clicks. Challenge because app stores attract lots of apps, and the barriers to entry are low, much lower than traditional retail channels. This forces prices down and makes it hard to have your particular app stand out.

The App Store model seems to include the idea of single-purpose apps at low prices. Apple still sells iWork, its office suite, for £72.00 as boxed product (UK prices), but on the Mac App Store it is split into three products, Pages, Keynote and Numbers, at £11.99 each. Even if you buy all three it is half the price of the box.

Mac desktop apps are larger and more sophisticated than iPhone apps, so I guess they will always attract higher prices; but I also guess that the factors which have driven down prices on the iPhone App Store will exert the same influence on the desktop store.

So where are prices going? Here is what Hed told us:

On the pricing side, we know now that on the App Store the standard price is fast becoming free, zero. And the premium price is 99 cents. If you go higher than that, then there are higher risks, because you might never reach the top ten, or top 100, and if you do, it will drop off very fast, there’s huge price sensitivity. So this also is a big change for traditional publishers who are used to high prices up front, and that’s the classic business model in gaming. That is changing, so game developers must find additional revenue streams.

This low pricing is the foundation of his thesis. Hed’s view is that software companies, in the games industry at least, have to be ready for it. Further, he thinks that the shift toward mobile is profound and will not reverse:

We are seeing right now a big shift from retail focused, location based games where you have to have your console plugged into your TV. That is slowly slipping away and in its place is coming the digitally downloaded game that you can play anywhere.

How then do you survive and prosper in this new world? Hed’s answer is to build a brand, and find diverse ways to monetize it.

He told us the history of Angry Birds. This, he says, is the first mock screenshot which his game designer made in 2009:

image

The way he explained this game concept to me was that you have these different coloured birds and then you have blocks with similar colours, tap on one of the blocks and the birds will fly and destroy that block. I listened to that description and I felt like, maybe this game concept is not a winner as such, but everybody liked these characters very much and we felt like, hey, we have really here a good starting point.

Rovio at the time was doing what Hed called “work for hire”, such as casual games commissioned by operators or other publishers. “We didn’t have a lot of capital to put into our game,” he said. Rovio kept half its 12-strong team doing the work for hire, and put the other half on Angry Birds. This meant the game took 8 months to develop rather than the usual 3 or 4 months, but he said this slower development time worked out well because the result was more polished.

Hed told us that most app developers push out apps too quickly:

They are concerned about getting their apps quickly out there on the market in order to start generating revenue. Before Angry Birds we did release a couple of other iPhone titles and they didn’t do well at all. We learned a lot from that and one of the things we learned is that never release something that is not completely finished, because it’s so easy for reviewers to just rip your game apart because something about it was not perfect. And that is exactly what is happening. It’s tremendously demanding, the consumer on the app store is tremendously demanding even if they pay only 99 cents, they still expect it to be perfect.

Even more significant was that Rovio consciously planned for Angry Birds to be more than just a game:

Our primary goal with Angry Birds was not to make a lot of money in the app store. Our primary goal was to build a brand.

Angry Birds took off pretty fast. It became the top seller on the iPhone App Store, first in Finland, then in the UK in February 2010, then in the USA in April 2010. Rovio made some decisions. First, it would stick with Angry Birds and build it into a strong franchise, rather than simply investing its profits into new game titles. Second, it would continue to offer free updates for the original app.

Where then are the “additional revenue streams” which Hed says are essential in order to thrive in this new world? In-app purchasing is one, he said, but Rovio decided not to sell additional levels via this channel. Instead it came up with the Mighty Eagle, which he calls a product rather than a feature:

In the Mighty Eagle we offered a way for users to pass levels that they are stuck on, so it gives added value to the users. But we made it into a product, and that is one of the important things of how we act in the marketplace, we make products, we don’t make features. And in this our big role model is Apple. You can see that nobody is that much interested in one “feature”. People want products. That’s why you don’t see Apple coming out with a feature called video calling. You see them coming out with a product called Face Time.

I am not entirely convinced by the distinction between products and features, but I understand the value of this way of marketing software. Hed says Rovio has been rewarded with a 40% conversion rate, much higher than for most in-app upgrades.

Rovio is also doing merchandising. 

image

This helps to sustain the franchise and to make sure that the franchise stays relevant for years to come, and it supports our game sales, and our game sales support our merchandising sales.

he says. It is another example of finding additional revenue streams.

Hed also talked about TV and film projects. Rovio partnered with 20th Century Fox to make a game that ties in with Rio the Movie, hence the game Angry Birds Rio.

He adds that mobile advertising is a key area:

We can see from the amount of time that people spend playing our games and playing everybody else’s games and using those apps, that mobile app advertising will be huge. We will see shifting of advertising towards mobile, because there users will be engaging for long periods of time, they will be exposed to brands repeatedly, they will be closer to the point of purchase.

This has worked for Rovio so far, though personally I am not sure for how long it can prosper if the Angry Birds franchise is all it has. It is a fashion thing and people will get bored of it – or does Rovio now have its own enduring franchise like Disney’s Mickey Mouse?

My main interest though is Hed’s insistence that software world is changing, prices are tumbling, and software developers will have to look for ways to monetize apps that go beyond the purchase price. “It’s the same for everybody. Now the industry is in the midst of transformation so everybody must adapt,” he says.

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

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.

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

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.

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

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.