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.
Related
I am looking for a way to start my application automatically as soon as the users phone GPS detects certain speed, is it even possible to do such thing?
I have been looking for a while for that in google without much success.
is it even possible to do such thing?
No.
The closest thing would be to have your app running 24 hours a day, constantly checking GPS and then taking specific action when the speed reaches your desired level. This will be exceptionally bad for the battery and has significant privacy implications.
Not sure what your exact use case is, but maybe Google's Awareness API maybe of use to you, look it up here https://developers.google.com/awareness/android-api/fence-api-overview
I am using LocationManager's requestLocationUpdates() to get the user's coordinates on opening the app, and it takes longer to get the coordinates than in other apps.
Getting location takes a while, however while my app is still loading and waiting for location (I am using LocationManager's requestLocationUpdates()) for much longer than other apps.
Here is a screenshot of my notification panel when I launch my application:
Notice it says Finding Location... when I open my app, because my app calls LocationManager's requestLocationUpdates() as soon as the app is opened.
Here's the meat of the question:
Even while this notification is in my presence, if I navigate to an app like google maps, it is able to pinpoint my exact location in a matter of seconds. Is that because google maps uses getLastLocation?
How come other apps are able to fetch location much faster than mine?
So there are two ways of getting location- fine (gps) and coarse (network). Google Play Services provides a 3rd method, but it uses a combo of those two. GPS takes a long time- it literally has to talk to 7 out of 2 dozen or so satellites to get a location for the first time. Network is fast, it just needs 1 network request (or less if data is cached).
A lot of apps will use both simultaneously, using the network to get a fast answer, and then improving to GPS when it gets that data. I know maps does this. This will get you a fast inaccurate answer, and allow you to improve the accuracy later.
You can use getLastKnownLoacation to go even quicker, but you have to be able to deal with it returning null. Generally network is fast enough.
I am using many threads in my app that are always running.These are used to send data to server periodically.There are called through services.The problem is that my app drains a lot of battery.I want to fix this.How??
I mean gmail etc dont drains that much of batterry.
Applications like Gmail are not requesting the server at frequent intervals, you may have to check the architecture of your solution, there are other mechanisms to do this you need:
http://developer.android.com/reference/android/os/AsyncTask.html
http://developer.android.com/guide/components/services.html
I would advice you to check Googles Android Training on minimizing the battery usage and focus on ways effectively access the network and send files there.
There is also a nice video presentation from Google's IO event that touches the topic (at around 1/3 of the video). It presents some code an is perhaps more easy to understand but less deep than the previously mentioned documentation
We want to implement a back end server [Java EE] for mobile application that sends notification to mobile on some events, I'm asking about the best/simplest approach whether Pushing or Pulling notifications, here you are my ideas/questions
1- The requirement is to send instantly the notifications to the mobile as long as the application is running no need to send if it's not running
2- I read that to push notifications to IOS or Android, I will need to connect to apple/google notifications servers, I felt that this is complicated especially that it requires low level socket programming, but based on number 1 and the project has limited time and budget, do we really need pushing ? and is it really complex
3- I read that pulling date may drain battery and consume data, but what if implementing a simple job on the mobile that runs only 3 or 4 times a day, invoking a simple web service on back end server asking for the notifications
P.S will be much appreciated if you can provide some tutorials for similar cases :)
1) If you're application is already running, is it connecting to the same location anyways? If so you might as well pull for the notifications at that point. However, if the app isn't actively connecting, i would attempt to avoid pulling.
2) Interacting with Notification servers on google and apple site directly, can indeed be a cumbersome task. However there are companies that have made this much easier for you. The advantage of using companies like urbanairship, xtify and mblox will get you started with sending push messages in minutes. (for an example take a look at http://developer.mblox.com/docs/ in the tutorial section).
3) depending on the data you try to present, end users now a days are used to instant data. I can't imagine a service whereby pulling 3 to 4 times a day is sufficient, however if your use case is truly limited to 4 times a day, and there is no other activity going on in the background process you create for this, you might as well have the background process running. But do think this through carefully... If at any point in time you want to increase the number of times a day you read, you might soon get to the point where a rewrite is needed to ensure end user satisfaction.
I'm new to the android development, and programming in general.
I'm developing app to create football statistics for each player, and in the long run I'm using SQLite to store data. However I was wondering if there is a way and if it will make sense, to store data during the run of my application without inserting it to the db, every time user is trying to add new statistics.
Also I'm wondering if there is a point in doing that, my biggest concern is that inserting data to a db all the time will slow down my app, and I would appreciate what more experienced developers do know, and think about this 'issue'
I was trying to research the topic, however all I got was storing data in db, and using SharedPreferences and I don't think that's what I'm looking for, however I can be wrong.
please help.
SQlite is what you're looking for. SharedPreferences are for just that - preferences, not large amounts of stats.
Put your database code in a separate thread and you won't notice any slow down in your app. Ask back here for help on this.
I can't speak to android directly but I have faced similar design issues on iPhone and desktop applications.
It depends on the specifics of the application as to what would be the best way. If your app is mostly about entering plays and saving statistics, I would keep a small set of the latest statistics in memory enough to populate the user interface and then create a "data manager" running on a background thread whose sole purpose was to insert these newly added statistics to the database.
Honestly, I would put it in the DB immediately. With the way android works, if your user navigates to another app (or possibly even receives a phone call) the data they have already entered could be lost.
It is possible to cover that contingency obviously (saving in onPause, etc.), but I've always felt it was safer to get the data into permanent storage as soon as possible. (Note this is a hotly debated topic, I'm merely stating my preference).
Saving to the DB immediately doesn't affect app speed (depending on how much of what type of data you are inserting) so much as battery life. Accessing permanent storage takes more in terms of power as there are several more steps the processor needs to take.
If you do all your DB activities in a thread other than the UI thread the transactions will be almost completely unnoticable in terms of app speed.
If you use implement Loader callbacks it should not slow your application down. Have a look at the Loader classes. They are available through the Android compatibility library.