Ask / Submit
68

Support for Wearable Computing Accessories

asked 2014-01-05 06:01:59 +0200

updated 2014-01-05 23:35:32 +0200

Of the things that I'd like to see with the development of SailfishOS - especially how Jolla has designed it such that at the setup screen that you can select what kinds of applications are present after setup - is the addition of a collection of APIs (and/or applications) which enable easy connectivity and management of various wearable computing accessories.

I see this support happening in two frames:

  • motion tracking
  • extended interfaces

Motion Tracking Devices

These devices include smartwatches (Pebble, Basis, Metawatch, etc.) and activity trackers (Fitbit, Polar Loop, etc.). The basic framework for this frame of reference would include:

  • Sending/receiving notification data from mobile to wearable
  • Storing motion, accelerometer, and status data from wearable to storage framework on the device that can be sent to a web service with nothing more than the device being authenticated to the service (this would obviously not as featured as a full app; leaving the door open for devs/companies to make a premium service option which may include a native app)
  • sending firmware updates to wearable

Extended Interfaces

This would include devices such as headsets, headphones, automobiles, keyboards, wireless projectors/monitors, etc. The basic framework for this frame would include:

  • managing the connection
  • giving basic "wand" capability to the mobile (wand: the mobile becomes a controller for the item its connected to)
  • enabling other applications to plug into these devices without the dev having to write all of the base functionality themselves; but leaving room for custom apps which might do a bit more, yet can be accessed/managed from a central interface

This kind of framework, something that would work like the Android Support package, would allow for SailfishOS to be marketed a bit easier to current wearable companies who'd see an option in SailfishOS devices, but probably have so far seen too much of a hurdle towards making something native that's of definitive value - against simply addressing compatibility by porting their current Android apps/services.

