Development
The Tizen SDK for wearable devices
One of the more entertaining aspects of the 2014 Tizen Developer Conference (TDC) was the opportunity to explore applications written for "wearable" devices. These days, the term "wearable" is often code for "smartwatch"—although as Google Glass shows, other classes of hardware device are certainly possible. The first Tizen-based smartwatch to reach the market is Samsung's Gear 2 series, which is supported by a special version of the project's SDK. Between the SDK and the wearable-devices track at the conference, it is now possible to see what device manufacturers have in mind for smartwatch software development. The focus is primarily on tethering to other devices (starting with smartphones and tablets), but there is also a framework in place for standalone apps—a prospect that probably makes executives in the "health tracker" industry break into a cold sweat.
The SDK
The Tizen SDK for Wearable was first released in beta form in March; the most recent update landed on April 22. As with the other Tizen SDKs, the integrated development environment (IDE) is based on Eclipse, bundled with the appropriate Tizen templates, frameworks, emulator targets, and documentation. While the SDK does include support for the APIs defined in the official Tizen Wearable device profile, developing apps for the Gear 2 smartwatch requires an additional step: installing Samsung's Mobile SDK. It includes the component needed for developing the Android side of apps that tether the Gear 2 to a smartphone or tablet.
As one would expect, the Tizen SDK is cross-platform, although the only officially supported Linux options are relatively old Ubuntu releases (12.04 and 12.10). The IDE is also a bit picky about Java releases, preferring Oracle's Java 6, and may require some additional tweaking on newer Ubuntu releases. The licensing of the SDK can also present some issues; it is based primarily on Eclipse (as mentioned above), but it also bundles in several proprietary components from Samsung. The complications that result for free-software developers have been raised in the past, so far without much in the way of resolution.
The SDK also includes a suite of sample applications to experiment with, either in the built-in device emulator or on a USB-connected smartwatch. Tizen's wearable apps are entirely HTML5—while the other device profiles include native app frameworks, too, the assumption seems to be that resource constraints of smartwatch hardware make HTML5 the only viable option.
At this point, the Tizen Wearable profile uses the WebKit-based web runtime engine that shipped with the most recent Tizen release, version 2.2. Interestingly enough, at TDC, there were several sessions devoted to rolling out a new web runtime called Crosswalk, that is based largely on Google's Blink with several additions pulled in from other projects. The Tizen 3.0 release scheduled for later this year will include the shift to Crosswalk; how this will affect the SDK for wearables is not clear.
Wearable devices in Tizen support a rather limited subset of the same HTML5 APIs found in the project's mobile device profile. For example, from the W3C Device APIs (a set that encompasses quite a few interfaces), only the Touch Events, DeviceOrientation, Battery Status, and Vibration APIs are supported. Multimedia support includes both audio and video, and, notably, includes media input via getUserMedia (in order to support smartwatch cameras, which some Gear 2models include). In addition, there are a number of Tizen-specific APIs available, covering alarms, filesystem access, time and time-zone information, and multimedia content discovery.
The Tizen project has always maintained that original APIs like these are mere placeholders, and will be replaced with W3C-approved APIs when and if applicable standard APIs are developed. What is a bit less clear is whether that same stance applies to some of the Samsung-specific APIs offered on the Gear 2.
At the moment there are three such APIs: one covering motion-sensing data (e.g., for pedometer usage), one covering infrared transmitters (to support the Gear 2's IR LED, which is used by several TV remote-control apps), and the Samsung Accessory Protocol (SAP). For practical purposes, SAP is the most noteworthy of the three, since it encapsulates how the Gear 2 watch communicates with a tethered mobile device. The connection between the devices is run over Bluetooth, but, it should be noted, SAP is not a standard Bluetooth profile.
Wearable app styles
On the second day of TDC, a session delivered by Samsung's Piotr Karny and Konrad Lipner explored the basic SAP functionality and the general landscape of Gear 2 app development. In essence, Samsung has defined three distinct classes of wearable app: Linked, Integrated, and Standalone. The Linked and Integrated classes are the two variations of tethered app, designed to work in concert with a smartphone.
A Linked app, they explained, is one with a component that runs on the tethered smartphone and a component that runs on the smartwatch, but in which the watch side of the app merely relays information from the phone side. A simple example would be a missed-call or SMS log: the calls and messages go to the phone, but the information is relayed to the watch for convenience's sake—without the watch, the phone continues to function. In an Integrated app, by contrast, the phone and watch sides are both required. Examples include most of the fitness-monitoring apps, which leverage the motion and heart-rate sensors in the watch; without them, the phone app does not function.
But Samsung is also supporting Standalone apps, which run only on the watch. In fact, there are several standalone apps available from Samsung itself: a calendar, calculator, even a music player. Naturally, the limited processing power of a smartwatch restricts what can be expected of a standalone app. Karny and Lipner noted that several of the Samsung-specific APIs found in the Gear 2 were created to fill in for pieces missing from the relevant W3C standards. For example, the Gear 2's camera supports autofocus, which can be accessed through the autoFocus() method of the CameraControl object.
SAP, they explained, is designed specifically for data connections between tethered apps. It operates over Bluetooth 4.0 Low Energy, and provides a fixed set of services: pop-up style notifications, alarms, calendar events, file transfer, music playback, and "context" management (which covers the device's motion and position sensors).
The Gear 2 also introduces its own user interface framework for apps, named the Tizen Advanced UI (or TAU) framework. The speakers explained that it was designed from scratch to fit the specific needs of smartwatch apps, most notably fast start-up time and usability on the significantly smaller screen size of a watch. On a desktop system, they said, users will forgive a three-second startup time, but on a watch, that same amount of time becomes unbearable. TAU attempts to optimize startup performance by pre-building as many HTML widgets as possible when the app is built in the IDE; the result is a larger HTML5 app package (and one filled with auto-generated <id> and <div> elements), but it starts up much faster than a smartphone app that builds the UI at launch time. They also commented that although TAU was designed initially for small, low-resolution displays on smartwatches, it will be usable on other device profiles, too, including the company's forthcoming line of Tizen-powered TVs.
The Gear 2 is, ultimately, a Samsung product, and one should be careful not to generalize too much about Tizen's wearable device profile from it. For instance, other device makers may opt to skip SAP entirely and offer a more general-purpose Bluetooth API. Nevertheless, the Gear 2 is a real-world product already in the hands (or, if one prefers, on the wrists) of consumers all over the world. As such, it is interesting to note how the three classes of app break down.
Is the fact that most fitness apps require tethering to a smartphone, for example, simply an artifact of the app vendors' desire to have a presence on every device a person owns? Samsung offers a standalone music-player app for the Gear 2, and recording pedometer and heart-rate data is certainly less intensive than audio playback. Once the smartwatch app marketplace breaks open in a big way, vendors that insist on requiring both devices to be present and running may find themselves at a competitive disadvantage. It is also interesting to note what ideas the smartwatch app developers have come up with so far. Most duplicate functionality already found in smartphone apps (which is not surprising), offering the slight increase in convenience of finding the information on one's wristwatch rather than in one's pocket.
On the other hand, there is already a wealth of fitness-related apps that leverage the built-in sensors of a wearable device. If smartwatch prices fall to reasonable levels, that would seem to put the squeeze on vendors who sell standalone fitness trackers like the Fitbit, most of which already require tethering to a phone or connecting to a computer with USB. Fundamentally, of course, the smartwatch is just another generic computing device: here at the beginning stages of its popularity there is a lot of differentiation to be found versus smartphones and other platforms, but surely one day there will be terminal emulators and web servers available for installation as well. Tizen for Wearable, at least, is a nice on-ramp to development for that platform.
[The author would like to thank the Tizen Association for travel assistance to attend TDC 2014.]
Brief items
Quotes of the week
This should not be an issue – the "JavaScript not available" use case is a very small one and mostly by users who either had JavaScript turned off by their sysadmins or people who prefer the web without it.
The "JavaScript caused an error" use case, on the other hand, is very much alive and will probably never go away. So many things can go wrong, from resources not being available, to network timeouts, mobile providers and proxies messing with your JavaScript up to simple syntax errors because of wrong HTTP headers. In essence, we are relying on a technology that is much less reliable than XML was and we feel very clever doing so.
How about just signing keys with people you would actually say you know well enough to trust? It's not the Web of Amateur ID Checking.
Docker 1.0 released
Version 1.0 of the Docker application containerization system has been announced. It includes a number of new features; it is also the first version that the developers are willing to put forward as being production-ready. "Second, this milestone signifies Docker’s coming into its own as an open platform for distribution apps. In particular, the community’s use of Docker in such a wide variety of use-cases and apps in every phase of the application lifecycle confirms this. So from today you’ll hear us talk about Docker as a platform, its components being Docker Engine, the container runtime and packaging tool, and Docker Hub, a cloud-based service for collaboration, content, and workflow automation."
Firefox 30 released
Firefox 30 is available. This version enables faster access to social, bookmark, and history sidebars, support for GStreamer 1.0, and an array of enhancements and bug fixes. More details can be found in the release notes.Nettle-3.0 available
Version 3.0 of the GNU Nettle cryptographic library has been released. This is a major update, incorporating several interface changes that break ABI compatibility with older releases. New interfaces are provided for DSA, AES, and Camellia, providing access to several new parameters and structures. All users are encouraged to study the new release carefully, as "there may be some problems in the new interfaces and new features which really need incompatible fixes. It is likely that there will be an update in the form of a 3.1 release in the not too distant future, with small but incompatible changes, and if that happens, bugfix-only releases 3.0.x are unlikely.
"
Prodromou: The future of pump.io
Pump.io and StatusNet creator Evan Prodromou writes
about the future of pump.io development. Since Prodromou is no longer working full-time on pump.io, the pace of development has slowed, but he has recently been working on reducing the administrative overhead needed for the public pump.io servers, which will ultimately leave more time for coding. "
Over the next week, I'm going to take the current state of pump.io and release it as version 0.3 and start the 0.4 development, he says. "
In the same time, I'm going to deal with the long list of pull requests and open issues with pump.io. The PRs will either get a reply, get pulled to 0.4, or closed.
" A 0.4 release could arrive as soon as September.
Newsletters and articles
Development newsletters from the past week
- What's cooking in git.git (June 6)
- What's cooking in git.git (June 10)
- LLVM Weekly (June 9)
- OCaml Weekly News (June 10)
- OpenStack Community Weekly Newsletter (June 6)
- Perl Weekly (June 9)
- PostgreSQL Weekly News (June 8)
- Python Weekly (June 5)
- Ruby Weekly (June 5)
- This Week in Rust (June 10)
- Tor Weekly News (June 11)
Libre Graphics World: Natron 0.92 released with new roto and keying nodes
Libre Graphics World has an interview with Alexandre Gauthier (the developer behind the open-source video compositor Natron) as well as an overview of the most recent release. Gauthier addresses the at times controversial decision to build an interface similar to that of proprietary applications that also support the OpenFX plugin standard: "when you implement an application which will be used by professionals who potentially have a lot of background in the usage of such software, you want to make sure you don't break all their habits, otherwise they won't bother. When you have an entire keyboard layout in mind and you need to switch to another, this is a lot of pain. When you have to spend afternoons just to find how to configure the same plug-in but on another application this can be very frustrating.
" Among other topics, the interview also delves into the complex history behind Natron and other OpenFX applications.
Day: Notify me
On his blog, GNOME contributor Allan Day writes about a redesign of the GNOME 3 notification mechanisms. It includes a new Message Tray design as well as reworking the lock-screen notifications and the notification banners themselves. "The final goal is one that was at the core of the original design, and which is central to the design of GNOME 3 as a whole: that is, to be noticable and useful without being distracting. Wherever possible with GNOME 3, we have tried to produce a distraction-free experience which helps you concentrate on the task in hand. This requires a fine balancing act, which can be tricky to get right. With the new designs, we want to change that balance slightly, by making notifications a bit more noticable and by providing more effective reminders, but we still want to retain the emphasis on avoiding distraction."
Page editor: Nathan Willis
Next page:
Announcements>>
