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 .
Related
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?
I have an activity indicator in my app, which I show when I'm processing quite a lot of data (building table rows) in a for-loop.
However while in the loop, the indicator doesn't move at all. Probably because the loop uses all resources.
Do I need to put a kind of 'sleep' in the loop so the indicator can redraw, or is there any other solution?
I'm using Titanium sdk 6+, the app is written with Android in mind.
Thanks in advance!
Actually, here you are doing 2 different UI tasks on one & only 1 UI Thread.
UI Task 1: Showing indicator
UI Task 2: Showing table rows.
But there's only 1 UI thread which we call as Main UI Thread. So doing 2 tasks on same thread will keep hanging up 2 tasks interchangeably which is why you see indicator moving sometimes after a freeze.
Ideally, it doesn't take much time to create any UI with today's processors so that you need to display indicator while doing them.
If you still think that your UI is taking lot of time in building up, then I would suggest you to choose another structure to create rows because as per my experience, creating 100 rows similar to Twitter Tweets on an average device will only take 2-3 seconds if built up properly.
That's why you really need to consider redesigning the Row UI creation code & it's strictly not recommended to show indicator on UI tasks.
To help you more, share some code snippets of how you are creating rows & what type of UI elements you're filling in them.
In Android, I am using a SurfaceView. It is inside a FrameLayout, to draw a couple of things on a transparent layer over the top of a general XML layout (with standard textViews, buttons etc.) The drawing does not involve very intensive computation, and does not animate, it only updates in response to button presses.
All the examples I have seen of SurfaceView use a separate thread for drawing, and then close down that thread in OnSurfaceDestroyed.
My code works without using a separate thread, but it does crash/freeze occasionally, especially when switching between orientations/applications.
So my question is, do I need to use an extra thread to prevent these crashes. And if not, is there any other specific thing I should do in OnSurfaceDestroyed? (I'd rather not post all my code here, just looking for a simple yes/no response and reasons in a couple of sentences).
You don't need to have a separate thread, but it's often a good idea.
For example, take a look at Grafika's "multi-surface test" Activity. It has three overlapping SurfaceViews that are rendered from the UI thread. If you click on the "bounce" button, it starts a new thread to control the animation, because it's simpler to do that way (it can sit in a loop and draw, instead of having to post timed draw events to the UI looper). The bounce thread stops when the Activity is paused. Note the code doesn't do anything in surfaceDestroyed().
The interaction between SurfaceView and the Activity lifecycle can be tricky. A discussion can be found here.
(It can be tricky to get everything right.)
I have a very simple question:
Is or is it not possible to inflate a view (not add it to layout) in a background thread (ex: in the doInBackground of an AsyncTask)?
I know that it is possible, because I have implemented most Activities in my application this way and never had a problem, until I had this problem on a Galaxy S: Android: android.view.InflateException: Binary XML file line #13: Error inflating class <unknown> in SAMSUNG Galaxy S
I've been told that I should not inflate Views in background threads, but what are the specific reasons and why does my aproach work in most devices but not in Galaxy S?
The LayoutInflater does not make any assumptions about what thread it runs on. And nothing is mentioned about this in its documentation. Also its code seams to be thread-agnostic.
On the other hand, Views that are created by LayoutInflater might instantiate Handlers in their constructors. Well, they probably shouldn't do that, but there is no requirement for them to not create/use Handlers in their constructors.
My guess is that Samsung Galaxy S had some modifications in its EditText that somehow triggers creation of Handler (according to crash log from your other question instance of GestureDetector was instantiated which in turn created new Handler). While default implementation doesn't do this.
Overall, I'd say that because there is no explicit requirement for Views to not use Handlers and Loopers in their constructors you can't assume inflating Views from non-UI thread is safe.
You can actually create HandlerThread and try inflating Views inside it. But I'd say this is very risky, as in Samsung Galaxy S example the view assumes that this thread will be alive during View lifetime and will process all messages using its Looper. Which might result in crash later on.
With latest support lib you can use android.support.v4.view.AsyncLayoutInflater to inflate views asynchronously. Be careful though that it can fallback to inflating on UI thread if specific requirements are not met:
For a layout to be inflated asynchronously it needs to have a parent whose generateLayoutParams(AttributeSet) is thread-safe and all the Views being constructed as part of inflation must not create any Handlers or otherwise call myLooper(). If the layout that is trying to be inflated cannot be constructed asynchronously for whatever reason, AsyncLayoutInflater will automatically fall back to inflating on the UI thread.
Is or is it not possible to inflate a view (not add it to layout) in a background thread (ex: in the doInBackground of an AsyncTask)?
Possible, yes. Recommended? No. As mentioned in the documentation:
Thus, there are simply two rules to Android's single thread model:
Do not block the UI thread
Do not access the Android UI toolkit from outside the UI thread
via: Processes and Threads
Update [02/06/19]:
Apparently, the support library has a tool to do this:
AsyncLayoutInflater (Jetpack version). It was introduced in version 24, around 2016 (2 years after my answer)
But, as mentioned on other answers, be careful with this tool as it can very easily backfire.
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.