The behavior of the Android Telephony/Signal APIs which OpenSignal depends on varies widely across phones. Many Samsung phones don't implement these well at all, bummer considering they are very popular handsets.
One of the things that makes Mobile development interesting to me is the mobile context, unlike the static context of desktop computing. But being smart in the mobile context requires using sensors, and this hardware boundary is where we see a lot of behavioral differences among Android phones (fragmentation). The existing CTS doesn't do a good enough job here. Its where the fragmentation is the worst - in the interesting APIs.
Also, the fragmentation problem for me is also about Google being able to deliver features to users at a reasonable speed. They can with the Nexus, but the Nexus was and is not likely to ever be a commercial success. Its mainly HW for the Google engineers to dev on, and they make a few more for us.
Bluetooth low energy was announced in 4.3. How long will it take for that feature to arrive for a sizable number of users?
What about the limitations of dvm? For example, its 65k method limit for APKs. How can Google fix this when they can't get everybody on the same page in a reasonable amount of time? Its this kind of fragmentation that hurts.
If you're building some basic CRUD app, don't worry. If you want to make interesting nontrivial apps that touch many APIS - especially HW APIS, that when you have to watch out - and have a very good testing plan.
I have had a few interesting problems with Samsung handsets over the past year as well. A couple examples I've observed:
* Samsung S3/Note2 - requestSingleLocationUpdate() would never return a location to the listener, where starting the location listener and then stopping it when you get your first result works fine...
* Samsung S3 (4.0.4) - onResume() then onPause() was being called repeatedly after the device blanked the screen (the time varies before it starts freaking out and calling onResume) - I observed it wait 7 minutes, then start calling onResume/onPause a few times per minute.
I think several big selling phones had Bluetooth BLE before it was baked into the platform, so it really depends on what you mean by sizable number of users. The fact that it's hardware dependant too, somewhat limits the adoption.
Comments
The behavior of the Android Telephony/Signal APIs which OpenSignal depends on varies widely across phones. Many Samsung phones don't implement these well at all, bummer considering they are very popular handsets.
One of the things that makes Mobile development interesting to me is the mobile context, unlike the static context of desktop computing. But being smart in the mobile context requires using sensors, and this hardware boundary is where we see a lot of behavioral differences among Android phones (fragmentation). The existing CTS doesn't do a good enough job here. Its where the fragmentation is the worst - in the interesting APIs.
Also, the fragmentation problem for me is also about Google being able to deliver features to users at a reasonable speed. They can with the Nexus, but the Nexus was and is not likely to ever be a commercial success. Its mainly HW for the Google engineers to dev on, and they make a few more for us.
Bluetooth low energy was announced in 4.3. How long will it take for that feature to arrive for a sizable number of users?
What about the limitations of dvm? For example, its 65k method limit for APKs. How can Google fix this when they can't get everybody on the same page in a reasonable amount of time? Its this kind of fragmentation that hurts.
If you're building some basic CRUD app, don't worry. If you want to make interesting nontrivial apps that touch many APIS - especially HW APIS, that when you have to watch out - and have a very good testing plan.
I have had a few interesting problems with Samsung handsets over the past year as well. A couple examples I've observed:
* Samsung S3/Note2 - requestSingleLocationUpdate() would never return a location to the listener, where starting the location listener and then stopping it when you get your first result works fine...
* Samsung S3 (4.0.4) - onResume() then onPause() was being called repeatedly after the device blanked the screen (the time varies before it starts freaking out and calling onResume) - I observed it wait 7 minutes, then start calling onResume/onPause a few times per minute.
edit: formatting
I think several big selling phones had Bluetooth BLE before it was baked into the platform, so it really depends on what you mean by sizable number of users. The fact that it's hardware dependant too, somewhat limits the adoption.
They were advertised, but only the S4 and Note2 had BLE that came close to working...
though "Close to working" is as good as I can say for my wife's Note2... it was extremely flakey and loses connection all the time.