In the previous SDK, the standard pattern for a watch-app often required a smartphone specific app running on the smartphone e.g. for doing HTTP calls, getting location etc. This makes the development process more complicated because apps have to be developed for multiple platforms (e.g. android, IOS). Furthermore the release of applications may be slowed down by the acceptance procedure of Apple.
I think the Pebble team made a great improvement with the addition of this feature. It will dramatically lower development speed, and thus enable better, and more feature rich watch apps for the Pebble. In the end I would expect that features like this lower the entry level for Pebble watch app development.
Recently I published my experiments with a watch app, which keeps track of lap times, for ice skating. The watchapp works with the transponder based service from MYLAPS. A new laptime is recorded and published on the MYLAPS website each time the finish line is passed. The idea is that the laptime is grabbed from the MYLAPS website and presented on the Pebble so that direct feedback on achieved skating performance is achieved.
With the previous SDK, the structure of the application would look something like plotted below. The dedicated app on the smartphone requests data from the MYLAPS website, does some screen scraping, to extra the laptime data and pushes data to the Pebble (number of laps, last laptime, average laptime, fastest laptime, etc.). I never built the app, but in android terms it should be something like a background service coupled to a configuration activity.
This change in the SDK makes me hungry for more features.
- Support for websockets. I tested socket.io, and it works, but seems to fall back to long-polling instead of websockets.