Before i ask my question i will first explain some background information.
Our company is developing an app for iOS and Android. Our customers can decide to use our app (branded) or integrate our functionality into their app. As our app has some complex algorithms and communication protocols on-board. For this reason we want to provide a kind of SDK for our costumers who wants to integrate instead of using our app.
As we use BLE, NFC and GPS, we decided to make our own apps native. The issue is that many of our customers already have an app which will be a hybrid app in the most cases. So "just" making an SDK for all platforms is almost impossible, not only to build but even more to maintain.
Another important thing to keep in mind is that we want avoid that our customers need to understand our complete communication process, even stronger we won't give our algorithms or communication protocols to others because this is what makes our app/product unique at this moment.
So now the concrete question. Is it possible to provide our functionality as a kind of API so other apps can use the functionality of our app like a kind of API? This means that our app needs to be installed also on the end users smartphone but they don't need to use it individually. The idea is that the app of our customer communicates with our app like an API, our app does the communication with our hardware and gives back the result to the app of our customer. Note that user of the app should not see our app in foreground. (I have the idea from some games who requires "Play Games")
I know there is a way to exchange data between apps (Inter-App Communication) but can this also be used like kind of API?
Obviously this answer relates to Android only. (You may want to ask a separate question for IOS)
At its most basic, a Content Provider is used to exchange data. However, nothing prevents code being run in the provider host to extract that data.
For example, You can host a Content Provider in your app which when called with specific parameters, performs a number of your complex functions and returns a simple table of data (MatrixCursor) or even just a simple True/False response within that cursor.
You could further simplify the usage of this by creating an Android Library that your customers could import into their own project to make it more friendly and API like by adding methods and functions to the library that then delegated their calls to the Content Provider or even to a Broadcast receiver in your main app which could then respond with its own broadcast.
You could even make use of invisible Activities. i.e Call an activity in your app that has no UI.
Even more preferable would be to create your callable code as a self contained library that your customers could use which would negate the need to talk to separate apps completely.
In my understanding, you need other apps to invoke a particular functionality, say call a web API or open an activity and write something or open a popup dialog and do something.
In android: Yeh, it is possible by BroadcastReciever. you only have to listen to the particular action and perform the functionality.
So the task is, you only have to supply the action.
Related
I'm newbie in Android services and I need some help. I'm trying to understand the google's guide, but it really lacks lot's of information and i hate the fact that google automaticly translates to my language and doesn't allow me to DENY it, so i cant quote it here.
https://developer.android.com/guide/components/services
I've an app that perform long tasks on background, so I do understand that i need a service to achieve that since activities and related thread or resources might be killed by android when the app goes background.
My service monitore some stuff from user social media so i do need to use social media Apis to contact with their server. To make things easier i wrap the social media apis into one facade and my service deals only with that facade. this facade is a singleton
the user logs in-> the service starts to run in background -> at certain point the user leaves the app now starts the problem...
after the user left the app, my background service keeps running: OK
all its fields still aren't collected by GC: OK
but the inner fields of the facade singleton get released by GC and at certain point my service call singleton (not null) which calls some field that now is null: PROBLEM
how can i deal with that? how can i force android to keep those fields (aren't many) alive because they are being used by my service
PLEASE- do not ask me to make them parceable or something like this... it is a third party api i cant change
I am looking for options around creating a multi-platform application that will react to a HTTP call made to it. To explain my situation:
I have software running on client machines which is capable of making HTTP requests, specifically passing information via GET;
I can adapt the software to accept a manually inputted IP address and any other information (such as authentication tokens) but not really change the comms method;
The requirement is that this software can pass small amounts of information, on the fly, to an app running on a smartphone;
I'm able to specify networking restrictions, such as being on the same local network etc;
It's not really viable for me to create a server to sit between the app and the client.
My thinking is that I could create a simple app to effectively act as a server, sitting and listening for a HTTP call and acting on the information passed to it.
Phonegap crossed my mind purely for the cross-platform capability; Ultimately, if it needed to be native development, whilst not preferred, it is an option.
Everything I've found on the subject thus far is either specific to a platform, usually with no alternative on competing platforms, or is reliant on the app as a client or an intermediary server handling the connections.
My question is, is such a thing - effectively setting up an iPhone or Android device as a server with a listening port - actually possible in Phonegap, or at all?
I appreciate that there are some (very valid) security concerns with the above approach - additional controls will be put into place to deal with that, right now I'm at the beginning of the search and looking to see which is the most viable way forward.
I would have to say that your approach is a bad idea. You have to keep in mind that the OS can kill your app if it is in the background any time it feels like it. I would look more into using a push service to send the app any updates. That way, even if the app was killed, when the user opens the app it has the latest info. My 2cents.
I'm just starting android development after many years of .net development. My begginners book doesn't make it clear what the difference is between a service and a content provider.
first it claims a service is a long running app which exposes it api other applications on the device. This is what a windows or a web servie would do on a pc
But then it states a content provider for the "Contacts" application exposes an API to other applications running on andriod so they can iteract with it. This is exactly what a service does. The both do the same thing. The both allow other apps to interact through their api. So what is the difference. Please point me in a a direction where i can read a more logical description of these two functionsl. As this appears to be just nonesense.
An Android service is something that runs without a user interface (in contrast to an Activity). Often said to be running in the background. This does not mean that it runs on a separate Thread though.
A content provider is a database abstraction layer. It implements CRUD not necessarily on top of a sql database. Most of the times it does. It is a defined interface to access the data behind it. Often recommended only for clients that are in separate processes than the data. I find it useful for inner application data access too.
Services are documented here and content providers here.
I am writing an Android application that interfaces with a RESTful service. This web service essentially fronts a file system, and provides metadata as well CRUD access to the files. My application retrieves the metadata, and exposes it to 3rd party apps through a ContentProvider.
I need to add the ability for 3rd party applications, running on the same device as my app, to CRUD the actual files by making requests to/from my app (not directly with the server). This means they need to either send or receive the contents of the files (which are typically XML or images) through my app.
I have thought of two approaches for implementing this:
Option 1 - Using ContentProvider.openFile
This seems like an obvious choice for giving 3rd party applications the ability to read files from my ContentProvider. I think it starts getting tricky when those applications need to create or update files through my `ContentProvider'. I'll need a callback when they are finished in order to know when to send the new/changed file back to the server. I believe I could use a FileObserver for that purpose though.
Option 2 - Using a Messenger through a Service
With this approach, I can send the files between my application and client applications through the Messenger. The files would have to be passed through a Bundle, so I am not sure what the best format is for transmitting them (File, FileDescriptor, byte array, something else??). I don't have a good handle on whether or not this would cause problems if the files get to be large.
Option 3 - a hybrid approach
Use folder(s) on external storage as a drop box
Communicate CRUD requests, and drop box contents, through a Messenger/Service
Use the ContentProvider to store the status of requests
3rd party app receives status updates through a ContentObserver
Summary
I think using ContentProvider would be the ideal solution, but it seems that the API does not fully support my use case. I am concerned that trying to go down that path might result in a kludgy implementation. If I go with a Messenger and Service approach, I am uncertain of the most robust way to transfer the files through a Bundle.
The hybrid approach seems pretty robust, but the most complex to implement. Files aren't actually being passed around, so performance should be good. However, I fear this is over-architecting the solution.
What is the best approach for transferring files between applications running on the same Android device? Of course, I am open to other options which I have not outlined in my question.
Content provider is definitely the way to go. If you consider that google uses this approach for almost everything then it becomes appaentr that this is the intended design method.
I'm not extolling the virtues of them, but in the land of the blind, the one eyed content provider is king.
Update
There is an example of how to do this in CommonsWare book, see the link provided.
Source of Content Provider/Files
Use the synch framework for content providers. Simply maintain a list of requests and then schedule the sync to download those file. You can also do this on network tickles etc. you can use broadcast intents or contentobserver to notify clients that the file is downloaded.
In essence this is probably similar to your 3rd option but importantly it uses the Android supplied tools rather than rolling your own.
Ad Endum
Best place to start is the android SDK sample in: android-sdk\samples\android-8\SampleSyncAdapter but be warned that there's a load of contacts related stuff that masks the juicy bits. It took me a while to figure out that I could delete almost all of it except the syncadapter
http://developer.android.com/reference/android/os/ParcelFileDescriptor.html can be sent between processes. I believe that there is a subtly where these are explicitly blacklisted from being allowed to be put in intents. They can be sent through AIDL though.
Also, do NOT use the sdcard for this. This is just asking for trouble. One sdcard is world readable, so anyone can see it. Also, you do not always have access to write to the sdcard (it is removed or put in UMS).
Using the SD card is definitely the recommended way to go to share files on Android.
However, I would go with a modified hybrid solution which makes use of startActivityForResult() and onActivityResult() (docs here) on the client side to communicate CRUD requests (and getting the Uri to the file(s) on the SD card if needed) if you don't mind creating a dummy activity as a front end to your service. Clients, once finished with the file(s), can call startActivityForResult() again to alert your app to changes.
Of course this can be done with startService()/bindService() however it doesn't provide an easy way for clients to obtain a status result especially if you need IPC.
Although content providers/resolvers feel like the correct way to go about things, I do feel it is more for single direction requests specific to providing/consuming content.
I'm writing an app, that has a somewhat modular system. It has a core app, and some apps, that consist of a single Service, that implements the desired interface. I followed the guide to create the IPC communication. But now I need to get all the services, installed on the system, that my core app can wotk with. How do I do this? I mean, is there any way to mark my Service apps with some kind of a tag, and then filter results, presented by the PackageManager#getInstalledPackages() based on that tag value? What's the common practice of doing so?
Create a custom Intent to which your activities will respond. You can then use PackageManager.queryIntentServices to get your list of matching services. You can get the package info, etc. from the information embedded in the ResolveInfos.
Ideally you'd actually use these intents for invoking the services, but you could always just use them as identification tags and fall back on the binding mechanism you were using before.