Tag Archives: software development

Apple lifts restrictions on app development tools, publishes review guidelines

Apple has lifted its restrictions on the development tools used to create iOS (iPhone and iPad) apps, in a statement published today:

We have listened to our developers and taken much of their feedback to heart. Based on their input, today we are making some important changes to our iOS Developer Program license in sections 3.3.1, 3.3.2 and 3.3.9 to relax some restrictions we put in place earlier this year. In particular, we are relaxing all restrictions on the development tools used to create iOS apps, as long as the resulting apps do not download any code. This should give developers the flexibility they want, while preserving the security we need.

In addition, Apple says it is publishing the App Store Review Guidelines in the hope that this will make the approval process more transparent.

Good news I guess; but why? Maybe in part because the restrictions made little sense and were possibly unenforceable; and in part because Android’s popularity is putting pressure on Apple to be more developer-friendly. In practice, some apps that you would have thought breached the requirements apparently made it through the approval process; and those publishers of cross-platform tools which kept their nerve have their patience rewarded.

But what about Adobe? Apple’s development restrictions seems to trigger a significant change of direction, with work on the Packager for iPhone stopped, Android devices issued to employees, and evangelism for Android in Adobe blogs and tweets.

Since Apple is not changing its mind about runtimes, but only about development tools, this change of mind does not enable Flash on the iPhone; but I guess Adobe could now revive its cross-compilation work. On the other hand, Apple’s pronouncements have caused disruption for Adobe and perhaps served more as a wake-up call: this is a closed platform with one owner and therefore a risky target for investment.

Decompiling Silverlight

A Silverlight application is a .NET application. Most developers will be aware of this; but it is worth noting that whereas ASP.NET code executes on the server and is not normally available for download, Silverlight code is downloaded to the client and can easily be decompiled. It is almost as easy to view as JavaScript code in the browser.

If you want to investigate this, the first thing to do is to find the .xap file which contains the Silverlight application. You will likely find this in your browser cache, or you can download it directly from the web site hosting the application. If you have out-of-browser Silverlight apps, they are usually located at:

C:\Users\[username]\AppData\LocalLow\Microsoft\Silverlight\OutOfBrowser

Copy the .xap file somewhere convenient, and rename it to have a .zip extension. Then extract the files. The result looks something like this:

image

Next, you need a .NET decompiler such as Redgate .NET Reflector. Run Reflector and open a .dll file containing application code. Select a method, and Reflector does its best to show you the code. It does a good job too:

image

The purpose of this post is not to encourage decompiling other people’s code, but rather to make the point that even though Silverlight code is “compiled”, it is trivial to read it – just in case anyone thought it was a bright idea to store passwords or other authentication secrets there.

The solution is to never to put anything security-critical in client-side code. Second, you can use an obsfuscator such as dotfuscator to make the decompiled code harder to read.

Getting started with Android – a few hassles

I’m setting myself up for Android development, and my HTC Desire arrived today. It is a lot of fun, though I have had a few hassles, partly because my device is locked to Orange and of course I wanted to upgrade to Android 2.2 “Froyo” right away. There are also a few issues with the Orange branding on a Desire, including the absence of Google Talk and applications like Orange Maps that you probably will not use. I went through a series of steps to unbrand the phone and install Android 2.2.

It is an odd situation, where mobile operators work hard at adding their branding and applications to the device, only for canny users to work out how to remove them. Branding also delays updates. If Android is updated, the operator has to receive the updated operating system image from the phone manufacturer, HTC in this case, add its customizations, and then apparently sent it back to HTC for packaging.

My guess is that if an operator decided to ship the standard Android image it would be a selling point and attract more customers. I even have a catchy name to offer: “Naked Desire”. How about it?

Still, all went well with my hacks; and eventually I was up and running with Android 2.2 and of course Flash 10.0:

image

That said, I had an annoying issue with Android Market. I selected an application, it would appear to start installing, but stuck on “Starting download” or “Downloading” with no actual progress.

