I am using firebase real-time database for my app. It's great but I am facing a delay of some seconds during writing data from the app to firebase for the very first time. Means every time when I starts the app it takes a time of 2 seconds to send data to firebase. And after that it works fine with great speed. I know this isn't a big delay by any aspects but in my case I seriously needed the data transfer and fetching instantly. Is there any way to reduce this delay ? Thanks in advance.
The first time you access the Firebase Realtime Database from your code, the SDK has to establish a connection to the server. This involves multiple steps, which are only needed upon establishing the first connection. This explains why the first connection may take some time, and indeed it is not uncommon for it to take one of more seconds.
There is nothing you can do in code to improve the actual connection speed. That is up your bandwidth and latency (which I assume you're not interested in changing), and the SDK and server (which you can't change).
All you can do is start connecting as early as possible in your app's lifecycle, instead of waiting with it until you need to firs read/write data. For example, consider adding a listener to .info/connected when your app first starts.
True,
hi vj Shandilya to my knowledge, the initial connection ought to take a tad longer than expected as this was the case while my team and I were working on an IoT based project linked with firebase and Android-Java.
Maybe you can add, a custom (not intense) progress animation to cover up for the 2 sec.
Related
I am creating a pos application on android.
The database for the app is in the cloud. That causes a problem when the internet is down. To solve that problem i have created a SQLite database that keeps needed information for the work of the people using the app. (the app sync's data with the cloud when possible).
But a new problem arises.
If a client wants to have multiple devices in his establishment, i need these devices to be synced. Meaning the SQLite databases on all the devices need to look the same.
I think i should be using WiFi direct as in WiFi p2p but after some research i am not so sure anymore. All the examples i have seen are file transfer oriented, but i need to transfer simple lists of classes.
This process should happen seamlessly once we set up the devices in the background threads.
Here is how i imagined it.
We have for example 3 devices.
All 3 devices need to have all the SQLite data on them, and another important factor is that i have a fiscalID/orderID that needs to be incremented every time a order or fiscal is printed.
So: We have a primary device, who handles the increment of the number, meaning when a secondary device wants to print a order/fiscal, he asks the main device for the id, once the secondary device gets the id, he inserts the order or fiscal, after that he sends the SQLite data entry to the main device, the main device spreads that data to all other secondary devices.
If WiFi direct is the only solution to this problem, can someone link me to a good tutorial on this topic? It seem's that tutorial's on this topic are scarce, which is a shame because WiFi direct/p2p seems like a interesting concept.
Thanks.
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.
I want to develop a real time game for Android with libgdx. I need to update some variables even dough the game is not running.
For example I want the money to be increased 10 credits per hour (real life hour) so that you can go out of the game and come back an hour later and get that money anyway.
How can I do that?
Thanks
For real time, no need to setup your own server. Just use one of the public time server. Download NtpMessage.java and SntpClient.java from ntp site. Then run SntpClient.java with a ntp port. e.g.
java SntpClient 0.pool.ntp.org
You can use the code of SntpClient class and tweak if you need to.
When user gets out of game (pause state), get the time from ntp and save it. Once the user launches your game, get the time again and compare.
How about these two possible solutions (easy vs. difficult)
The difficult one...
To have a full control, you need to implement the logic in a server and have your application connect to it to get the credits (expensive but excellent solution). Your app will not hold permanent data. Your app will only be used for display, interaction, send/receive data from server.
The easy one...To simply use your app along with phone time. This solution costs much less but your app will be vulnerable against phone time manipulations.
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.