In defense of the iPhone 4.0 SDK section 3.3.1

There have been many blog posts about the new iPhone 4.0 SDK which do not like section 3.3.1 of the developer license agreement, which says:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

Apple's introduced restrictions on original programming language, which has been considered an attack against Adobe Flash. However, there is more to it. The market for smartphones has been very diverse for a long time. Microsoft has attempted to standardize smartphones on Windows Mobile, which failed because of its power consumption and because it was always a bit late to the market. Apple made a huge hit with the iPhone, because they combined new technologies that made it possible to give a great smartphone experience, earlier than what would otherwise have been possible. They were rewarded for innovation.

Now, that everybody is catching up on the basic technology, like touchscreens and sensors, other software vendors are seeking ways to standardize the ways that software is written for many platforms. There is a huge saving if software vendors can create one application that can be deployed on iPhone, Android, Maemo, Bada and others, and on many different form factors. What would the result be for Apple? They would just be one of many, and they would probably not have any significant advantage over the competition. This means that their margins would drop, in a market where prices are already going down, and they would earn a lot less money. Apple does not want that, of course.

For the consumer, that would mean a lot of apps, which do not exploit each platform well - the feature lists would focus on the lowest common denominator for the target platforms, and few platform-specific features would be used for marketing apps. It would be hard for phone platform developers to add new capabilities that the developers would love to use.

Apple's strategy is to separate itself from the apps on other platforms, giving the user a unique and different experience, which they believe will be better than usual. If you have three features, and Apple does the first two perfectly but not the third, and the competitors do all three in a mediocre way, many consumers will pick the Apple product. A good example is the HP Slate: It supports flash, but nobody cares, consumers still want the iPad.

The iPhone and the iPad will never become devices that can do everything. Of those who had this expectation, many will be unhappy about Apple's latest move, but anyone who wants innovation in smartphones, great user experiences and real choice, should be happy about the new section 3.3.1.

Google Android reviewed by a Delphi developer

With the major part of my background in Delphi, but also some in C, C++, Assembler, Java, C# and others, I threw myself at the Android platform in order to figure out how it works.

The main language is Java, the obvious IDE is Eclipse, and after installing the Android SDK things are well integrated with each other. The fundamental structure is very similar to Delphi - but things have different names and formats, of course. Forms are called Activities, DFM files are XML files, there is a manifest XML-file like in Windows, a message queue like in Windows, and each application has a main thread that receives messages and is reponsible for updating the GUI (don't update the GUI from other threads).

The platform comes with some APIs. For storage, we have a file system (SD flash ram), an app-specific database (SQLite-based) and a preference storage (like .ini files or registry). There are also APIs for network access, location, sharing data between apps, phone calls, user interface integration etc.

Generally, things are straightforward, but Eclipse isn't as smooth as Delphi. Examples are usually missing from the documentation, so Google and sample apps are great friends - and even though the form designer does integrate with the IDE so that you can design something graphically, it's not as simple as putting a button on a form and double-clicking it, in order to create a "hello, world" app. One nice thing is that you only have to design one user interface, and it looks ok on many different phones with very different screen resolutions. You can also adapt the user interfaces to different resolutions, of course, especially when rotating the phone, but many standard user interfaces immediately work on all screens.

You need to programmatically attach event handlers etc., and generally, the form designer is not as neat as a typical form designer for Windows apps. Since the screen is usually very small on a phone, the user interfaces usually try to solve only one problem, like showing a list, editing one record of information etc. Therefore, there are special user interface classes for these purposes, like a "ListActivity" which is basically a form that focuses on supplying a list to a user. One of the benefits of this, is that the form then has handler functions, like OnListClick, which are implemented using class inheritance.

The Java language still does not have "procedure of object" constructs, so some event handling stuff is more complicated, like using inheritance, extra classes etc. Also, Java still feels a bit behind Delphi 2009/2010 in several aspects, but on the other hand, Java has better features in some areas, too. One interesting thing is the Google advice "Avoid creating objects" in the Android developer guide, in the "Designing for performance" section. Considering that almost all API functions require you to pass a recently constructed object, you need to create an huge amount of objects compared with typical Delphi apps, so I guess the advice tries to say, only create huge amounts, don't create extreme amounts of objects.

Performance is definitely a key issue when creating mobile apps. Performance is not so much about instructions per second, but more about responsiveness of the GUI and battery usage. Many of the things that you would want to do on a phone requires external systems to react, and they may not react immediately. For instance, a GPS fix takes time, and looking up an address over the internet can take a long time. Such things need to be handled using separate threads on Android, so if you don't master multithreading in Java, this is one of the first things to learn. Fortunately, it is not that difficult, so don't let it scare you off, Java does many of the things you need, in easy ways.

Debugging is great - the SDK includes an emulator that can emulate different kinds of devices, and you can even simulate incoming phone calls and see stacktraces from the emulator inside the Eclipse IDE. I see no reason why you should need hardware in order to develop Android software, except that I couldn't make GPS simulation work. It's probably just an option somewhere that I didn't find.

Besides a great Delphi-like form designer, one thing I really missed was a non-SQL local database similar to BDE or DBISAM. It seems to be overkill and a waste of CPU cycles to use SQL on app-specific databases that are single-user and cannot be shared by multiple applications - and somewhere I also saw some benchmarks that proved that SQL is a bad idea in this context. Data sharing to other apps is handled using Content Provider interfaces and not SQL, but that is outside the scope of this blog post.

Publishing to the Android Market is extremely simple. There is a guide for it in the Android Developer Guide, and if you follow that, your application is worldwide available immediately, and the market reports, how many phones downloaded your app and how many still have it. Upgrading is also quite simple: Just upload a new version of your app, that's it, and all users will be notified next time their phone checks for upgrades.

If you know the Java programming language and Eclipse, I would say that it should take less than a day from scratch, to install Java, Eclipse, the SDK, to create a simple app and publish it on Android Market. There are no expenses for the tools, but it will cost $25 as an initial fee to sign up as a publisher for the Android Market. I guess this fee is meant as a kind of spam-protection and also makes it possible to trace your identity, if needed.

Bullshit Bingo for programming

A Bullshit Bingo card for software developers:

Remember the rules, you need 5 in a row before you win!