It turns out this is a common problem – see here for one of many discussions. A popular fix is to change your account from someone@gmail.com to someone@googlemail.com, but this did not apply to me. I discovered the reason, which is that my wifi is behind Microsoft’s ISA Server. Android Market requires TCP outbound connections on port 5228. I configured ISA accordingly, and after cancelling and restarting the downloads they succeeded.

Finally, I wanted a screen grab or two to decorate this post. I used the method described here, fine for developers but not ideal for casual users.

image

I’ll report more impressions shortly, including no doubt the inevitable iPhone comparison.

Review: Tapworthy – designing great iPhone Apps by Josh Clark

Developing for iPhone is a hot topic. Many developers are not only having to learn Apple’s Objective C and the Cocoa application framework, but are also new to mobile development. It is a big shift. Josh Clark is a iPhone designer, and his book Tapworthy is about how to design apps that people will enjoy using. It is not a programming book; there is not a single snippet of Objective C in it.

His book illustrates the power shift that has taken place in computing. In the early days, it was the developer’s task to make an application that worked, and the user’s task to understand how to use it, through manuals, training courses, or whatever it took.

There are still traces of this approach in the software industry, but when it comes to iPhone apps it has reversed completely. The app creator has to build an app that the user will find intuitive, useful and fun; otherwise – no sale.

An early heading reads “Bored, Fickle and Disloyal”. That’s the target user for your app.

Clark’s point is valid, and he does hammer it home page after page. You will get the message; but it can get tiresome. His style is frank and conversational: some readers will love it, others will find it grating after a chapter or two.

Even if you are one of the latter group, it is worth persevering, because there is a ton of good content here. There are also numerous short interviews with developers of actual apps, many of them well-known, discussing the issues they faced. The persistent issue: we’ve got a complex app, a small screen, and intolerant users, how on earth do we make this seem simple and intuitive?

Constraints like these can actually improve applications. We saw this on the web, as the enforced statelessness and page model of web applications forced developers to simplify the user interface. It is the same with mobile. Joe Hewitt, author of the first generations of Facebook for iPhone:

There is so much stuff that is actually better on the small screen because it requires designers to focus on what’s really important.

So what’s in the book? After a couple of scene-setting chapters, Clark drills down into how to design for a tiny touchscreen. Be a scroll sceptic, he says. Chapter 4 then looks at app structure and navigation. Chapter 5 takes you blow by blow through the iPhone controls and visual elements. Then we get a chapter on making your app distinctive, a chapter on the all-important start-up sequence and how to make seem instantaneous, and a chapter on touch gestures.

The last three chapters cover portrait to landscape flipping, alerts, and finally inter-app communication and integration.

Throughout the book is illustrated in full colour, and the book itself is a pleasure to read with high quality paper and typography. 300 pages that will probably improve your app design and increase its sales; a bargain.

 

Enterprise app development on Apple iPhone and iPad

Apple’s iPhone is still perceived as primarily marketed to individuals rather than corporates. However, I was interested to see how much Apple is doing to attract corporate developers. First, Apple now supports some basic enterprise-friendly features, such as Microsoft Exchange (with a few caveats), VPN, remote wipe, and the ability to lock down iTunes to some extent. Without these capabilities, the devices would not be acceptable in many environments, making it pointless to consider them for custom applications.

Unfortunately iTunes is still needed for activation, deploying software updates, and installing applications. It is silly that Apple requires business users to install a music library to use its phone, I guess reflecting the device’s history as a music player. It is also a somewhat intrusive application especially on Windows.

If you then want to develop internal applications, you sign up for the iPhone Developer Enterprise Program. At $299 per year this is more expensive than the more general equivalent, but no big deal. Then you have to get a digital certificate from Apple. Next, create one or more “provisioning profiles” that install onto the device and authorize it to run your applications. Applications you create must be signed with your digital certificate. Finally, you can add the signed applications to an iTunes library, and users can then drag them to their iPhone or iPad. It will only run on devices that have the matching provisioning profile installed. Organisations can also revoke applications by revoking the identity used to sign the provisioning profile.

