Develop Reference

Exactly what operations can only be done on the user interface thread?

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?

How can I monitor user activities in my app without touching the main class that extends Activity?

Suppose an app project is already written, all you want to do is to additionally write a somehow standalone script that captures the onClick, onFocusChange or even onAppear in the app. Is that even feasible? How robust is the approach?
All answer I found was to fully add listeners (or global listeners, although less comprehensively functional) for each item or so, which is a boring work for a large project, and not always desired at the end of a production process(where I just cut in).
Another purposed approach was to locate the root of the nodes and scan from there? Correct me if that's a dead end. Other answer mentioned spying app, which is not the case, since it's the original developer who wants to track everything from inside the app.

I am not sure, if this solves your problem but have your extension of views. Eg: MyTextView extends TextView then just override the touchEventHandlers, log what you want and dispatch the event down to the listeners.
So instead of normal TextViews, use MyTextView.

is it possible to use view instead of UI Thread?

I m new in android.
i have a little bit confusion in SurfaceView and View......
According to my knowledge..
Views are all drawn on the same GUI thread which is also used for all user interaction.
I want to knw is it possible to create separate thread for the handling

Depends on what you define in handling.
If in handling you mean doing calcualtions, downloads etc. then yes.
If by handling you mean splitting control and view up, then no.

If your handling means that handling GUI things in other than GUI thread then Its not possible as Views are coupled with GUI thread or Android Component Activity. But non GUI threads alive even when your activity is finished , and It may leak the references to views. So it has been avided in al most all Programming models. Suppose if you are downloading the some values in Non GUI thread and then update your GUI views and in bwteen your screen orientation takes place and Your activity and its views are recreated but Non GUI thread is till now keeping the reference to old views . This can create old views to not to be collected by Garbage Collector and leak memory .

When should you let SurfaceView be drawn by UI-thread?

I'm reading up on SurfaceView and how to use it, and I've come across some information that states that a SurfaceView has View#willNotDraw() set to false by default, and that it's up to you to call SurfaceView#onDraw(). I also read that RomainGuy said that this is done by default because it is more efficient. My question now is, when should you handle calling SurfaceView#onDraw() in a separate thread, and when should you just set View#willNotDraw() to true, and just call SurfaceView#invalidate(). Is there a difference between the two, and does one improve performance more than the other?

See:
http://developer.android.com/reference/android/view/View.html#setWillNotDraw(boolean)
I'm not sure where you got your information, but at least the javadoc says that most users will set this to false to get Android to send it onDraw events itself. As for your question about when you should do this, I would say it comes down to why you're using a SurfaceView.
If your view is displaying something dynamic (e.g. for a game or something that has a tight event loop), you'll want to be controlling exactly when updates happen, especially if you'll have the information to use one of the more detailed forms of invalidate to save redrawing the entire View. You won't want Android to call invalidate for you, and that's why the flag is there.
If, on the other hand, you are simply drawing something static, it makes sense to let Android's UI stack control the invalidations.
By the way, invalidate only posts a request to re-draw the View, so be aware of this if you intend to use the event-loop style (onDraw will be called sometime after you call it).
Edit: some clarifications.

Using SurfaceView.onDraw() and SurfaceView.invalidate() will make SurfaceView behave like a normal View and you will pay for the extra overhead associated with SurfaceView. If you want to draw from the UI thread, use a regular View instead. It's easier and cheaper.

Taking a long time setting up views

I have a form with about 100 views and apparently all the findViewById is taking a long long time. And i need to do a save and retrieving of the form fields which takes around 2-3 seconds freezing the UI thread.
Is there any way to make it look better? I read that its not feasible to call findViewById or any UI related stuff on another thread but i have no choice.
Saving the forms from that many field is taking alot of time as well.. im doing it on another thread currently.
On honeycomb 3.1. please help. many thanks.

You might want to rethink your design, perhaps you could use a ListView, which'll only construct enough views to fill the screen, rather than the entire UI. You could also use the events from the edit controls to update a structure with the current values as they are edited rather than waiting til the end then trying to read all the values in one go.