Fragmentation of smart TVs. Really? Part 1/2
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
- Language (Java, C#, Objective-C, C++), frameworks, and development tools
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.