I have my full functional code working, but as much as I took time to write this clean code, I am having problems notifying my UI for data.
The data state I want to notify my UI with are:
State Data available
State no data
State poor network connection
State loading data.
I have all the callbacks that makes these data state, but how to notify my UI in a clean way is a pain. Though, I have tried several means like using an Interface and ViewModel that controls a progress bar and dialog and just make them visible and invisible at the right time. This method is clean but I wish do do more cleaner handling plus I have a issue of delaying a little for data to arrive especially in case of a little weak network connection to download data.
Here are my questions:
How to effective way notify UI for data states.
How to delaying effectively while waiting for data.
I appreciate your reply.
Related
I have a fragment and the data displayed are fetched from a network call.
I am using onSaveInstanceState in order to avoid fetching the data again when the orientation changes, but if I understand the lifecycle for fragments correctly as long as the app is never destroyed (either explicit by the user or because the Android OS kills the activity due to lack of resources) the data from the server will never be refreshed.
If I have understood this part correctly, I would need to define some way to periodically refetch the data from the server or is there another way?
There are no rules about data refresh. It depends on your app, your data, etc. If you fetch a list of receipts, you do not need to implement a refresh mechanism. But if you fetch, I don't know, the exchange rate of currencies, you must have one.
What about a pull to refresh pattern ?
I would use the Android Architecture components ViewModel and LiveData to save the data during screen rotations preventing multiple calls to the server for screen rotation changes. This is the preferred method Google seem to be pushing to their developers https://developer.android.com/topic/libraries/architecture/saving-states
To prevent the data from going stale I would either let the user decide when to update using the "Pull to Update" (as described in the other answer) or add a timer to update if the fragment has been in the foreground for an extended period of time using the method described here: https://guides.codepath.com/android/Repeating-Periodic-Tasks
I'm trying to determine whether or not I download data in my android application. I can do this by making the method return true when it does download data, but the listener doesn't seem to be invoked until all other code is finished running (meaning it waits until a pause in your code). So I'm wondering if there is a way to sort of "forcibly" invoke these listeners? Perhaps by creating the listener in a different thread? Would this work or would it be a waste of time? I've already tried to sleep on the main thread for a few seconds, but that doesn't seem to do it either. If it wouldn't work, could you explain when exactly these listeners are invoked? Thanks in advance.
To add onto my question, I am NOT using the realtime database. I understand how realtime triggers work, but I am using the Firestore, so I am only getting data once, not getting realtime updates :)
As you have already noticed with the API calls that deal with reading and writing data are fully asynchronous. This means that the call always returns immediately, without blocking the code to wait for a result. The results come some time later, whenever they’re ready, since it may take some time for this. Depending on your connection speed and the state, it may take from a few hundred milliseconds to a few seconds before that data is available. So Firebase, already is using another thread (other than the main thread) to get the work done.
Calling a synchronous function on your app’s main thread could freeze the app indefinitely, which is a terrible UX. On Android, it could also soft-crash with an Application Not Responding (ANR) dialog.
Doug Stevenson, has explained in his post everything that you need to know about Fireabse asynchronous behaviour and what you need to do/avoid when dealing with Firebase.
I am currently creating an Android events app that uses RxJava to wrap an old network layer and cache setup with Observable.create(). I'm currently stumped as how to approach prefetching data though. Initially I display a list of events which will then open an EventDetail Activity which will fetch the contents of the given event. I want to prefetch some of events' contents, but end up making redundant network calls if the event is selected before the prefetch returns and caches. Is there a good way to keep Observables/subscriptions alive over Activity switches? A singleton network layer held in the application? Any help would be greatly appreciated.
Typically, I keep all the logic away from Activities, so, "Yes, definitely!": A network layer is what you need.
Keeping this approach, your Subscriptions will stay alive even if the Activity is restarted, for instance, on rotation. A very useful operator you need to look into is .cache(), that will help you to reuse the ongoing network request instead of firing a new one on a new subscribe().
I am using a database to persist the state of a search form. I am using the onPause method to persist the data and the onResume method to restore it. My opinion is that restoring and persisting state should be a blocking operation so I plan to perform the database operations on the UI thread. I know this is generally discouraged but the operations should be quick and I think if they were done asynchronously they could lead to inconsistent UI behaviour.
Any advice
Even if you want the application to not accept user input while the slow operations are being performed, you still don't want to do them in the UI thread. This is for two reasons:
Fully non-responsive UIs are a big nono. If you need to lock your user away from interacting with the program, you need to assure him that something is actually going on - anything else is likely to be interpreted as your application being buggy. Use dialogs, toasts and/or progressbars while the application is working, as appropriate.
Android will offer users the option of force-closing applications that it thinks are hanging. You don't want this to happen during what is normal behaviour for your application is taking place.
Even if you want it to be a blocking operation, you have to show the user that some thing is happening. Because when the UI thread is blocked, the screen will not respond to any touch operation of the user. Sp, you can have an indefinite progress bar in your onPause() and onResume() methods till the persistence and restoration is done. And obviously you will have to do it in a separate thread. Because if the UI thread is not responding for sometime, android can give the Application Not Working error.
I'm currently building an android application with quite a few different connected activities. In each activity I've got a private updateView() method to update all the textViews and stuff on that screen. This gets called in the onResume() method so that each time the activity comes to the front it's views will be updated.
Is this the right way to do things or is there a more standard pattern for keeping your views in sync with the data?
I think that you are doing this correctly. onResume would be the perfect time to update your views, I assume you are only updating if there is actually new data to be displayed?
If retrieving the data during the updateView method takes a long time then you should do it in an AsyncTask to avoid clogging the UI Thread which will make your app hang.
In fact any data retrieval like getting data from the web or reading from your apps database should be done in an AsyncTask. This is because even if your data retrieval seems to take milliseconds on your device it may conceivably take longer on another, less powerful device.