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?
Related
I'm implementing a payment terminal in a POS (point of sale) application for Android. I have gotten an SDK for communicating with the payment terminal through Bluetooth.
Application startup: Initialize the payment terminal, check connection.
Then i need to keep it alive througout the application lifecycle, to be able to check connection status, and start/cancel transaction.
The main issue here is, what is a good/best way to implement this.
I cannot have it in the main thread as i have experienced ANR when doing that.
I was thinking that i maybe should create a service that runs in another process.
I found this table which gave me some indication of what i can use, but i'm not sure anyway. The closest thing to use here was the IntentService, but i'm afraid that since i cannot run tasks in parallell with that, i won't be able to cancel a transaction while it's ongoing.
Difference between Android Service,Thread,IntentService and AsyncTask
Would a solution be a regular service which starts a thread when started?
A side note is that i need to be able to use the content provider to save transactional data as well.
What do you suggest?
Thanks in advance
Use a normal Service that owns a thread. Send jobs to that thread to be executed in parallel on it. Its a fairly common implementation pattern.
it is logical question so I don't have code.
My question is:
How may I run background task that make Network work (waiting for messages from the server) and in the same time updates the UI when Message arrive!!
the Paradox "Android prevent access to UI from another nonUI thread", and "prevent network accesss from UI thread!!!"
Important: I want to run my method all the time that the application run, and scan network buffers and when I get message I want to update the UI and messages List...
That sounds like a perfect description for a Service. You can use IntentService or build your own Service (be careful, the last one doesn't start in a new thread by default).
There are also many examples out there how to update the UI from a Service (i.e. using Notifications or Broadcast).
Android provides built in class to perform network operation. For this purpose you can use AsyncTask class.
AsyncTask enables proper and easy use of the UI thread. This class
allows to perform background operations and publish results on the UI
thread without having to manipulate threads and/or handlers.
You can get details from here Android AsyncTask
But if you want to check message continuously then Service is the best solution as #AlexS explained it perfectly.
Hey I need to implement a infinite loop for receiving commands through socket and updating status in my android app and want that thread to be running even if application is closed. So I need to know that what I'm thinking is optimal solution or not... I am planning to make a service which create a thread which will look for commands and this class is also Observable so the activity can get updates of status from it. Kindly suggest your way or if you think this is right solution. Thanks.
Running things in background is usually a bad idea(battery life), especially if using data services(data plan costs). What you need is indeed a service, but start your updating status thread only when you receive a user present broadcast and stop it when the device goes to sleep(I think it's enough just not to request a wake lock and not use startForeground()).
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
I need a good way to get data from a thread to another activity.
I have one gaol: how to develop an Android app that plots bluetooth data forever in real-time.
I inherited a background thread which updates the screen with new data it receives over a bluetooth connection. When I launch my Plot activity I can see a bluetooth background thread continue to write bluetooth data to Logcat forever and ever. So I know for a fact the bluetooth background thread is still running when I launch my Plot activity.
I have succeeded as follows: since this bluetooth background thread seems to run fovever, I decided to use its update() method to call my static Plot.plotData() method to plot the bluetooth data. And this works. It will will run endlessly with out a problem - receiving bluetooth data and plotting it via periodic calls from the bluetooth background method update() to my static Plot.plotData() method.
The latest feedback I have received "It sounds like you're looking for an in-memory way to share data, and that's simply not the way the Android activity model works." In-memory???But this is rediculous. An Android phone has a limited amount of RAM for running Activities (one at a time), threads, handlers, Services, AnycTasks, etc. And an SD card for persisting data.
One critical person basically said: "In order to share data from a bluetooth background thread to my Plot activity (Plot.plotData()) that I must use the SD card." ??? This just sounds nuts, because I have it working using my static method Plot.plotData().
Frankly I don't see anything wrong with my solution primarily because those who criticize it do not follow up with a definitive alternative.
If you find my solution deficient please speak up and provide a definitive solution." Unless I use a new thread, handler, Service, AsyncTask, etc, everyone assumes my solution is not a good one. Why? Supposing the criticism is valid, PRECIOUSLY What should I do instead of what I am currently doing?
One more time: if you have background task running you should create Service. That's how Android expects applications to behave. Otherwise your thread may be terminated at any time (assuming none of the Activities are active).
From documentation:
A service is a component that runs in the background to perform long-running operations or to perform work for remote processes
This precisely describes your case.
Also carefully read Processes and Threads, specifically Process Lifecycle section.
Basically your application falls into Background Process or Empty Process group most of the time. That's why you need Service started in your application.
I've asked various questions related to one goal: how to develop an Android app that plots bluetooth data forever in real-time. I now have a new question from a different angle. To be fair to new readers I will cover some of the same background, but basically the question is in the title.
I found some open source code Bluetooth that apparently creates a background thread which updates the screen with new data it receives over a bluetooth connection. Then when I launch my Plot activity I can see the bluetooth background thread continue to write bluetooth data to Logcat. So I know for a fact the bluetooth background thread is still running when I launch my Plot activity.
Again, my goal is to plot the bluetooth data that is continually provided by the bluetooth background thread. I have succeeded as follows: since this bluetooth background thread seems to run continually and just won't die, I decided to use its update() method to call my static Plot.plotData() method to plot the data. And this works. It will will run endlessly with out a problem - receiving bluetooth data and plotting it via periodic calls from the bluetooth background method update() to my static Plot.plotData() method.
Although I have received some negative feedback regarding my solution, I have found sharing data across Activities where Edward Falk says sharing static data is OK. Here Edward Falk asks: "Are the activities all in the same application? [yes] Same task? [not sure] It seems to me that you could just store the data in a static variable accessible by all of the activities." Well I tried static data and it worked, but I switched to a static method Plot.plotData() which seems to work better for me.
The latest feedback I have received from one person #emmby that says my static Plot.plotData() goes against the following: "It sounds like you're looking for an in-memory way to share data, and that's simply not the way the Android activity model works." But what am I else to do? I thought that an Android phone has a limited amount of RAM for running Activities (one at a time), threads, handlers, Services, AnycTasks, etc. And an SD card for persisting data.
#emmby seem to say that in order to share data from a bluetooth background thread to my Plot activity (Plot.plotData()) that I must use the SD card. This doesn't sound right. After all I have it working using my static method Plot.plotData().
Frankly I don't see anything wrong with my solution primary because those who criticize it do not follow up with a definitive alternative.
If you find my solution deficient please speak up and provide a definitive solution. Otherwise I will take Edward Faulk's solution as the best one.
If I understood you correctly, your thread is running at the background even when none of the activities display data obtained by that thread. For example, let's consider scenario:
You started your bluetooth thread.
Your activity A started and now read data from that thread.
Your activity A is backgrounded (for example user navigates away via "Recent" tasks).
Your activity is idle but bluetooth thread still consumes cpu and power.
If you don't use your bluetooth data you shouldn't run the thread. You can introduce some kind of counter that tracks number of clients that use your thread's data. And if counter drops to zero - thread stops/pauses.
But Android has built-in solution for such cases. You can introduce service which will be bound by different activities and will have DataSource interface with getNextData function. See Bounded Services for more details.
When there are no clients bound to service Android will stop the service. This way you completely decouple Activities from thread. Your bluetooth thread is now managed by Service. And Service is now managed by Android.
In your case Local Service should be enough to share data between your thread and activities.