As Adobe pointed out to me, since these apps do not go through Apple’s approval process, there is nothing to stop corporate developers using the Flash Packager for iPhone that is available in Creative Suite 5.

There is more detail on Apple’s iPhone in Business page.

Google App Inventor – another go at visual programming

Google has put App Inventor for Android on Google Labs:

To use App Inventor, you do not need to be a developer. App Inventor requires NO programming knowledge. This is because instead of writing code, you visually design the way the app looks and use blocks to specify the app’s behavior.

Sharon Machlis at Computerworld says it is a breakthrough:

App Inventor has the potential to do for mobile app creation what VisiCalc did for computations — move it out of the exclusive realm of specialists in glassed-in data centers (or, in the case of mobile apps, programmers who can use a conventional SDK) into the hands of power users as well as make it easier for IT departments to create corporate apps.

I’d like to believe this but I do not. It is visual programming; it is interesting; but it is similar to other visual programming tools that we’ve seen in the past. These tools have their place for learning, and there is probably some small sub-section of programming tasks for which they are ideally suited, and some small sub-section of developers for whom they work better than text-based tools, but for most of us textual code is easier and more productive when we are coding the logic rather than the user interface of an application.

I took a look at the Quiz Me tutorial. Here’s a code snippet – it is a click event handler:

image

and here is the complete application. Note the navigator at top right, which would be vital for finding your way around a more complex app:

image

It is often a problem with visual programming tools: scaling an app beyond a few simple blocks introduces difficulties with navigation and project management. Our text-based tools are highly evolved for managing large projects with thousands of lines of code.

What about democratisation of programming through visual tools like this, coding without coding, that will allow domain specialists to develop apps without involving developers? Is visual programming really easier for the non-specialist than textual programming? I’m not convinced. It should be easier to get started: no syntax errors, no language reference to consult. In the end though, is a purple “if” block with jigsaw connections for “test” and “then-do” much easier than typing if (test) {code block}?

It is just a different way of presenting the same thing, but less concise and less flexible. I suspect the domain specialist who can succeed with App Inventor will also succeed with code; and that people who struggle with code-based programming in an accessible language like Basic will also struggle with visual programming.

Where this gets interesting is when you have powerful components that expose a simple interface. A high-level non-specialist programmer can drag a component onto a design palette and do amazing things, because of the smarts that are hidden inside. Components do democratise development. One reason for the success of Microsoft’s development platform is that from Visual Basic through COM and then .NET, the company has always made it easy to use components and fostered a strong third-party market for them. If App Inventor provides a great way to deliver components to high-level developers, it could succeed.

That said, components do not require visual programming. Microsoft has flirted with visual programming – like the abandoned PopFly – but despite using the name “visual” everywhere, Microsoft has never delivered a mainstream visual programming tool.

DevExpress merges its Silverlight and WPF UI controls, says VS 2010 is light years ahead

Developer Express is a component vendor with add-ons for Visual Studio and Delphi. It has offered a library of components for Silverlight for some time, and a separate set for WPF (Windows Presentation Foundation), but now says that Silverlight and WPF are close enough that it can merge the two into a single codebase to be called XPF (Express Presentation Framework). CTO Julian Bucknall says:

Silverlight in v4 has the ability to create desktop applications that aren’t sandboxed into triviality. In fact, Silverlight, more than ever, resembles a WPF-lite on the desktop side, to the extent of pundits considering their eventual merging. At long last it is possible to write one set of non-trivial code and compile it both for Silverlight and for WPF without having to reinvent so many wheels on the Silverlight side (and to a much lesser extent on the WPF side).

Even though Visual Studio 2010 is only just released, DevExpress is focusing all its new Silverlight and WPF development on the new platform and IDE:

