by Peter Hauser
@Kenneth - we are currently working to resolve this issue and encourage all to put requests in to Apple via their enhancement request system to provide a method for obtaining the presence of an unread SMS via public APIs.
A quick question on the IOS app & associated libraries :
How do you plan to provide sms notifications via the libraries ? As far as I know no app has access to SMS notifications using public apis. Any attempt to find a workaround using private apis will simply result in Apple banning your app.
@loannis - I agree that the same care should be taken whether it be an internal or external API. My comment had more to do with the level of documentation and support infrastructure surrounding the API, and when the investment should be made for such documentation. Thanks for your comments though and I hope you'll join the ranks of developers building apps that interact with the COOKOO™ watch and other ConnecteDevice products.
I disagree with your comments regarding the API. Whether it's for internal or external consumption only, the same (high) level of care should be taken, unless off course you enjoy Murderous Developers Who Know Where You Live (http://c2.com/cgi/wiki…). Therefore, if you take good care of your API, who ends up using it becomes a moot point.
I appreciate your points about the Pebble watch API - but let's not compare apples and oranges.
My understanding is that the Pebble watch API lets you develop applications that run on the Pebble watch's hardware (e.g. OS running on the Pebble watch).
The cookoo™ watch's Bluetooth SMART technology communicates with iPhone and Android OS devices via Bluetooth 4.0 Low Energy. It uses a proprietary protocol to do so, and a Bluetooth Low Energy app on the mobile device.
The cookoo™ watch APIs abstract all of this so that you can develop your applications and simply "communicate" with the cookoo™ watch without having to understand the complexities of the Bluetooth Low Energy technology or link. We've done that hard work for you.
Alexis - regarding the API and whether it needs to be written anyway - the answer is yes and no. Developing an API for internal consumption vs. external consumption (e.g. so that it can be published to 3rd parties) require two different levels of involvement and investment.
We want to build a thriving developer community by supporting it and extending functionality for 3rd parties, creating a developer portal so that developers can share ideas, etc. and providing quick turn-around support to developer questions.
This is not possible without the developer community's support and why we are reaching-out to Kickstarters for additional funding to support it.
As a software engineer, I don't understand why we should need to drop $200 to develop on this watch. I understand that support costs money, but the actual API itself? Doesn't that need to be written anyway?
Open-Source is the wave of the future. Lets be fair the watch will only work with very new or up and coming phones. Someone like me rocking a Droid Incredible from two years ago is only going to enjoy a new watch until I can find a new phone I like and that has BT4.0. Hopefully by the time this watch is released I can get my hands on a newer Google Nexus phone.
I feel the same, the Pebble watch API was open to all, just later than others who purchased the "Developer Special".
IMHO dev libs should be open to all, not just open to the ones who can drop $200. Shutting out a lot of devs because of the size of their wallet strikes me a little myopic.