Fragmentation of smart TVs. Really? Part 1/2

06. May 2013

One of the topics discussed recently is the fragmentation of development environments and application interfaces of smart TVs, and the attempt to solve it. Let’s ask a question, isn’t this a battle against something that is quite natural (everyone wants to be different) and doesn’t it make this unifying effort a somewhat quixotic battle.

Before we get to TVs, let’s look inside the world of mobile applications in the first part of our talk, for the sake of comparison and better understanding of the fragmentation itself. Mobile development – today it primarily means iOS and Android operating systems. Two incompatible worlds of applications, which are incompatible not only at the level of source code (Objective-C vs. Java), but also in terms of design. The time when the appearance of applications on Android imitated the interface of existing iOS applications is gone. In the world of Android, especially with the advent of version 4.x and holo design, there is a rise in autonomous and interesting design of applications (see for example), completely different from “the apple” in terms of appearance. If we look at other platforms we find more differences: On Windows 8 and Windows Phone 8 it’s the world of .NET, XNA and Metro design, on the new BlackBerry it’s C++ and Qt. In other words the area of application development on mobile phones is a world of fragmentation on the level of:

  • Supported technologies
  • Approval of applications

Conclusion? The mobile world is simply diverse. There certainly had been and still are efforts to unify these environments, they tried C#, BB10 allows running Android applications, Adobe tried to push ActionScript. But it all ended in failure, or these technologies barely survive on the edge of the developer community. Of these directions only HTML/CSS/JavaScript have any hope in the future. But not in the present. Anyone who saw just a little more complex application in PhoneGap crawling even on Galaxy SIII will probably agree with me. One of the reasons is, that to write a fast, high quality and complex application for phones in JavaScript is not easy and it requires experienced professionals, and writing the same thing natively can be managed by a less experienced developer. It is very hard to cut costs (the main argument of the cross-platform approach) here – especially when it comes to maintenance or need to utilize native features of the phone. Another important fact is that a cell phone application developed for more platforms usually has negative consequences for its users: It’s typically (but not necessarily) slower than native applications, it does not allow full utilization of all features of the given platform, because it works only with a set of functions common for all platforms and has a unified graphical interface that does not respect the peculiarities and unique requirements of mobile operating systems. You may find other types of fragmentation and differences, or you may have another view of these differences – be sure to write us about it. Next time we’ll look at the situation with smart TVs.

  • Language (Java, C#, Objective-C, C++), frameworks, and development tools
  • Design

What compactness and backward compatibility can be found within various platforms? Android developers know that the worst thing is its internal fragmentation, i.e. differences between versions of the operating system. At the present it is perhaps a receding trend, however let’s wait for the release of Key Lime before drawing any conclusions. There’s also the fragmentation resulting from the number of resolutions, rotation support and additional features (e.g. QWERTY keyboards, NFC) and then also fragmentation originating from manufacturer errors, size of available memory of the device and its performance, problems with video players, and so on. This results in complaints of customers who still have Froyo on their phone, or comments on Google Play denouncing developers for speed of application on a Chinese tablet, complaining about out-of-memory error when processing larger XML. It’s also not true that the closed system of Apple guarantees consistency – an application written for iOS 4 will probably have some problems on iOS 6 and vice versa, the same applies to resolution and screen size and especially memory performance on iPad 1. Similarly, writing an application for WP7, WP8 and Windows 8 requires good application design and significant effort especially during testing. Conclusion? Again, certain fragmentation and necessity to test on the level of:

  • Operation system version
  • Phone manufacturer
  • Phone features Resolution and screen size
  • Tablet and phone support

Furthermore there is a technological fragmentation. It relates to supported DRM, codecs, streaming protocols, options of private data security on the server level, running applications in the background, methods of server notifications, possibilities of payments on the phone, etc. To prepare a multi-platform system today means the necessity to support more technologies on the server side, which may be the highest costs of project implementation by far… It should be also noted that the procedures and requirements for approval of applications are fragmented as well. What is without problems on Google Play, due to the absence of any input filter, it may not pass approval at Apple or Microsoft.

Free OTT insights in your inbox