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.
Related
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.
I have a use case where I want to download some files from the server and store them locally before starting another activity that is dependent on this file. This kind of design can be found on karaoke kind of applications where clicking on one song would
Load the required files from the server
Once the download is finished, open the required activity.
Let us assume that my app is a karaoke app. My question is how to design this flow. Basically, on clicking on one song, I want to show progress on the screen and when the download is finished, I want to move to the activity. Another requirement is that once I am inside the karaoke activity screen and playing a song, I have an option which leads to loading of another lesson. If a user uses that option, I want to again download the required files. Based on this requirement, should I:
Have the file loading thing as a separate activity?
OR
It can be used as Fragmentinside the activity where I choose a particular song. In this case, once entering the karaoke screen, if I choose an option which leads to downloading some files and reloading of this activity, is this the best design?
I would recommend two different approaches depending on how long you plan on keeping the data that you've downloaded. If it is single use than a bound service would be ideal. However, if you are planning on keeping the downloaded content for more than a single use, I would recommend you use a content provider and possibly a sync adapter(Depending on how frequent/predictable content downloading is). This combo would help guide you into not having to think about the 'design' as much(Since it is pretty standard at this point), plus it would provide a lot of features that you may/may not find useful: you can make your internal data 'public' via the content provider/authority(s), you can make an 'account' on the phone associated with your app so that the user can manage its syncing via the sync manager(actually via widgets/apps using the sync manager, but still), and most importantly a set of clean(ish)/standard means to interact with it/propagate UI, etc.
My simple version would be an Activity that spawns either a async-AIDL service with callback (which is in my opinion the only way to use a bound service) that would allow you to asynchronously design your 'starter' activity, its "currently downloading" spinner (which can get progress updates via the callback if you design it that way). Then once the download is complete then send the results (via a parcel file descriptor in the Intent's bundle) to the new activity that makes use of it.
However, if you are planning on using the data more than once, I'd recommend downloading the content like you did above, but then also store it in a content provider for easy access later. Providers also have a lot of nice associated functionality related to cursor loaders, etc. that will help keep a list of the content currently being stored nice and clean/up-to-date/dynamic/etc. However, this is a lot more work to setup once, then later it would save you time in reduced.
A sync adapter is best when the data to be downloaded is predictable, either based on user's account or temporally (such as someone having an account to download data from (email account, etc.) or when the target is fairly constant, but the data should be updated every hour or so(such as the current weather)). So this will depend a lot on your application's exact specifics.
Here is an assignment for an Android App Development course I wrote that is an even more simplified version of the first option (it has intent service + broadcast receiver for returning download results back to the Activity). Obviously since this is an assignment it has sections cut out to make skeleton code, but the documentation is ABSURDLY detailed and should be fairly easily implemented.
https://gitlab.com/vandy-aad-3/aad-3-assg-2/tree/master
Here is the extension of that assignment for that same course that focuses on implementing a simple content provider's 4 main methods (Create, Read, Update, & Delete). Everything else about the provider is given to you.
https://gitlab.com/vandy-aad-3/aad-3-assg-3/tree/master
Obviously the content being downloaded in both applications is probably not what you intended, but that is a simple swap to replace in what you do want.
Not to shill to hard, but here is the (free) Specialization that this course is a part of: https://www.coursera.org/learn/androidapps
Point one : Don't download video file within the Activity level. You can start a Service to handle it. Once the download function is finished you can start the second Activity. While download function is in progress you can show a ProgressBar
Point Two : Best Design is show a ProgressBar with percentage to user. Or disable the function. After download complete enable or start the second activity.
I am currently assigned the task to research and implement two Apps that do the following:
App A writes some content to a buffer/register of some sort
App A terminates
App B starts and reads the Buffer
The Apps are not supposed to run at the same time.
First of all I don't know which possibilities I have.
I came up with the following:
Write to a File
Write to some shared memory range
Are those two options possible and do i have to grant App B the right to access the file or memory range?
Furthermore i am supposed to check network sockets for usage as "buffer".
I know that would go against everything that is supposed to be done but this is expected!
I was trying to use a DatagramSocket because i can open up that kind of socket, send packets over it, close the socket and terminate the App.
I thought there would be some system buffer holding the packets until someone calls receive on a DatagramSocket with the same port.
Would that even be possible or will the system throw all packets away when nobody is receiving them immediately?
There is a class in the android API that was created specifically to allow you sharing data between different applications - the ContentProvider.
You should create a ContentProvider that will be in charge of the data (I recommend using the SQLite database to store the data), and both apps can use that same ContentProvider to access and/or modify the data.
It does not matter in which of the apps the ContentProvider resides, but probably best it is in App A since it is the one creating and modifying the data.
See this great guide on how to create a ContentProvider:
http://developer.android.com/guide/topics/providers/content-providers.html
I am new to Android. I’m attempting to write an application which will display multiple pieces of information about open stores. I get that information using a RESTfull API which passes JSON data.
Here is my question: What is the best service/threading implementation choice?
Here are my product requirements:
• I want to encapsulate all the API and JSON into a class that one or more Android “Activities” can call. I think this might dictate a service but this service will only need to run when my application is running and will not be accessible by other applications. The user will be required to authenticate into the remote system via the RESTfull API.
• It will have to be on a separate thread because of the possibility of the API calls taking too much time. I don’t think it will need to be multi-threaded since I don’t see more than one “Activity” will be interfacing with the service at a time.
• The service should look at caching some of the information it gets back so that when an “Activity” makes a call (“GetStoreList” for instance), it could return a list of stores it already queried earlier. I’m not sure if I should keep this information in memory or try using the SQLite functionality in Android. I could have several hundred stores in the list with ten to twelve other pieces of information associated with each store. Some of this information would be displayed in the “Activity” list view and some won’t. Since I don’t have any experience with SQLite, I’m not sure what the performance cost would be over storing the information in memory.
• There will be about a dozen or so methods that the service will need to encapsulate. For instance: once I get the store list, I may want to call the API again to find out if the store is currently open. Some of the information passed will be custom classes and therefore would require “Parceable” class definitions if I have to use IPC’s as part of my solution (if I understand the Android documentation correctly).
• I would also like to “Lazy-load” the list into my “Activity” so that I don’t have to wait for the full list before updating the user interface.
Possible Solutions (this is all guessing, so please don’t crucify me… that’s why I’m asking the question):
I could use a class extended from “Service.” It would have to handle the threading itself so that long internet calls via the RESTful API wouldn’t hang the system. Alternatively, I could do the thread manipulation first and call the API with the assumption that I can take as much time as I want. I think I would need to implement communication between the “Activities” and the service via IPC’s. This seems a little complicated to me. I’m not sure if I can use the “Messenger” class. It looks easier than the AIDL stuff.
I think I could use an “IntentService”. This would automatically create a separate thread and queue messages/tasks. I think I could communicate with the service (to get the lists of stores for instance) by “Binding” to the service. The problem I see is passing data back and forth and I’m not sure how I would cache the data between calls to the API since the service terminates after making the API call.
Anyway, I’d rather learn from someone who has already done this type of app instead of doing it the wrong way and coding it twice.
Thanks for the help.
AbstractThreadedSyncAdapter was made just for stuff like this. There's a fairly comprehensive (but complex example) here. Also, one of my favorite Google IO videos gives a pretty good overview of how to use it.
Your scenario is almost exactly the same as ours in my previous project. Here's what we came up with (I'm sure it's not original, but is patterned from one of those google io videos too)
A Service handles the request-response of RESTful calls to the server. This is triggered by the activity calling startService(Intent) that includes the parameters in a Bundle included in the intent. The Bundle contains information as to what API will be called, and what parameters are included.
The Service doesn't directly pass the result to the activity - instead it writes the result to an sqlite database. The activity will know that the transaction is finished by observing the db (via ContentObserver). Similarly, the Service can notify the activity once a transaction is completed via broadcast; the activity can catch this by registering a BroadcastReceiver - however the resulting data should still not be directly passed to the activity via Bundle, as there may be cases where the data is too large for the Bundle to contain (there's a limit for the length of a String that can be included in a Bundle) - you still want to put the result in the Provider. The activity should query for the data as soon as the Service notifies the activity that the result is there.
Additionally, you can include a "success" or "fail" flag in the Broadcast that the Service will throw for the Activity, so it will know if it still needs to query for result - this removes an additional overhead for failed transactions.
If you need to ask, No we didn't use AIDL for this architecture (but we did use it on another module that does facebook/ym chat over xmpp).
The "lazy-loading" I think can be asked in a different question, as it is an entirely different process.
I just started doing my first Android app which happens to be an RSS Reader. I did a bit of googling about this but haven't seen a clear reference though. What I want to do is cache my xml file (the feed file) to the sdcard so when the phone is offline, the user can still view the feed by automatically telling the application to look for it when no network is detected. What I have now is the mechanism to cache the image but I wonder how to use this for other files since it was specified only for images that converts it to Bitmap using the HashMap().
I think the preferred way is (just as Umakant Patil commented on your question) to store data in an SQLite database. You would typically write a background service which every now and then refreshes your database with the server side data. Your application will always read only from your SQLite database. Note that the service and the application will typically live their own lives, independently from each other (your application will never communicate directly with your service).
This procedure is also somewhat safer from an architectural perspective. Your application will never depend on network connectivity or timing issues due to network traffic. It will only rely on data and database access on your local device.
TIP #1:
You could pass an entry to the AlarmManager which will wake up your service at a given interval. Your service will synchronize your database with the RSS source and then kill itself (saving resources is always good :-)
There is a good example of Services in Android here: http://developer.android.com/reference/android/app/Service.html
And about Content Providers here:
http://developer.android.com/guide/topics/providers/content-providers.html
TIP #2:
Note that you don't necessarily need a content provider to communicate with your database. The content provider is good to have if you wish to "standardize" your database communication. Perhaps several components of your application need to access it or even several applications, then it's good to use an already defined "de facto standard" way of accessing the database.