I'm making an application in Android that should detect, classify and map road surface anomalities (potholes, speedbumps, road rugosity/roughness, etc.) using mobile sensors (accelerometer, GPS), and I'm in need of a little advice on some design choices since I'm a quite new to Android development.
So far, I have created a background service (using AsyncTask) that reads the sensors and stores data in buffers.
I need to use the data provided by the service to perform some low level filters and computations which I must then use for the pothole/speedbump/rugosity/mapping/etc. detection procedures.
I want to somehow modularise/layer these procedures such that the lowest level filters provide the data for higher level procedures and I'd love some suggestions/best practices on how to achieve this.
I'd also like to know how to consume the data provided by the background service (timer triggered event at a given interval, ...) ?
I am no Android expert, but I have been developing an app with similar structure than yours. To accomplish it, I am using an actual long-running Service for the top-level background proccessing and data management which launchs different Threads to perform low-level computing and data acquisition.
For the communication threads->service, I am registering a BroadcastReceiver in the service and broadcasting information from the threads. To communicate service->activities I am just binding the service to the activity as described in "Extending the Binder class" in Android API Guide.
So the structure is like this:
Activity --(bound)--> Service --(spawns multiple)--> Thread
You can get communication in top-down direction by directly calling public methods in the Service and Threads and down-top by broadcasting messages and receiving them in the Activity and Service.
Related
Short stated my question is: in MVP architecture is it a good idea to use a Service as
Presenter to control a Model implemented as Service ?
Alternative question: Is using a Service to control another Service a good idea ?
The context:
I am writing an app that communicates with a bluetooth sensor.
The app has a Service
(aka BluetoothService) that makes the connection and manages the communication with the sensor.
The app has several Fragments but just few of them are related to the operations that
the Bluetooth sensor does. A user should be able to start an operation, navigates to different
fragments and later watches the results of the operation(s) done by the sensor.
My purpose:
I want to write a component (aka BluetoothController) that makes the links
between the sensor (represented in my app by BluetoothService) and the rest of
the app. The BluetoothController contains Objects that described what kind of
operation has to be done by the sensor (only one operation, serial operations,
type of the operation, ...), so BluetoothController 's purpose is to let
the operations be independant to Bluetooth sensor and then be able to test the app
with a mock bluetooth class. I see BluetoothService as a model and
BluetoothController as a presenter, am I wrong ?
Why a Service:
Because it does not die if the user navigates between fragments
Because it is accessible through the whole app via bindService
Because bindService is the only entry point, I guess I can control that just
one operation is done at a time
Because I see Service as an active component, so it can keep on receiving data even if there is nothing bound to it
This service would be both started and bind (like a music player):
to be able to keep on running even if no components are bound to it,
to ease communication
All services would be in the application process to let communication be done
without binder but rather
method call.
Any suggestion would be highly appreciate , thanks in advance
Why not something else:
RetainedFragment are (for me) just container
pojo presenter are just gateway between views and models, they should die if
they are not attached to a view.
Conclusion
Am I wrong? Do you see difficulties in this architecture? Are there other Android
components that suits my purpose better?
Any suggestions would be highly appreciated, thank you in advances
I'm working on an Android app which controls some BLE enabled hardware. It also accesses a Server API and use location services.
The current app organises this as three different services: Location (system service), BLE service and Server service.
That means a lot of broadcasts coming to the GUI part of the app and a lot of logic in the Activity.
I would like to move more functionality into a background service for two reasons:
- Enable the background service to perform interactions with both BLE, server and receive locations while being in the background.
- Simplify the interface between the Activity and the services (also makes it easier to test functionality).
I would like some "best practice" inputs on what solution would be best:
1: Create an additional service which is the entry point for the Activity and which then starts and communicates with BLE, Server and location services.
2: Merge my server and BLE code into a single service and add locations to that?
I'm kind of leaning towards 2 to avoid too many broadcast being thrown around making things more complex even with the more functionality getting stuffed into one service.
Any thoughts? Any comments on several services communicating?
Thanks
I want to develop an Android application that satisfies the following specifications:
Record data from a sensor (for example the accelerometer) at an
approximate rate of 10-30 Hz.
Upload this raw data to a remote server (for example using TCP
sockets).
The user interface should be minimum, just a pair of buttons to start
or stop the recording and transmission of the data.
All the process should be unnoticeable for the user and keep working
when the screen goes off for several hours.
Battery life is not critical (it should last several hours).
Vision: I would like to analyse in quasi-real time the sensor measurements of a group of users without their intervention (apart from starting the application).
After some research, I could manage to perform these tasks separately and inefficiently. I've tried classes such as Service and IntentService, SensorEventListener, etc. I don't know if I should use Thread, Service or IntentService for each task. Specifically, I have serious problems to communicate them.
My questions:
What class(es) do you recommend to use in order to solve this
problem?
What task should be done on each of them?
If the tasks are performed in different entities (threads, services,
intentservices, etc.), how should I intercommunicate them (I'm
thinking about the recording and uploading tasks)?
I am asking for the best-practice structure to solve my problem. You do not need to go into details in terms of developing/coding the solution.
Thank you very much and feel free to ask if something is not clear enough.
David
UPDATE:
After some more research and thanks to DROIDcoder, I manage to design a skeleton for my app:
Main UI: Activity object presenting two buttons (start/stop) that
will launch a Service with the usual startService/stopService methods
Background: Service object
Awake when screen goes off: the service requests a power lock in onCreate() and releases the power lock in onDestroy(). Find more info here: https://developer.android.com/training/scheduling/wakelock.html#cpu
Log sensor values: implement SensorEventListener in the Service as usual
Upload sensor values to server: use AsyncTask in the service as described here: How to use AsyncTask
Data formatting and transmission: use GSON library + HttpClient as described here: How to send POST request in JSON using HTTPClient?
Testing: use the website http://www.jsontest.com/ to test the JSON queries
As this is only a proposition, I add it as an edition. I will post a detailed answer when the whole system works.
The questions remains: can you think about a better design for the application?
Thanks again!
Finally what I have done:
Issue 1: record data from a sensor on the background for a long period of time.
Solved using the class Service to initialize the sensor and listen for callbacks.
Issue 2: communicate the Activity class holding the UI with the Service class.
Solved using the startService(Intent myMessage) method from the Activity class combined with a switch in the onStartCommand() method from the Service class to classify the message.
Issue 3: communicate the Service class with the Activity class.
Solved registering a custom BroadcastReceiver in the Activity and sending Intents from the Service. I've used it to update a progress bar (in the Activity) during the file uploading (in the Service). An exceptional tutorial can be found here.
Issue 4: upload data to a remote server.
Solved using AsyncTask inside the Service like in this site.
here are my suggestion
Upload this raw data to a remote server
You can use JSON parsing for server communications. you will use AsynTask(Background Thread) for background data uploading
All the process should be unnoticeable for the user and keep working when the screen goes off for several hours.
You should use services for background long term processing
I'm a beginner in android development and I'm trying to implement an android udp client, which connects to a java server and sends/receives some packets from it.In this process it collects some data (like round-trip delay etc), which is used to measure the QoS of that particular network. I have tried implementing the connection and sending/receiving data using Java Threads, but the application crashes, and hangs if i try to use more than 2 threads. So I'm looking for alternatives. While going through this site as well as some other links I found that in android multiple threads can be implemented using AsyncTask, Handler etc. Also I found that the Service class also helps to run a background service in an app. Please suggest which approach among these would be the best to achieve my purpose.
Thanks in advance.
You can use AasyncTask to do this and as you mentioned service may be useful too, where u can let your application do whatever it wants in background , if user needs to use application by its interface then AsyncTask must be used to avoid Crashing
There is not one right answer that can be applied as a broad stroke to how to do Android multi-threading. There are a few different ways to approach it based on what your specific needs are.
Any long running, blocking call, in Android will result in the application crashing.
The most common solution is to use an AsyncTask though. For example, when I want to make a call out to a web API endpoint for some XML data within an Activity I would in this case use an AsyncTask and kick off the calls from within doInBackground.
This is not an appropriate solution though if the wait time is longer, or possibly an unknown wait time. Or in a situation where there will always be waiting such as a message queuing service. In this type of situation it may be best to write a separate app based on extending the Service class. Then you can send/receive notifications to/from the service from your primary application in a similar manner to how you would communicate with a web service.
I'm using pubnub as a publish/subscribe channel between an android app and a server.
Currently I'm thinking of how I will implement this.
I'm using the provided library for android (https://github.com/pubnub/pubnub-api/tree/master/android) but I think there will be some problems with the application lifecycle if I use it like it is now. (Correct me if i'm wrong)
I was thinking of implementing it as a service
What I want
The service has to keep on running until an hour (negotiable) after the last app usage. That's because we want to have notifications when a message comes in, but the app is not the currently used app.
How do i stop the service after one hour of non-activity of the app? Probably Android will kill it, but I want some control.
The Service must be able to trigger the app to change it's interface when specific messages come in (I was thinking of sending intents from the service when we receive a pubnub message?), pubnub will send data to the service, so I need a way to pass this data to the application (probably save it in a Bundle in the intent?)
I need to listen to multiple pubnub channels (max 2 at the same time), I think I will have to do this in multiple instances of this service?
I think I will do it like this:
Create a service that's started when the app starts
Let the service listen to a pubnub channel
When a message comes in, send an intent and use the intent filters
implement broadcasthandlers to listen to these internal intents
Is this the right way to do this? any hints?
You have an excellent set of questions an detailed points that I will talk about in this answer. You are using Android and you are interested in the conventions and best practices for PubNub Publish/Subscribe scenarios.
Your use case is very common and the best ways to build apps always vary dependent on application needs. However you definitely have the right idea and have asked all the right questions. You just needed some sample code and a direction to get started on implementing the specifics of your application needs. To define your needs in a list:
Connect/Disconnect Ability.
Always-on Background Service that can Send/Receive data and notify other apps via Android Intents.
Connecting to Multiple PubNub Channels at the Same Time.
So to get started I will provide you direct links to some examples and methods:
Create a Service that is Started when when Android Boots: https://github.com/pubnub/pubnub-api/blob/0dfd8028b803332f5641adc909b1a26f87bd7ff1/android/PubnubAndroid/src/com/aimx/androidpubnub/BootReceiver.java
UnSubscribe/Disconnect Example Code when you want to stop listening on a PubNub Channel: https://github.com/pubnub/pubnub-api/blob/0dfd8028b803332f5641adc909b1a26f87bd7ff1/android/PubnubAndroid/src/com/aimx/androidpubnub/MainActivity.java - Listening to multiple channels is easy by placing the blocking pubnub.Subscribe() method inside a Thread.
Regarding your thoughts - This IS the right way to do it:
Create a service that's started when the app starts
Let the Service listen to a PubNub Channel.
When a message comes in, send an intent and use the intent filters.
Implement BroadcastHandlers to listen to these internal intents.