While the transition from desktop/laptop to smartphone in the post-PC age is still ongoing for lots of people, yet another technological advancement is slowly making its way into our lives: wearable technology. Currently, lots of various wearables have actually entered the market and the opportunities for users and tech firms are starting to pervade continuously.


Key Learnings

Similarity with the portable market: Fundamentally, wearables that exist today are not technically various from portable devices. In reality, a number of the technological challenges they deal with are similar, however are just more popular on wearables: battery life, smaller sized screen size, less computing power, and so on
Similarity in between wearables: The primary commonness between wearables– and what identifies them from handhelds– is how we are supposed to use them, which issues of their kind aspect. Indeed, wearables lend themselves for much quicker interactions and for providing “glance-able,” more condensed information to the user. In our technology review, we found that manufacturers have actually created wearable os using this main presumption, which discusses the similarity in between the wearable devices.
Importance of prototyping: At this stage, prototyping is vital to test new concepts and check out real-life use cases. We have found that some platforms are not as well-suited for rapid iterating. More on that below.
Fragmentation: The primary obstacle for wearable app developers is software fragmentation. There are various operating systems (with no clear winner yet), and there are no options for cross-platform development presently available.


Commonality: Notifications

The very first resemblance between the various wearable platforms is the dominant placement of alerts coming from the portable. Alerts are also the simplest way to include wearable functionality to an existing app, since this leverages the notification system of the handheld device.

With Wear and a handheld Android 4.3, the os instantly sends out notifications to the watch, with optional wearable-specific rich notification parameters such as voice input for actions and additional pages to offer added information.

With Pebble, any app using the handheld system alerts will see the alerts also displayed on the watch. On Android, a Pebble application is required on the handheld; on iOS no application is needed on the portable, since any third-party device can use the Bluetooth Low Energy Apple Notification Center to subscribe to the system notices.

With the Sony SmartWatch, an application on the handheld is also required to capture notifications coming from other apps and show them on the watch.


Commonality: Hardware Capabilities

A vital restraint for wearable apps is the wearable hardware capabilities, which are constrained by the form factor.

Screen types: Wearables have various screen sizes, numerous screen shapes (Android Wear supports round or squared screens) and even different screen types (the Pebble has an e-paper screen and the Qualcomm Toq uses the Mirasol technology to allow an always-on display screen). These different screens require the user experience to be adjusted for each device type. The case of Pebble is even more dramatic given that a completely adapted UI should be created to the black and white screen.
Readily available sensing units: While handhelds have a conventional set of sensing units, wearables vary considerably in terms of what on-board sensing units they have. Some applications that rely on certain sensing units will have to either give up devices that don’t support it, or discover an alternative to that sensor data.
Battery life: Because of size, battery life on wearables is really limited, even on devices with always-on screens, like the Pebble, that typically have a longer battery life. Wear and the Sony SmartWatch provide a low-power mode where the screen dims and less activity is performed on the watch, and applications need to be established with this mode in mind.


Commonality: Application Architecture

The architecture of a common wearable application has been directed by these hardware constraints, and specifically by battery life concerns. It works to position wearable apps along a spectrum of “self-reliance from the portable,” going from standalone apps to extensions of a handheld app, to differentiate the architectural techniques of the applications. On one hand, standalone apps live entirely on the device and do not require a buddy portable application. They usually (however not specifically) take the type of custom watch faces. It is vital to note that custom watch faces on the Sony SmartWatch do not run totally on the device and are therefore not standalone. On the other hand, extensions on a portable application have various architectures depending upon the device:

  • The Sony SmartWatch app code mostly lives on the portable, and just the layout code is transferred to the watch.
  • The Pebble and Wear apps survive the device and are in that regard standalone, except that the heavy lifting (such as asking for a resource from the Internet) is performed on the portable and transmitted to the phone.

In both of these methods, the battery is maintained on the wearable and the portable’s computing power, and simple access to the web is leveraged.


The very best Platforms for Prototyping

It is important that developers can quickly test their concepts to obtain a better feel for the actual user experience. For that reason, the much easier it is to prototype on a specific platform, the much faster the platform will develop. In reality, the easiest platform to prototype on will likely figure out which platforms the prototypes are constructed on specifically.

Amongst the factors that affect the prototyping speed on a platform that we have actually recognized:

  • Programming language: For developing standalone apps, the programming language does not have a significant impact on the ease of prototyping. Nevertheless, for prototyping an extension to a portable app, having a single programming language for both the wearable and the portable devices has a substantial effect on development. The Wear and Sony SmartWatches are both running Android, which implies that wearable apps and their portable counterparts are both composed in Java. However, the Pebble apps are coded in C, while the handheld equivalents are coded in either JavaScript for cross-platform development (that is, cross-handheld-platform), Objective-C/Swift on iOS, or Java for Android. Platforms like the Pebble make it much harder to develop both sides of the app because even the domain code, which is most likely to stay the same, can not be shared.
  • Emulation: While it is crucial to test on the device, having an emulator assists during the initial actions of development. Of the 3 platforms that we reviewed, just Wear has a standalone emulator for development devices.
  • Reduce of uploading the app to the wearable: This is an essential action throughout rapid prototyping since this operation is repeated extremely frequently. All three platforms have great systems for uploading the application to the wearable.


Cross-Platform Development and Fragmentation

At the minute, it’s really hard to say how numerous wearable platforms will share the market when everything has actually settled down. However, if the situation resembles today’s, the fragmentation in this space will be really high. While developing natively for iOS, Android, and Windows is really frequently undertaken in the portable market, it is not likely to be sustainable to develop for all wearable platforms natively if the existing fragmentation stays. Cross-platform development for wearables would for that reason be really beneficial, even more so than for handheld platforms. Nevertheless, there are numerous constraints that presently make it difficult to imagine efficient cross-platform development:

  • Lots of wearable platforms, consisting of the 3 we evaluated, do not include an internet browser engine, which is the basis of lots of cross-platform development tools for handhelds. This will probably force cross-platform tools to use cross-compiling.
  • Design concepts vary substantially between platforms. They will probably converge in the long-term, but a one-size-fits-all model might not be perfect at the minute.
  • The APIs of each wearable os are considerably various, which will complex the job of porting.



Wearables are at their early stage, and it shows in the tools readily available for development. As we have gone over, the simplicity of use for prototyping differs between platforms, and we hope that these tools will enhance in the future, especially for platforms such as the Pebble, which are falling behind because regard. We also intend to see some cross-platform development tools emerge, however in the meantime, we can rely on the open-source community to offer tools and sample code to accelerate the development for each platform, such as the Salesforce Wear collection of starter apps. Lastly, we are excited to see how the marketplace will settle, especially with power-players like Apple, which has yet to go into the wearables market.


Source: Digital For Real Life