After doing some research it is still not clear to me how exactly Android downloads data from Firebase. Android has a lot of best practices for performance such as using an AsyncTask or Volley, but I need to understand how Firebase operates before I can make decisions about them.
To be more specific, does Firebase load data in a separate thread? When I am downloading profiles (a profile picture with some text) in a FirebaseRecyclerAdapter I would like to download the text for each profile first and the pictures in a separate thread. I know how to do this when downloading data from the internet normally but I do not know what Firebase already does.
Firebase uses a single separate thread for all its (network, disk, etc) operations. But your callbacks will always be invoked on the main thread, so that you can safely interact with the UI.
But if you perform any non-trivial operations in the callback, it is (as usual) your job to perform those operations off the main thread. So a AsyncTask or IntentService are still the proper approach there.
Related
Hi guys I have a question about Asyntask which is used in android studio :
As far as I know AynTask is used for user interface via one thread, the so called UI Thread. If you perform a long running operation directly on the UI Thread, for example downloading a file from the internet, the user interface of your application will “freeze” until the corresponding task is finished.
But let's say that I want to register an account so that I can login, that shouldnt take time at all so why should I use Asyntask for this?
Let's say I want to send 100 strings to the Database, that can be done in milisecs I think, so again, why to use and how to decide when to use Asyntask?
I hope you guys can help me out, I have been searching for a long time !
If you don't know how much time operation will take, you should perform it in a separate thread and then pass the results to UI thread. I think the database should be accessed in a separate thread as well as HTTP requests. In the case of time-consuming query, it may be a long operation. AsyncTask is one way to do it. You can also use other techniques. The popular technique used nowadays is applying RxJava library, which gives you the high-level functional reactive interface for writing multi-threaded applications with a few additional features. You can perform an operation in e.g. Sechdulers.io() (I/O) thread and then pass the result to AndroidSchedulers.mainThread(), which is UI thread.
There are also other techniques like using Looper & Handler from Android SDK or using Thread class from Java, but such techniques require more knowledge, more work, writing more boilerplate code & you have more problems to deal with.
I've an android app where I'm retrieving data into a Fragment. And I believe that Firebase manages its asynchronous calls. But still I've doubt the if we need to write the Firebase code in the background thread or not?.
If we need to write it into the background thread then can you please tell which operations takes more time. eg:
mDatabase = FirebaseDatabase.getInstance().getReference().child("Blog");
I think that performing this on the main UI thread may become risk full because setting connection between database may sometime take large time.
The Firebase Database client performs all network and disk operations off the main thread.
The Firebase Database client invokes all callbacks to your code on the main thread.
So network and disk access for the database are no reason to spin up your own threads or use background tasks. But if you do disk, network I/O or CPU intensive operations in the callback, you might need to perform those off the main thread yourself.
If you're pulling down a large-ish collection of data from the database, and you want to convert that all into a JavaBean type collection, you may want to offload that onto another thread as the size of data its use of reflection may cause too much work for the main thread. The only way to know about this for sure is to benchmark it yourself. Generally speaking, you get 16ms to do things on the main thread before you start dropping from the optimal rendering speed of 60 frames per second.
I recently tweeted a diff on a project of mine where I refactored a pattern for sending database listener to an Executor for background processing. However, your app may not call for this kind of complexity. It was good for my app, however. https://twitter.com/CodingDoug/status/773277680867258368
Firebase runs all of its callbacks asynchronously as documented https://www.firebase.com/docs/android/guide/retrieving-data.html . This is done through a web socket layer.
If for example, you need to do a large amount of data processing on the result of the Firebase data update - you should probably spin up an AsyncTask to prevent the UI from blocking. This isn't any different from how you would normally approach data processing before being presented to the UI.
The Firebase documentation covers how data is handled and the reason why you do not need to execute any background reads. You should probably spend some time reading the documentation.
As I understood, Firebase Database performs all the reading tasks on a single thread.
Is there a way to split that work into few different threads?
Is there a way to make a tasks execute before another? some parallel to handler.postAtFrontOfQueue() ?
The Firebase client handles all network and disk I/O on a separate thread to avoid interfering with the UI of your Android app. The callbacks into your code are invoked on the main thread, so that your code can interact with the UI.
The operations are executed in the same order in which you call their APIs. There is no way to re-order operations. There is also no way to set up multiple threads, nor have I ever seen a need for that. Interacting with a remote service is inherently an I/O intensive operations, which is not helped by multi-threading.
This sounds like a XY problem. If you describe the actual problem that you're trying to solve, we may be able to help better.
I referred so many links regarding synchronization
http://developer.android.com/training/sync-adapters/index.html
my requirement is to download all the data regarding the user at first time.There are nearly 12 tables are existed at the service i need to download all the 12 table into the android mobile at first time. After that we will modify that local data whenever we click on that sync button we need to send that updated data to the server.
I am following this type of approach: I am sending a json object to android mobile from server side which contains all the 12 tables data.by using that json object i create the tables and insert those data into the local database.Is this correct approach?
Is there any jars exists to simplify this type of requirements?
Please give any suggestions regarding this question.
For downloading the data. You can use AsyncTask in Android. Its runs at background so no worry if you are changing the UI. Here is the documentation
AsyncTask
AsyncTask enables proper and easy use of the UI thread. This class allows to perform background operations and publish results on the UI thread without having to manipulate threads and/or handlers.
Here is the good tutorial on this topic have a look on this
Android Background Processing with Handlers and AsyncTask and Loaders - Tutorial
If I need to asynchronously load some data via HTTP (or whatever) in order to update the UI, I have a few options when writing an Android application (among many others that I'm sure I missed):
Use a regular thread and a handler to update the UI.
AsyncTask
Use and IntentService, and use either a callback or broadcast the results via an Intent.
Using Loaders.
From what I understand, an IntentService is not tied to an Activity's lifecycle, so any changes to orientation, etc, will not impact the retrieval of data. Where this is not the case for an AsyncTask or thread fired off within an Activity.
The reason for the question, is that I just recently read about Loaders, and am confused as to their application. They seem to be more closely tied to a data source, where if the data source changes, then "transparently" everything is handled appropriately. Loaders also appear to be tolerant to configuration/orientation changes (I believe).
I've been currently using an IntentService to make RESTful service calls, and broadcasting the results to be received by appropriate Activities.
I'm assuming I could write an HTTP based Loader, but I'm not sure if this is the best use of this mechanism.
What are the advantages/disadvantages to using one of the async data loading methods over any other?
All of these mechanisms are simply options. There's no such thing as a one size fits all tool and so all of these different methods of completing the same task is a way to cover as many use cases as possible.
Ultimately, it's up to you to decide which method makes more sense for your scenario. But for a sort of generic explanation of what you should use...
Regular thread and a handler - Why when there are other, simpler, options?
AsyncTask - Since an AsyncTask will almost always depend on an Activity, use this when you need to load data asynchronously and you are 100% certain of how long it may take. Example: Executing an SQLite query.
IntentService/Service - Services are not bound to an Activity like an AsyncTask is, therefore, they are perfect for scenarios in which you may not know how long it will take to complete. Example: Downloading data from a web API and updating a database.
Loaders - Loaders are aimed at simplifying the process of loading data and populating it into UI. The nature of Loaders sort of assumes that the data you will be loading will be presented to the user as a list of some sort. Example: Downloading data and populating it into a ListView