We Keep Coding

Android Ibeacon Indoor Location experiences

It's a few days i'm trying to build an app for indoor location of a user in to a room.
I'm using Estimote SDK . I had BAD results even if I tried many altrenatives.
I used, thrilateration, quadrilateration, some alhgoritms based on media and variance(made by myself) trying to reduce the noise...
I had unsatisfactories results (too wide fluctuations in very small range time) and i'm wondering if someone had any good experience in this kind of applications.
I know that results are good with IOS and I'm wondering if is it possible to replicate them in android system and if somone did...and could eventually help me.
Thanks,
Federico.

My personal opinion from experience I am building is that BLE beacons are not designed to easily provide location. They are only designed to provide "presence" ie. "you are near a point". And by near it means within a few metres, so that the signal is strong and you can be sure of being nearby. (Although I'm not convinced they are reliable even for that)
There are several companies that are doing trilateration or similar to get better accuracy out of multiple beacons, such as:
www.pointrlabs.com
indoo.rs
Estimote Indoor Location SDK
ensolocate.com
It seems from their publicity that they have this working. So it must be possible, but I suppose there is a lot of trial and error in getting practical algorithms, and a signal strength survey of the venue seems to be needed. I have not been able to find any unbiassed/independent review of these systems.

the fact is that ibeacon (i tried on ios with estimote earliest release) have RSSI no affidable. The fact is that you should not use it for detecting distance in meters but in "zones" like near, far, ecc

How to detect volume buttons when screen is off in energy-saving way

I would make an application that handle the volume buttons when screen is off. The goal would be to turn on or off the front LED.
I know that there many topics here that talk about it, but the recommended solutions (like PARTIAL_WAKE_LOCK) seem to be energy intensive and drain the battery very quickly!
What I want is a solution that is as energy efficient as possible. Is this possible? Maybe some kind of hooking?
Please note that the solutions based on scheduled tasks can not be envisaged for this project because I want detect keys in real time (or close to it)!

Take a look at this question.. if you already haven't ..
Just to make one thing clear. If something is not documented in API docs of android then any hack or workaround you find won't be reliable as Google may decide to change things in future releases, for example there is nothing documented about creating shortcuts after the app is installed ! But Since Android source code is available, developers took that piece of code as how was playstore creating shortcuts.. but its not documented so Google may change it in future !

Too many requests FirebaseError

I've come across this error with Firebase saying too many requests. I've read the nest api saying that they have limited the number of requests to avoid battery drainage on the device. But on the official nest android app you can switch on/off (changing to heating/off) the thermostat without an issue.
Any idea why this is limited in the developer api?

The API limits the number of requests to preserve battery life and it will also stop accepting requests completely if the battery level drops too low. Take a read through this page on the Nest API site about limitations.
I would expect if you keep flipping the on/off switch in the Android app, it would also quit working after a while. You can pull up the battery state and look at it, so maybe someone will determine what the upper/lower limit is?

I faced this issue with firebase firestore database while reading too much data at once. I don't know exact limit breach but it worked for around 1600 reads in Promise but didn't work for 26000.
So my solution was to divide the whole thing in buckets, make their Promise and then read and it worked.

How to detect low-spec mobile devices meaningfully?

Right now I only know about Scientiamobile's WURFL and a few others. Those libraries or databases tell you quite a lot of things about the device but none of them can clearly indicate that you shouldn't use CSS transitions or other sorts of animation because even if the device supports it, its a complete different story that those features will run smoothly and this is my major concern when building mobile web apps.
Is it technically possible to 'classify' devices in this direction, using the 'WURF' database ? And which device capabilities I should use to 'group' devices as 'fast' in terms of graphic power ?
Finally, I just need a rating of the device from 1-5 in order to decide which gfx operations I can use.
well, any thought is welcome. It turns out as real brainer and the researches on internet didn't bring up anything useful except lots of data about device caps.
Update-1 : I just got a response from ScientiaMobile : "we have been playing around with the idea of some form of Javascript performance index (possibly based on one of the existing benchmarks) that could give some indication of that, but we are still not there yet. The problem is complex."
Update-2 : The biggest bottlenecks we discovered in mobile web apps
animation power
PNG transparency
text and box shadows
image resizing
For us its really enough to figure out that we need to disable those features as they can bring any application to its knees. Possibly, there are also other approaches.
Thank you.

Unfortunately, I do not believe this is possible today for the general case.
If you are only interested in a limited number of devices, of course you could test each and target those specifically via user agent or JavaScript-based detection.
Within the context of a thick app (e.g., you "wrap" your web site with something like Apache Cordova), it would be possible to provide JavaScript access to some of the device internals (e.g., amount of total memory, amount of free memory, processor speed), but otherwise, this information is not available from the browser. As you've hinted at, having access to this type of device information may still be insufficient (e.g., seemingly "high spec" devices that perform poorly).
JavaScript feature detection libraries like Modernizr can answer whether something such as box-shadow and text-shadow is supported by the user's current browser, but does not provide information about how well or how quickly supported features will be rendered.
Likewise, the datasets from Browserscope and related project ringmark (somewhat of a JavaScript analog to WURFL) answer these browser support questions on a per-browser-version basis through crowdsourced benchmarking tests (e.g., does the iPhone support CSS3 transitions?), and for the general case, this is what would be necessary. You would need to run a benchmark test for the various features in question and assess real-time performance. However, even this has its limitations:
Because the necessary conditions for speed (available memory, processor, battery, network connection, etc.) are constantly in flux as mobile users move around, receive calls, change hardware settings, launch background applications, etc., the result of the benchmark is likely to be unreliable/unrepeatable.
Benchmarking takes time and will invariable add a (hopefully unnoticable) delay.
Depending on the feature, benchmarking may not be practical.
Features may behave differently in combination (e.g., animating transparent PNGs with shadows) or at scale (e.g., every image on the page is animating) than individually in the benchmarking test.
If you rely on benchmarking datasets instead of performing your own real-time benchmarking, the sample size, scope, and age of the dataset greatly limits its usefulness.
A final point is that I haven't even addressed is the fact that performance is rather subjective. Say it were somehow possible to assess/predict the speed of an animation. If the animation will run at 15 fps, should the user see that animation? What about 5 fps? Who gets to be the ultimate arbiter that decides the threshold for whether or not a given feature performs well enough?
The best advice I can offer today is to reduce (or eliminate) your reliance on the troublesome features for the time being. It may seem terrible to suggest going back to "the old way" of using images with precomposed shadows or making background gradients without CSS3, but at the end of the day the user experience should take precedence over using the shiney new technology. Many mobile devices are simply not there yet, and neither are the detection methods. If you must use these features, perhaps consider a simple but unobtrusive way for users to opt-in/opt-out like Gmail's "standard" vs. "basic HTML" view options, or consider automatically doing the opt-in for known good browsers.

I can't add much more than 'user113215' already said. Also its not an answer to the actual question but rather to the actual problem :
I did experiment with a few users and we were using a simple welcome popup menu, asking the user to turn off special effects such shadows and animations. The most of the test users did appreciate the choice and clearly understood the means of such menu. We do integrate this now more advanced and in conjunction with a hidden benchmark for auto pre-selection of GFX effects.
Thank you.
g

In short, no. How we define the smoothness of animations and graphics is solely depend on the FPS(frame-per-second). And in this question we are talking about "web-app"s, which are making use of HTML and JS on the client-side. Since none of the client side provide interface for the programs to get the FPS by HTML or JS, it is impossible to tell if the client is smooth or not.
However, if you really want a benchmark on the performance of web-app. You can make use of stats.js to monitor the change of stat and have a benchmark for you to suggest your client activating or disabling any sort of effects on runtime. This method even working with most FXs of Javascript libraries like jquery too. But this will take sometime for you to get enough data before applying changes and the stat may differ from the status of the device, such as memory usage, concurrent applications, etc.

Is there a higher level API for Xuggler?

After downloading and using Xuggler, my initial impressions are very good; it supports a whole host of codecs, it was relatively hassle free to get going and the getting started tutorial videos explained all the necessary concepts very clearly.
However, after playing around with it for a couple of days I'm really tearing my hair out over getting all the audio and video to sync up nicely. It's fine when playing normally but when adding pausing, seeking and accounting for occasional 6 second pauses while my external hard drive spins up it becomes an absolute nightmare.
I've partly implemented something already but it's nowhere near perfect - you can seek around a few times but after a while it still drifts off.
I can't help thinking this is a common use case of Xuggler and someone must have done this sort of thing already much better than I have. But alas, I can't find any examples beyond the ones on the website. Is there a higher level API around that manages all the audio / video sync issues and just provides some higher level controls (play, pause, stop etc.)? I've no problem going down the route of doing it myself if there's nothing out there already, but I've never been a fan of reinventing the wheel (especially if my new wheel is in all likelihood worse than the old one!)

This is really a two part answer - the first being yes, there is a higher level "player" framework here. It's in early stages but much better than anything I would have cobbled together quickly, and I'm sure the guy running it would be open to any improvements in the code.
Secondly, I didn't really go with the above at all because I looked to VLCJ instead which uses libVLC which in turn has all the synchronisation stuff built in nicely. To get multiple players embedded in the application reliably you need to use out of process players (see here for how I went about doing it) but once that framework is in place it works reliably, fast and overall very well.