Closed RingoMckraken closed 9 years ago
Thanks for a constructive feedback @RingoMckraken. We strive to have SDK as simple as possible. It is doing only ranging, monitoring for our devices and their configuration. It'd like to ask you more questions.
Documentation. So far we have verbose SDK Demos along with section how to use it. We had recognised that we can do better and we introduced Estimote Developer site where we put tutorials. Android one soon. Can you tell me more what do you expect when you did say "detail documentation"?
Holo theme point taken. But what do you mean that we do not adhere modern Android practices?
As a author of this SDK, I'm interested why you had said that Android support is an afterthought. Estimote is fully committed to Android.
Regarding Android Beacon Library. Estimote beacons are iBeacon compatible and if this library can handle iBeacons than you can use it. We cannot provide any more details about iBeacon as it is Apple's proprietary protocol.
First I'd like to thank you for such a concise and friendly response. That speaks volumes for Estimote's commitment to the development community at large. Second I'd like to apologize for my tone in the issue raised on this repo, I'm a hardcore android guy in a world of iOS first so I definitely think we feel each other's pain on the need to uphold the standards and best practices of the platform(s) we have to support.
To further elaborate and address your questions, and this is something all android dev's (foot in mouth) struggle with, is the lightning pace that this tech evolves. I/O this year unleashed a plethora of updates and support libraries with much welcome to the community, although not completely encompassed in the native documentation, these practices continue to evolve to become the de-facto standard for "how it's done". The tools we use on a daily basis and the native sdk's we use are a direct reflection of that, constant updates that force developers to look around the corner to see what production code could be affected and what level of refactoring will have to take place to accommodate the changes for an ever diverse user base with differing hardware specs, os versions, custom OEM forks, etc.
What I mean specifically by documentation is the on boarding experience itself. Say you are a code shop that has a handful of devs on both sides of the fence. This shop gets a BLE beacon related project for a critically acclaimed client. One side gets a clean paint by numbers step by step (and I may just have a hard time finding these docs) guide on the meat and potatoes of integrating the tech into their production code(albeit proprietary), while the other gets a link to github repo a small readme, and is left to stack overflow / the web (not to say that's a bad thing, and yes that is a bit of a dramatic stretch). The one side get's their code written quick as wind and is off running to the races. Meanwhile, the other is backwards configuring their environment, build system, and "the latest and greatest" to make it work (on a platform where 45% of the target market won't even be able to use it,) and has to explain why they spent a little more time to get their code to work. This is the plight of a lot of developers out that and we are scrambling to just get it to work so we can implement application logic and fine tune the code to not crash on a myriad of devices.
Thank you again for responding and listening to the community. At the end of the day, I'd love to see a million giving constructive feedback and vice versa to help you guys and the community at large support every platform available in the market. Look at the competition and help us do that. We got your back and will support you.
Prop to you and those who developed the sdk, for realz!
@RingoMckraken Just to reassure you. We are working on generic getting started with beacons guide. What it is, what concepts are behind it etc. In addition to that we will have getting started in Android & iOS guides.
I get that your sdk is "closed" for whatever reasons deemed applicable, but at the very least can there be some detail documentation / tuts (that use modern android practices, Holo theme is 4 years old, you can do better than that.) like the iOS sdk has? After digging through the archive files and de-compiling the classes.jar file it becomes immediately apparent that the android support is an afterthought.
On your community portal there is mention that Estimote beacons can be monitored via the open source Android Beacon Library from Radius networks, yet there is very little information on how to set the beacons layout paremeter for monitoring.
Sorry for sounding like a complainer but a tech that is this pervasive and powerful needs support across the board, it can only bring more success to everyone at the end of the day.