In an application that I am developing I have a main Activity that starts one Service (it is a floating window, I am using StandOut library). The same application contains a class that extends InputMethodService, I'd like to make them communicate, since I want to handle some Events in InputMethod calling methods contained in instances of classes created inside my StandOutWindow. I tought to use SharedPreferences, is this a good way or are there better ways to make them communicate?
I think you must use bindService to communicate with your service
http://developer.android.com/guide/components/bound-services.html
To communicate with your InputMethodService you can follow this tutorial:
http://android-developers.blogspot.com/2009/04/creating-input-method.html
And to comunicate between services:
Android communication between two services
Related
I am creating an application for Android which I want to turn into a library module and use its own logic as a common logic for several other application which differs in their UI. The library module got an Android service which can receive and send commands to a listener which is defined in the application itself (in my case in the main activity).
On the receiving side, The listener is the main activity of the application which then invokes callbacks according to the type of message from the service.
The issue is more with the sending commands to the service part. The API in question is the way of the application to send messages to the service. It simply gets the argument of the message to send and pass it along to the service.
The way I thought of doing it is making the library's main activity as the API which will allow both the sending and receiving events. The developer of a UI using this library will then simply need to make another module for the GUI alone, and make his main activity extend the library's main activity, thus being able to use the API and extend the listener's behavior.
What I want to know is possible technical issues, and not an opinion if the design itself is the best possible or not - Is there a problem with this design? For example issues with Android disposing of the activity? Any other issues?
The main risk with building your APIs based on the Activity is that you are basically tying your API to the activity lifecycle, I assume an API like that for messaging should be available on both the main and UI threads. I prefer using interfaces for designing API's. Dagger is very helpful for creating singletons which can be injected anywhere.
I want to use an ActivityRecognitionClient and a LocationClient in the same Activity. The trouble is that either calls onConnected.
I would like to use both e.g. to write the location and the recognized activity to a database.
I thought that should be a rather easy thing to do but could not find out how. Hope someone can help.
UPDATE
I use Services now instead of Activities and implement the clients separately, connecting when the service is started and disconnecting when it is destroyed.
The same activity cannot implement two methods with the same name from different interfaces.
This is well explained here Java - Method name collision in interface implementation
You might want to make separate classes implementing each interface separately and call your methods to read/write to your database from both of them.
I have 3 activity, and all of them must synchronize user information .So I'd like to create a kind of Service.It must be running all of the time, even before root Activity is shown, and until the app is closed. The 3 activity communicate to the Service and to get user information and change user information. What kind of Service should I use, and how to create it?
Don't know why you need a service.
What you need is a single DAO that handle all the CRUD opertaions on the data, and each on of the activity will use the same instance of the class for access the user information.
Sounds like you need to use a bound Service. You can use bound services to communicate with activities. Here is the link to bound services documentation: Bound Services
I've got a little gap in my knowledge here and I want to make sure I do it right before writing all the wrong code.
I have an Android app that extends Application to set up some core functions for a TCP client. There are a few different Activity screens that should interact with Application. What I'm stuck on, is what to do when a data packet is received by Application. I want to relay it to the currently-visible Activity, whatever it is.
Coming from a C# background, I'd just create an Event in the Application, and simply subscribe to that event when an Activity is created. But I'm getting confused with Java Listeners, Handlers, ...
What's the best way to go about that? Should I be doing a Service instead? (But I don't really care if the TCP connection is killed when the app is not shown.)
I would go with a LocalBroadcastManager (documentation) approach.
Create one of those puppies in your Application class, and register/unregister your Activity objects in onStart and onStop. See Context.registerReceiver. Note that this requires using Intents, which might be too restrictive/heavy-weight for your application; packing/unpacking data can be a chore.
Alternatively, you don't have to use any specific android class to do it--just keep track of what Activity your program is in by calls to your Application in onStart and onStop. Might help clean your code if you make all of your activities-of-interest extend a subclass of Activity that contains this logic.
Under what circumstances would using AIDL to define a service interface be the correct decision (rather than just creating an extension to the service class)?
You need to use AIDL if you want a class outside of your application's process to access the Service. If you're only using the service from inside your application, you can use a local service.
Merely extending a service class will not allow your service to expose its methods to outside entities. If you want your service to be exposed/used by code which runs out of your android app, you will have to define an AIDL for it. This AIDL will be shared and be formed as contract for your service. Refer this http://developer.android.com/guide/components/aidl.html.
1.when to use aidl based service.
A few benefits can be gained by segment part of your code into backend service:
decouple front-end and back-end
memory/cpu intensive processing can be stacked to backend service, GC in service will not affect front-end user experience
service crash will not bring down the whole APP
2.how to create such a service
I have written a good library, you can refer as an example http://github.com/zhchang/hogwarts
AIDL
The Android Interface Definition Language (AIDL) allows developers to define a programming interface that the client and server use to communicate with each other using Inter-Process Communication (IPC).
This article shows how to connect to a running service in Android, and how to retrieve the data from the remote/running service.
Example of IPC mechanism
Let RemoteService be a client service and RemoteServiceClient be an Activity to communicate with the remote service.
One service provides information about the mathematic operations like addition, subtraction, and multiplication for the given two integers. To expose the functionality of what Service can do, create an .aidl file in the project directory.
AIDL Example