The Silverlight and WPF controls in DXperience v2010.1 will require .NET 4 and VS2010. In particular, you must use the new Silverlight 4 and WPF 4; the controls will not function with the previous versions of WPF and Silverlight, such as Silverlight 3. Similarly, you cannot use VS2008 or earlier, but must use VS2010. To my mind this isn’t that much of a downside: VS2010 is light years ahead of its earlier brethren in terms of user experience and its use is de rigueur if you are creating applications with either Silverlight or WPF.

Of course it’s in Bucknall’s interests to move developers on; he’s keen to sell upgrades. I still find this interesting. Like him, I find Visual Studio 2010 a major advance on earlier versions. More significant though is the idea of a common WPF and Silverlight codebase, though presumably still with added capabilities when running on WPF. I don’t think Windows-only development is dead; the success of Windows 7 may even stimulate the market for applications that take advantage of its new features. That said, for the large subset of applications where cross-platform is desirable, Silverlight seems to me a better choice than WPF.

Intel’s compiler is best for AMD too says software director

I attended Intel’s software conference in Barcelona earlier this week, and took the opportunity to talk to Director of Software Products James Reinders. I asked him about the complaint from the FTC, which I reported on here, that Intel deliberately underperforms on non-Intel CPUs, specifically those made by AMD. Was it a valid complaint?

He was surprisingly (to me) forthright.

It’s not valid. It’s misguided. Intel’s compilers are very high performance. If you use our compiler, you’ll get better performance on Intel or AMD processors than if you used anyone else’s compiler. That’s always been our goal. We believe – I’ll use the words “in general” and that’s a legal disclaimer – in general we’re better. Why don’t I say always? Always is an absolute. Nobody is “always” anything. We are as close to always as we can figure out to be. We have many customers that use our compiler, ship code, because they believe it gets the best performance on Intel and AMD. We will back that. If you find that our compiler is getting less performance on AMD than someone else’s compiler, we consider it a bug. That includes AMD processors.

We settled the suit with AMD, we agreed that we wouldn’t do things we were accused of in future – well, we didn’t do them before. There’s a lot of proof points. AMD used our compiler for benchmarking for a long time. They didn’t do that because we were lower performance.

There are a lot of technical nuances, details of what we do in our compiler that are confusing. One of the challenges is how do we produce a binary that runs best on Nehalem, and on an older Intel processor, or on a processor that supports SSE 2.0 but not 3.0? We have technology in our compiler to try to adapt to that. We mix into that blend AMD, because AMD processors have different capabilities, in the same way that our processors have different capabilities from each other. Yes, people will say, “hey, your compiler’s checking for an AMD processor”. Yes, absolutely, we also check to see if we’re on a Intel processor that only supports SSE 2.0. We have to. AMD processors don’t support the same instructions we do. Our processors have a lot of variety too.

The short answer is that we didn’t do what we’re accused of, we’re very serious about being an excellent compiler for AMD as well as Intel, and this extends to our libraries too.

So that’s telling them. Is he correct and it was a misguided complaint? Well, as I mentioned previously, there are issues of disclosure as well as performance if you are publishing benchmarks; and it is hard to believe that Intel devotes equal effort to optimisation on AMD processors as for its own. Nevertheless I respect Reinders and don’t dismiss his statement. Perhaps Intel’s compiler is OK for AMD after all.

Martin Fowler on the ethics of software development – QCon report

Martin Fowler of ThoughtWorks gave what seemed an important session at QCon London, exploring the ethical dimension of software development with a talk called What are we programming for?. The room was small, since the organisers figured that a track on IT with a a conscience would be a minority interest; but Fowler always attracts a large audience and the result was a predictable crush.