Allowing for this kind of centralized setup (account and device management inside of a sub-profile that's user manageable), allows for a focus of API compatibility on the side of SailfishOS, rather than application and service updates which take more time/resources.

Personally, I'd just like to see SailfishOS support the wearable device I own (a Polar Loop) but I realize that asking for supporting just one device is too short-term of thinking, and doesn't push the community forward. Asking for an entire framework that almost lives within itself, is where making SailfishOS and native apps/services on it most relevant.

Done well, its an evolution of the Accounts function on the N9 and the plugin-like abilities seen on FirefoxOS.

edit retag flag offensive close delete

Comments

For fitbit there is already galileo. It's python, so it should work. Shouldn't it?

NikosAlexandris ( 2014-03-21 06:03:22 +0200 )edit

It would be enough a proper Bluetooth working, so that proprietary Android apps, like MI FIT could connect to the respective wearable. (MI FIT is the Xiamomi app to handle the MI Bands.)

Actually I get a "no bluetooth 4.0" message on all SF OS XA2, even if the hardware is ready and working under Android.

Waiting for a new module or framework, I think that allow the access to apps working in the Android layers is the short term solution.

minojolla ( 2019-10-30 13:01:07 +0200 )edit

5 Answers

Sort by » oldest newest most voted
13

answered 2014-01-10 20:56:20 +0200

javispedro gravatar image

updated 2014-01-10 21:16:45 +0200

A few years ago I started a smaller scale project: Sowatch -- an attempt to build a generic framework for all kinds of smart watches. Yet, you'll find that even within smart watches, different models have gigantic differences. Thus, a truly generic framework is a lot of work.

At the end, Sowatch only supports two smartwatch models (which use the "dumb framebuffer" model, where the host device basically draws everything that appears on the watch's screen): Sony's Smartwatch/LiveView and the MetaWatch. And even then their interaction models are so different that Sowatch hardly "abstracts" any interface, other than just pushing QML-rendered pixels to the watch screen, managing the BT connection/scanning, and forwarding notifications. Note that out of these three interfaces, for example, the Pebble would only use two (notifications and BT connection). Other watches I've monitored are even weirder and act either as Hands-Free Profile devices, and thus, would use no interfaces at all from the above.

I'm not sure what a framework with an ever wider scope would actually "abstract". I feel that BT connection management alone is not worth it, as it's trivial to do with a proper BLE API. Most smartwatches or motion trackers do not transmit accelerometer coordinates in any sensible way because that'd kill the battery. Instead, they "mangle"/process the data in some model-specific way (e.g. you ran X miles), so abstracting that would also be hard. Same for firmware upgrades.

That said, there are some aspects that are starting to become standardized. For example, BLE. Thus, proper BLE support is mandatory for this request. Also, there are two competing standards for a Bluetooth "generic notifications proxy". There is one from the Bluetooth SIG, ANP, and one from Apple, ANCS. At least the MetaWatch and the Pebble seem to be moving towards supporting ANCS because it's the only one supported by Apple devices. That would provide for a way to forward notifications to smartwatches without any watch-specific Jolla "driver".

edit flag offensive delete publish link more

Comments

@javispedro - first let me say thank you for Sowatch. That was what made me run after getting a wearable that worked w/my N9 to begin with. And it was the inspiration behind this question.

Seeing the challenges involved, I don't think I'm asking for an easy solution, but you do point out challenges

arjwright ( 2014-01-12 18:04:43 +0200 )edit

@javispedro Thanks for Sowatch Hope we will see soon a port on our liked #Jolla! I really miss to see on my wrist how is calling :,(

Nokius ( 2014-01-16 22:36:10 +0200 )edit

Yes, thanks for sowatch! Here is hping that we might have a comparable solution on the Jolla soon.

tingo ( 2014-03-04 13:47:44 +0200 )edit

@javispedro I have the N9 and a Sony Smartwatch. I went to the link you gave for the Sowatch, but in the description: "currently only digital MetaWatch" is supported. Is there something special to do for the Sony Smartwatch, a different link?

cocof2001 ( 2014-05-04 12:40:31 +0200 )edit

@cocof2001 no. note that only sony's smartwatch1 works, and partially. try it.

javispedro ( 2014-05-06 13:29:29 +0200 )edit
4

answered 2014-01-05 23:43:14 +0200

I think that out of these notification is probably the most basic one, but as explained the topic is much wider.

Some other related items hanging around:

https://together.jolla.com/question/8589/proper-bluetooth-le-support/

https://together.jolla.com/question/317/allow-for-multiple-notification-destinations/

edit flag offensive delete publish link more

Comments

Notifications are indeed a low-hanging fruit. However, I've tossed a wearable from my usage because that's all it did. If the wearable is to speak towards smart contexts, then empowering it to do more is what a platform framework can do. Hope the discussion here helps that along for SailfishOS.

arjwright ( 2014-01-06 00:21:51 +0200 )edit

I really didn't know Intel's CES announcements were coming, but what can I say, I think they are thinking along the same lines I am with this idea. Jolla could get behind this easily IMO.

arjwright ( 2014-01-07 07:19:37 +0200 )edit
1

answered 2014-06-10 00:11:05 +0200

Given what Apple has pulled off in their recent iOS 8 Health/Healthkit announcement, I don't know that I was too far off in thinking it was possible to build something similar. But, I might have been further off in thinking that it was closer to happening as Apple seems to have been able to leverage lessons from partnerships, previous iPod models, etc.

That said, what stops SailfishOS from jumping into a similar framework, much like is what's happening with the Android support engine, making it possible not just for wearables, but allowing those folks/markets where this could be usable to take advantage of it. Plus, Apple would probably like the play from this end, makes them look like a closed agent on this wise.

edit flag offensive delete publish link more
0

answered 2014-04-29 00:51:36 +0200

This isn't really an answer as much as its a pointer to a discussion found talking about a Pebble implementation for SailfishOS (in development) called SkippingStones over at Talk.Maemo

edit flag offensive delete publish link more
0

answered 2019-10-28 11:28:09 +0200

It would be enough a proper Bluetooth working, so that proprietary Android apps, like MI FIT could connect to the respective wearable. (MI FIT is the Xiamomi app to handle the MI Bands.)

Actually I get a "no bluetooth 4.0" message on all SF OS XA2, even if the hardware is ready and working under Android.

Waiting for a new module or framework, I think that allow the access to apps working in the Android layers is the short term solution.

edit flag offensive delete publish link more

Comments

@minojolla, this is not an answer, but an comment. Hence please convert it to one!
Plus there is no reason to "shout" by using bold half-sentences (equivalent to COMPLETELY CAPITALISED ones).

olf ( 2019-10-28 15:33:37 +0200 )edit

garret. I didn't knew bold was aggressive :-/

minojolla ( 2019-10-30 13:00:54 +0200 )edit
Login/Signup to Answer

Question tools

Follow
10 followers

Stats

Asked: 2014-01-05 06:01:59 +0200

Seen: 3,015 times

Last updated: Oct 28