So I understand that any changes to the UI need to be on the main thread for an Android application. And also, you should use other threads to do work so that the UI doesn't freeze up. But some of the work I want to do is preparing UI elements which will be shown later on. I want to get those things ready on a separate thread and then enable a button once its done - that way the user won't be able to access it until it's ready BUT they'll be able to use the main page quickly.
Exactly what operations count as changing the UI? I want to do as much preparation in the background so that the first part of the app ready can be shown ASAP while other parts are still loading.
For example, it seems like findViewById is fine, but what about creating/modifying Views, setting listeners, setId, setEnabled and so on? If I newly create a Button which hasn't been added to a parent, can I setText on it in a background thread?
Related
From Activity lifecycle we know, that in onResume the UI is visible. But if I set a breakpoint on onResume, I still don't see it, only after that. I heard there's some method which can check it, but I can't remind how it calls. We used it to make better animation. So how can I be fully sured that UI is ready?
Add global layout listener on view you want to check. Also please make sure that you remove listener once your work is done else it will keep getting called multiple times.
#onik shared a good link that should solve your problem
This ensures lay-outing. Drawing happens continuously and frame are refreshed according to sys clock.
I recommend watching: https://www.youtube.com/watch?v=Q8m9sHdyXnE
This will give you good idea on android drawing and layouting
When my quiz app starts for the first time it needs to add questions to a database and a few other things and this takes a few seconds. I want to display a indeterminate progressbar whilst this occurs. Once the questions are added, the class calls finish() and moves on to the main screen. The problem is that the layout isn't drawn unless finish isn't called. I assume it doesn't draw the XML layout until after the oncreate and onstart are called. So how do I get around this?
The reason, the UI isn't shown while you're filling your DB is probably that you're doing that in the UI-Thread - the main thread of your application. As the thread is busy filling your DB, there is no time to show the UI, animate the progress indicator or react to user actions.
Thus you should always run time-consuming tasks in a separate thread. See this excellent entry in the android devloper's blog about painless threading for more information and to do it right:
http://android-developers.blogspot.co.at/2009/05/painless-threading.html
Use AsyncTask, display progress dialog in its onPreExecute and dismiss in onPostExecute prepare your db in doInBackground.
You would have to handle device rotation unless you are using DialogFragment to display your dialog.
I am making an interactive walkthrough for one of my apps, and in a couple of spots an alpha animation and some various other UI changes (such as checkbox pressed states) would be really great.
The walkthrough has a back and next button. The basic idea is that the next button would start the animation (maybe as a thread?), and if at any point in the animation the back button was pressed, that the animation would stop.
I have looked into the built in Android animation library, but have sort of seen a lot left to be desired. My next thought was a thread, but I know I can't change the UI from an outside thread. Also I want to leave the UI thread open for my back button listener.
Any thoughts on how these simple animations could be achieved?
You're right you can't update UI elements directly from another thread. But you can do this indirectly with Handlers. Handlers are basically a type of IPC that allows you to queue up messages to the UI for proceessing. So what you do is basically create a Handler in your Activity and pass this handler to your process thread. When there's something you want to update in the UI from the process thread just do mHandler.sendEmptyMessage(UPDATE_SOME_VIEW).
Take a look at handlers here.
I am changing the value of several RatingBars upon completion of a child activity (inside the onActivityResult() callback). My problem is that the parent activity has not finished drawing before my RatingBars value-changing code is executed, so I get some funky lag and a half-way completed "animation" before the parent layout has even been displayed.
I'm familiar with the document.ready() function in jQuery, which waits until the DOM is completely ready to commence any script therein.
Is there any way to achieve the same result with Android? In other words, I need a way to wait until an activity has completely finished drawing itself to the user's screen before some code is executed.
This might be a simple thing in Android, but I'm pretty noob. Thanks for your time and help.
-Steve
Could you simply put the code in the onResume method which will be called after the views have been set up?? (Not sure if this include getting drawn)
Another possibility is to create a handler and dispatch a method to it at the end of the onCreate method, this will get run on the UI thread but I imagine this won't get processed until the UI thread has finished the more important stuff (i.e. drawing the views)
This is largely just me putting down possible ideas, I know there is a way of achieving this I just can't remember how.
I'm developing an Android 2.2 application.
I have an event listener on an activity, and I want to set visible a TextView when I receive an event. But there is an error:
I only can set it visible from UI thread.
In C# and Windows Mobile there is a BeginInvoke. Is there something similar in Android?
Thanks.
You can use Activity#runOnUiThread or an AsyncTask as the two easiest ways to duplicate the BeginInvoke functionality; with runOnUiThread being the one most similar.
For more complicated or performance orientated needs (i.e., you do not want to keep creating a large number of Runnable objects) you can use a Handler. However, I do not recommend it as your first choice.