The topic itself has many facets, perhaps awkwardly commingled. Should you walk away if your customer or employer asks you to code the wrong thing – maybe enforcing poor practice, or creating algorithms to fleece your customer’s customers? What about coding for proprietary platforms owned by vendors with questionable business practices? Fowler mentioned that around 50% of ThoughtWorks solutions are built on Microsoft .NET; and that the efforts of Bill Gates to combat malaria was something that helped him make sense of that relationship.

image

Fowler also echoed some of Robert Martin’s theme from the day before: if you build poor software, you are in effect stealing from the future revenue of your customer.

Finally, he talked about the male/female imbalance in software development, rejecting the idea that it is the consequence of natural differences in aptitude or inclination. Rather, he said, we can’t pretend to have the best people for the job while the imbalance continues. I’d add that since communication is a major theme of Agile methodology, and that females seem to have communication skills that males lack, fixing the imbalance could improve the development process in other ways.

Big questions; and Fowler had few answers. When asked for the takeaway, he said the main one is to discuss these issues more.

Microsoft .NET gotchas revealed by Visual Studio team

The Visual Studio Blog makes great reading for .NET developers, and not only because of the product it describes. Visual Studio 2010 is one of the few Microsoft products that has made a transition from native C++ code to .NET managed code – the transition is partial, in that parts of Visual Studio remain in native code, but this is true of the shell and the editor, two of the core components. Visual Studio is also a complex application, and one that is extensible by third parties. Overall the development team stressed the .NET platform, which is good for the rest of us because the developers are in a strong position both to understand problems, and to get them fixed even if it means changes to the .NET Framework.

Two recent posts interested me. One is Marshal.ReleaseComObject Considered Dangerous. I have some familiarity with this obscure-sounding topic, thanks to work on embedding Internet Explorer components. It relates to a fundamental feature of .NET: the ability to interact with the older COM component model, which is still widely used. In fact, Microsoft still uses COM for new Windows 7 APIs; but I digress. A strong feature of .NET from its first release is that it can easily consume COM objects, and also expose .NET objects to COM.

The .NET platform manages memory using garbage collection, where the runtime detects objects that are no longer referenced by active code and deletes them. COM on the other hand uses reference counting, maintaining a count of the number of references to an object and deleting the object when it reaches zero.

Visual Studio 2008 and earlier has lots of COM APIs. Some of these were called from .NET code, and for the same of efficiency called the method mentioned above, Marshal.ReleaseComObject, to reduce the reference count immediately so that the COM object would be deleted.

Now here comes Visual Studio 2010, and some of those COM APIs are re-implemented as .NET code. For compatibility with existing code, the new .NET code is also exposed as a COM API. Some of that existing code is actually .NET code which wraps the COM API as .NET code. Yes, we have .NET to COM to .NET, a double wrapper. Everything still works though, until you call Marshal.ReleaseComObject on the doubly-wrapped object. At this point the .NET runtime throws up its hands and says it cannot decrement the reference count, because it isn’t really a COM object. Oops.

The post goes on to observe that Marshal.ReleaseComObject is dangerous in any cause, because it leaves you with an invalid .NET wrapper. This means you should only call it when the .NET instance is definitely not going to be used again. Obvious, really.

Once you’ve digested that, try this illuminating post on WPF in Visual Studio 2010 – Part 2 : Performance tuning. WPF, or Windows Presentation Foundation, is the .NET API for rich graphical user interfaces on desktop Windows applications. Here is an example of why you should read the post, if you work with WPF. Many of us frequently use Remote Desktop to run applications on remote PCs or PCs that do not have a screen and keyboard attached. This is really a bad scenario for WPF, which is designed to take advantage of local accelerated graphics. Here’s the key statement:

Over a remote desktop connection, all WPF content is rendered as a bitmap. This is in contrast to GDI rendering, where primitives such as rectangles and text are sent over the wire for reconstruction on the client.

It’s a bad scenario, but mitigated if you use graphics that are amenable to compression, like solid colours. There are also some tweaks introduced in WPF 4.0, like the ability to scroll an area on the remote client, which saves having to re-send the entire bitmap if it has moved.