I need to implement some async client in android app for communication with external device. I need this client to start connection with specified socket on different thread and then implement some methods which will be sending data to external device, all this methods need to be asynchronous. What is more I need to have guarentee that Android won't kill my process.
This client needs to be working w Dependency Injection. I would like to create single instance of this client being injected and used across many activities.
What I took into consideration is:
AsyncTask - heard that it is for only short tasks
Thread - I am struggling with implementing other methods despite run which will be asnychronous and able to be called
Service - I can't make it asynchronous
ServiceIntent - I am not sure if it is the best pick for implemeneting async methods.
I need your suggestions which way would be best with simple explanation why.
Related
Binders are used for Inter(not intra) Process Communication/Remote Method Invocation so why/how the communication between Activity and Service is possible via binders where there are no different processes involvement.
When the very first component of an app is initialized a request to the kernal is triggeres (I think via ActivityManagerService(Native)-AMS > AMN) (running in system_process) for a new process fork if no corresponding process exists. Once the process is created then any other component (say a Service) belongs to the same process unless specified. Now this service wants to communicate to an Activity of the same process. Then why IBinder is one of the option?
Doesn't that violate the underlying principle on which Binders are created?
Interprocess communication is done by writing data to some source such as a socket or pipe, and another process reading it. There's no reason that the same process can't read and write though- it's less efficient than other means of passing data within a process, but it still works.
As for why would you use it in the same process- the alternative would be for Android to have two ways of communicating with services, one way for if they're the same process, and one way for it they aren't. That would complicate things for the framework for minimal gain. It would greatly complicate things for Services where the client may or may not be in the same process (say a service that is used by both the client app and other apps by the same company). So they just use the same method for both.
Binders are intended to be a construct of an IPC - this is true but, if used in the same process to communicate between an Activity and a Service, there is no performance cost, i.e, it is converted into a direct call instead of an RPC.
Don't assume that Binders will only be used for IPC but it is a general purpose communication mechanism in Android.
You won't find this documented normally anywhere. I found it in one of the discussion between Commonsware and Dianne Hackborne(designer of the binder concept in the Android team).
I would like to separate My app ( client side ) to two different independent services.
The main app ( run the user views and a bit of functionality ) - written in Java
"back-end" ( encrypt and upload to the cloud ). - what i want to start writing.
My wish is to create a communication channel between the 2 services.
Main app will collect data from the user.
the data will be transfer by inner protocol communication to the second service.
the second service encrypt the data and upload to the cloud.
Both services locates in the client side
What is the best practice ( if it possible ) to create the desire architect?
what is the prefer communication protocol?
will appreciate any link/advice
I'm not sure what the problem you're facing is exactly, but I get that you want to divide concerns. I'd suggest having two packages, one that controls the UI and one that handles API requests. When you want to send a request, you just call a method in the API class you created and pass your data as a parameter.
Concerning the API, I'd suggest working with the Retrofit library. It does most of the heavy lifting for you, and It's easy to implement.
Other than that, make sure you know when to use the term "Service" in relation to Android.
A Service is an application component that can perform long-running operations in the background, and it doesn't provide a user interface. Another application component can start a service, and it continues to run in the background even if the user switches to another application.<
Documentation
I want every app to be able to send data to my service. Therefore I need inter process communication. Every page I can find proposes to use Messenger, AIDL or Intents (BroadcastReceiver). So far what I could figure out by building some test apps is that BroadcastReceiver is extremely slow and messages can get lost without notification if sending with multiple threads inside while(true) loop. AIDL and Messenger are not only complicated to implement (service is needed, binder,...) but can provide strange behavior for example when sending with multiple threads resulting in RemoteException (!!! FAILED BINDER TRANSACTION !!! ) with AIDL just when using oneway keyword. I want to ensure that delivery is guaranteed. Is there even a reason to use oneway when delivery should be guaranteed?
Nevertheless, LocalSocket seems to be extremely easy to use (no need for a service, works just like java socket). Client apps could just open a LocalSocket, connect to the provided address and then while(true) outputstream.writeObject();
Are there any downsides when using LocalSocket because the android developer page says "Some apps attempt to implement IPC using traditional Linux techniques such as network sockets and shared files. We strongly encourage you to instead use Android system functionality for IPC" but does not further comment on this
Are there any downsides when using LocalSocket
There is no security at the framework level for LocalSocket. While you may "want every app to be able to send data to my service", the user may not, which is why standard IPC can be protected by permissions.
startService() and bindService() will cause an instance of your service to be created, even starting a process for you, if needed to handle the request. Your service will not be running all of the time. So, you need startService() or bindService() anyway.
AIDL: Using AIDL is necessary only if you allow clients from different applications to access your service for IPC and want to handle multithreading in your service.
Binder: If you do not need to perform concurrent IPC across different applications, you should create your interface by implementing a Binder.
Messenger: If you want to perform IPC, but do not need to handle multithreading, implement your interface using a Messenger.
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.
to understand the AIDL in android, i want one real life example, means the at what scenario of development we need to use AIDL.
by reading the Android Docs ... It puts me in confusion and so many question, so it is hard to read whole doc for me, can anyone help me
is it for communicating with outside the phone.
or to communicating with different apps, (why we need to communicate with other apps)
what kind of service they are talking in docs
AIDL is used for Binder. Binder is a mechanism to do RPC calls on/from an Android Service.
When to use AIDL? When you need a Service. When do you need a Service? If you want to share data and control something in another application, you need a service using AIDL as an interface. (A Content Provider is used when sharing data only).
Services can be used within your application as the model roll in the MVC-pattern.
AIDL is Android Interface Definition Language. This basically allows you to do IPC calls.
Use: There are situations where one process would need to talk to other to obtain certain information.
Example: Process A needs info of Call status to determine whether it needs to change Call Type (for example Audio to Video Call or Vice-versa). You may get call status from certain listeners but to change Call type from Audio to Video, Process A needs a hook to change. This "Hook" or way of changing calls is typically part of Telephony Classes which are part of Telephony Process. So in order to obtain such an information from Telephony process, One may write a telephony service (which runs as a part of android telephony process), which will allow you to query or change call type. Since Process A(Client) here is using this remote Service which communicates with Telephony process to alter call type, it needs to have an interface to talk to service. Since Telephony service is the provider, and Process A (client) is the user, they both need to agree on an interface (protocol) they can understand and adhere to. Such an interface is AIDL, which allows you to talk (via a remote service) to Telephony process and get some work done.
Simply put in laymen terms, AIDL is an "agreement" Client gets, which tells it about how to talk to service. Service itself will have a copy of that agreement(since it published for it's clients). Service will then implement details on how it handles once a request arrives or say when someone is talking to it
So process A requests to change call via Service, Service gets the request, it talks to telephony process(since it's part of it) and changes call to video.
An important point to note is, AIDL is only necessary for multithreading environment. You could do away with Binders if you don't need to deal with multithreaded arch.
Another real world example is Google Play License is using AIDL.
I have the same thinking about an example of AIDL, it's very difficult to find an idea to make an example app which uses AIDL. Then I have an idea about it create a LocalLogServerApp. Maybe it can not become a production app but it still shows some value in using AIDL
The main function of this app is
Receive the local log from other local apps (another app need to implement AIDL to send log)
Save the log to datastore
Display the logs
Maybe do something with the local log (eg: search, delete)
Maybe notify developer when error log happened
The benefit of this app
The local log can use when you have some very strange issues which sometimes happened in a few moments and in some specific device. In this case, common Log won't help, debug won't help, Firebase Log may help but Firebase receive log from multiple device.
Reusable, many apps can use it with less code
Hope you find this idea helpful to find another better AIDL example
https://github.com/PhanVanLinh/AndroidLocalLogServer
https://github.com/PhanVanLinh/AndroidLocalLogClientTest
1 - is it for communicating with outside the phone.
Its communicating with outside the app.
2 - or to communicating with different apps, (why we need to communicate with other apps)
As #GodOnScooter mentioned, when your app communicates with telephony service which is actually an other part.
3 - what kind of service they are talking in docs?
This is a service which runs in different process of a system, To bind to this service you need IPC(inter process communication), AIDL is used to implement this.