Develop Reference

What is the need of main thread in Android?

i know that the android app runs in the main thread means UI thread.I want to know what is need of main thread to run an app? What happens if we do not use the main thread to run app.Why main thread is necessary?

Well it needs a thread. Every app ever written has at least one- even the simplest Hello World app in the simplest language. A thread is just a series of instructions being run on the processor. So even if your app doesn't multithread at all, the one series of instructions it is running would be a thread- you could even call it the main thread if you wanted. So it would literally be impossible to have no main thread at all.
What makes the main thread special in Android is that you're only allowed to change visible elements on it. If Android didn't have that restriction, you'd have the possibility of race conditions and inconsistent UIs- the possibility that views are being changed on one thread while another is drawing to the screen. To prevent this you'd need to do a lot of manual locking. Instead, Android decided to only allow these changes on the main thread. That prevents a large class of timing bugs and race conditions (although not all, depending on how you implement your models).

From this link:
What is the need of main thread?
When an Android application is first started, the runtime system creates a single thread in which all application components will run by default. This thread is generally referred to as the main thread. The primary role of the main thread is to handle the user interface in terms of event handling and interaction with views in the user interface. Any additional components that are started within the application will, by default, also run on the main thread.
Why is main thread necessary?
Any component within an application that performs a time-consuming task using the main thread will cause the entire application to appear to lock up until the task is completed. This will typically result in the operating system displaying an “Application is unresponsive” warning to the user. Clearly, this is far from the desired behavior for any application. In such a situation, this can be avoided simply by launching the task to be performed in a separate thread, allowing the main thread to continue unhindered with other tasks.
Please refer to the link to understand more about main thread with an example.
For more details, you can follow this link.

When will one need to create a separate process in a Application?

I was reading a article in Android developer blog Process and Threads which talks about creating new process for specific component of Application. But I failed to understand when will creating a new process in my application becomes a absolute need. Could you please help me understand following doubts I have in this regard.
When as a developer I should feel I need to have a separate process for a Android component/s?
Does introducing a new process has any side effect on application's overall performance?
Any other info is greatly appreciated.
Thanks,
SKU

Having a separate process can be useful if there are components of your application that do not necessarily need to both be running to be useful to the user, and the background task is critical to application "correctness" (either now or in the future). The classic example of this is an app that has a service where the service saves or uploads some data that is critical to your application (critical meaning the only way to get the data back is to have the user re-enter it!). The service might be responsible for doing something like uploading or saving data, while the activity is just the interface for the user. So developers should decouple these two components to prevent problems that may arise from my next point..
Android was designed to run in a resource (especially memory) constrained environment, so processes deemed unimportant are killed periodically to open up memory for important ones by the "low memory killer" (LMK) (if you Google this you'll get tons of information on the topic). Things like foreground processes are understandably given a higher priority since they're currently in use, but they're sometimes killed off as well for reasons like consuming too much memory. Now, imagine you need to save off some data to a database after the user does something in the app and you use a service to do so to ensure that it is done even if the user navigates away from the app. Unless you create the service in its own process the process containing both the activity and the service is likely to be killed since the process belongs to a non-foreground activity.
However it is not always necessary to place the service in its own process, oftentimes simply giving the service its own thread will suffice; it's very application specific. I would only place a service in its own process if it took longer than maybe a few seconds (long enough for the user to navigate away from my application and for the LMK to step in) to perform some task in the background and that task related to the "correctness" of my application (I.E. saving data for later). For something like caching, stick to threads, since if the process gets prematurely killed you can just recreate that data later.
Another reason to have a separate process is if you're running a global service (a service that can be used by applications other than your own) that maybe you provide an interface with via an Activity for configuration.
As for the performance question, there will definitely be a performance hit for something like this. Interprocess communication is not cheap, so you should really only use a separate process if you fit into a specific use case, like the ones mentioned above. Also, there's a certain amount of memory overhead for maintaining a process, so that's another performance hit.

1.)You need to do something on seperate process or thread when you don't want your app to behave slowly. As by introducing threads you force your app not to run on UI thread. Thus making your app responsive to other events. For Example : you can use threads when you have to fetch some data from web service so that it happens in background and doesn't effect your app.
2.)Threads should not be used..We should use AsyncTask or loaders rather in android.

1.) In android 4.0 (and possibly 3.0, not sure though) The device does not let you use the HTTP Agent in the main thread, for this slows the UI..
This is when threads come in handy.
Also with the use of functions that need alot of cpu, if these are run in the UI thread, the UI will lag and not respond until the function finishes.
2.) as stated at 1, it will actually improve the visual performance of your app ;)

Closing another process listener

Is there any possibility to create a listener for closing another process?
Let's say I want to know when the process com.android.test.app isn't running anymore.
By the way, I don't want to use threads for listening for current running apps.

Btw I don't want to use threads for listening for current running apps.
From what I know, there is no other way supported by Android as yet.
I'd like to point out that getRunningAppProcesses() checking processes with IMPORTANCE_EMPTY or IMPORTANCE_BACKGROUND is one of doing this but as per the documentation :
Note: this method is only intended for debugging or building a user-facing process management UI.

Android: Single service with multiple threads

I am building an application which performs 3 tasks concurrently.->
Listening to new devices.
A proxy to interact with the device in real-time.
A set of business Logic to be run on the data provided by the device proxies.
And of couse a Main UI (thread)
I want task 1,2 and 3 to run even when the application is in the background.
What should be done?
Using 3 services, one for each.. (apparently not practical).
Can a single service support all the tasks.( one service with multiple threads sort of design)?
Please help.
Basically, What i intend to ask is that is a model available to perform all 3 tasks even if the application is in the background? If service is the answer, how can it be implemented in an efficient way without putting too much load on the system i.e. using 3 services?

I would go for three threads started in your action or (Surface)View depending on what sort of updates you'll have on screen.
When doing threads though you really need to keep synchronization in mind so your application won't blow up from accessing the same variables and getting unexpected results.

Using Multiple Threads to perform your tasks concurrently.
The following link gives a good idea about Multiple threads: http://edwards.sdsu.edu/labsite/index.php/josh/124-multiple-background-threads-in-android

Make sure your service runs in the foreground; this will make it work.

Problem with GPS porting

I'm working on a GPS porting project where we need to avoid all the framework changes. This was acheived through a socket where an application (GPS Settings) talks to GPS library (Middleware) and vice versa.
Issues
In GUI, Socket is running in one
thread and not able to call methods
in the main thread
activity(securitySetting.java). For
this we are using the Handler to
communicate with the main thread but
the problem still persists. The
problem here is the actual source is
modifed, securitysettings is
inherited from
"SettingsPreferenceFragment" where
when i check the actual source it is
inherited from preferenceactivity.
Every time i am using
securitysettings.this.getactivity()
to get the context.
Need to show few notifications,
after completion of work in GPS
library. Its is not possible from
security settings activity as it
can't be avaialble all the time.
Please suggest if any work around to
show the notifications.

I'm having trouble understanding this question.
To me it sounds like a threading/UI issue. You have a separate thread running, doing some work and you want the Activity on the UI Thread to get notified when this background thread is done, so it can display something to the user. Is that correct?