• User experience perfectly adapted to the phone (e.g. touchscreen interaction)
• Direct access to device “periphery”, e.g. gyroscopic sensor
• Integration with other software, e.g. messaging, contacts
• Own, colorful app icon

Naturally, most apps do not in fact replace Web applications, they rather augment them with another means of interaction (e.g. think of all the social network apps, news and information apps, etc., that contact their respective “mother sites” using dedicated APIs). Nevertheless, the increasing proliferation of app-enabled smartphones means that apps will increasingly be considered a required means of interaction for Web applications. This will naturally have quite an impact on the mid-term development of the software and software development landscape, particularly with respect to those services that are currently being offered primarily as free (and most probably ad-financed) Web applications. In the remainder of this article, I will discuss some aspects of these changes, and highlight their positive as well as negative potential consequences.

Service monetization

First and foremost, I will discuss one of the most important and positive aspects of apps: Due to the ease of use of the respective app stores, apps have made it easy to monetize services. Most classic Web applications are offered free of charge, and monetize primarily using advertising. This, however, has many drawbacks: Users develop advertisement blindness, block advertising completely, and more often than not advertising also impedes the user experience of Web applications – be it in terms of the visual appereance, or even getting in the way of the user wanting to use the application (think layer apps, or Flash ads with sound effects).

In contrast, lots of apps are offered for a relatively little charge around 1$, which is easily payable by the user through the app store, and because all applications carry a price tag (even if it sometimes says “free”), it makes it more acceptable for the user to pay for receiving a service. Even though today there are means to charge small amounts to users also in more classic Web applications (think premium SMS messages, PayPal, etc.), it simply doesn’t feel natural to pay for something on the Web without getting physical goods in return (of course, I am exaggerating here, and there are numerous examples of virtual services and goods being sold for real money, but they mostly fall outside the basic service category I am looking at here).

Additional effort with limited differentation opportunities

Apps as one means of interaction with Internet based services are going to be increasingly considered a necessary part of the service itself. The more this is the case, the less will the existence of an app to access the service alone be a unique selling proposition (USP) for that service. Of course, an app with a well designed, intuitive interface can be a USP, but the same holds true for a well designed Web interface, so this argument is not app specific.

On the other hand, designing and developing apps to interface with an Internet based service requires additional effort, especially if the apps are to actually take into account the specialties of the device they are targeting (and a good Web developer/designer doesn’t necessarily make for a good app developer/designer). This is especially true if the competition offers their apps free of charge (as it is the case now e.g. for social networks), since then there is no way to generate additional revenue to cover the efforts involved in the app development – except ads, again.

Multitude of platforms

Another challenge that is developing is the increasing number of platforms for which an app concept exists. Apple’s iOS – powering iPhone, iPad and iPod touch – is still the most popular and relevant one, but other smartphone (OS) vendors have adopted their app platforms and stores as well: Google’s Android, Microsoft’s Windows Phone 7, RIM’s BlackBerry platform, Palm’s Web OS, Nokia’s OVI are only the most relevant, and this means a stunning number of six platforms with incompitable programming environments. Some progress has been made in this direction recently, e.g. Palm focusing on making it easy for developers to port their apps to Web OS. On the other hand, there is Apple as the most important player, whose app store terms effectively prohibit any software not originally developed in Apple’s C dialect Objective C, making it virtually impossible to easily port any app to iOS.

A way out of this dilemma would be to increase standardisation of smartphone app development platforms. There are multiple possibilities for developing that kind of platform: One would be Java, which has a track record in both platform interoperability and mobile devices, or web technologies such as XML, HTML, and JavaScript, which are quite well known to a lot of developers and can already be used for app development on a number of platforms. Naturally, a standard smartphone app development platform would still have to be able to adapt to specialties of the device, but abstraction layers to accomplish this could probably be conceived relatively easily.

Share/Save

First and foremost: What I tried first was using the @PostConstruct annotation on a method that should be called after deployment – but that doesn’t work, because the EJB is not guaranteed to be instantiated directly after deployment. As a matter of fact, at least the JBoss I was using lazily instantiates the EJB the moment it is first invoked.

After a while, I came across this thread in Sun’s forum, in which a Sun developer states that better support for this use case is planned for a future EJB version, and currently the only way to achieve the desired effect is to rely on a ServletContextListener, which provides a contextInitialized() method that is called as soon as a servlet context is initialized. However, like the “servlet” implies, there needs to be a web application to use this listener – so I ended up adding a web application to my enterprise application with no content besides that context listener that would poke the EJB in order to get started. Now although this method is far from elegant, at least it works reliably and most possibly independent of the container used; at least I can verify its functionality on the JBoss 5 used in my test system.

Share/Save