I'm developing an app for a company and I need to integrate it with Google Drive. I can't use the native API because the company has files not created by the application that needs to be handled, I need the full drive scope, so the REST API is what I must use.
Here's the problem, the tutorials are not basic enough for me to get started since I only have a very basic understanding of JSON and REST.
The tutorial: https://developers.google.com/drive/web/integrate-create
As I understand it I need to create JSON in my Java code and then pass that through the example code?
JSON
{
"action":"create",
"folderId":"0ADK06pfg",
"userId":"103354693083460731603"
}
JAVA
public class State {
/**
* Action intended by the state.
*/
public String action;
/**
* IDs of files on which to take action.
*/
public Collection<String> ids;
/**
* Parent ID related to the given action.
*/
public String parentId;
/**
* Empty constructor required by Gson.
*/
public State() {}
/**
* Create a new State given its JSON representation.
*
* #param json Serialized representation of a State.
*/
public State(String json) {
GsonBuilder builder = new GsonBuilder();
Gson gson = builder.create();
State other = gson.fromJson(json, State.class);
this.action = other.action;
this.ids = other.ids;
this.parentId = other.parentId;
}
}
The problem is that I have no idea how to create JSON nor do I quite understand how to use the JSON when created to do things like create files and query for files.
If someone can get me as far as creating an empty file in a users root folder then I can probably take it from there, but I could really use a nudge in the right direction!
Assuming, that you're talking about an Android app, there is no need to create JSON. The Java REST Api is quite easy to use on Android. If the official docs and the examples do not suffice, you may look at this demo. It is a bit more complex that needs to be (in order to maintain compatibility with the GDAA version), but with a few simple steps, you may simplify it.
I certainly can't copy all the code here, but you can just snatch the REST class, supply a GooDrive account to setSelectedAccountName() (or omit the method and let the service handle it) and simplify the connect() / disconnect() methods. The connect() method (for compatibility with GDAA) should be) replaced by a try/catch construct like this:
com.google.api.services.drive.Drive mGOOSvc;
...
try {
mGOOSvc...execute();
} catch (UserRecoverableAuthIOException uraIOEx) {
// standard authorization failure - user fixable
} catch (GoogleAuthIOException gaIOEx) {
// usually PackageName / SHA1 mismatch in DevConsole
} catch (IOException e) {
// '404 not found' in FILE scope, still, consider connected
if (e instanceof GoogleJsonResponseException) {
if (404 == ((GoogleJsonResponseException) e).getStatusCode())
mConnected = true;
}
} catch (Exception e) {
// "the name must not be empty" indicates
// UNREGISTERED / EMPTY account in 'setSelectedAccountName()' ???
}
anywhere you find the '...execute()' method in the REST class in order to catch sudden loss of authorization, etc... (can happen anytime). Otherwise, I've been running this CRUD implementation for some time and never experienced problems.
One general note about the REST Api. Since it is 'network state dependent', I would recommend to disconnect it completely from your app's UI and run it in some type of sync service invoked when there is an active network (WIFI, cellular) traffic. See the network related episodes here.
Good Luck
Related
We want to add a reporting feature to our existing application.
For this purpose we are sending Events in JSON via HTTPS to a server application.
We need to remember Event-objects that could not be send to the server (No internet, server not reachable...). We are considering to store the events in a SQLite database and discard all Events that are older than 24 hours to prevent flooding our storage.
Another option would be to write the JSON-objects to a file and concat each new event when it could not be send to the server. The problem with this solution is, that it would be hard for us to discard logs older than 24 hours.
We store the event sin a table with the columns:
| id | json | created_at |
Can anyone recommend best practices for this use case?
Currently we tend to use the sqlite solution but we are wondering if there are any caveats that we are not aware of.
If you don't mind using third-party lib i can recommend android-priority-jobqueue. You can easily achieve what you are trying to do. You can always create job and it will handle itself. You can set if it needs network, if it is persistent (saved into DB when no network) and even you can customize your own retry logic.
Here's little example.
public class PostTweetJob extends Job {
public static final int PRIORITY = 1;
private String text;
public PostTweetJob(String text) {
// This job requires network connectivity,
// and should be persisted in case the application exits before job is completed.
super(new Params(PRIORITY).requireNetwork().persist());
}
#Override
public void onAdded() {
// Job has been saved to disk.
// This is a good place to dispatch a UI event to indicate the job will eventually run.
}
#Override
public void onRun() throws Throwable {
// yours code here
}
#Override
protected RetryConstraint shouldReRunOnThrowable(Throwable throwable, int runCount,
int maxRunCount) {
// An error occurred in onRun.
return RetryConstraint.createExponentialBackoff(runCount, 1000);
}
}
And you call it like this.
jobManager.addJobInBackground(new PostTweetJob("It works"));
use JobService(Android 5+ - lollipop and above) and AlarmManager (for android sdk<21 - pre lollipop) with this solution u can schedule any task and it would be performed. JobService was developed rxactely for tjis purposes(schedule and perform different tasks) maybe you can try JobIntentService it is would work on kitkat(android 4+) devices
P.S.
In that case you didnt need any third party libs and other dependrncies like firebase/google play services(like for FirebaseDispatcher)
Running the code below, I create a folder with Google Drive Android API on a tablet. After a few seconds, delete that folder from a remote location on a PC. When I re-run the code, the API still thinks 'MyFolder' exists, even though it was deleted and not visible in the Google Drive app on the tablet. The folder persistance finally disappears after a while and the code works as expected. Is this expected behavior for Cloud drives?
Query query = new Query.Builder()
.addFilter(Filters.and(Filters.eq(
SearchableField.TITLE, "MyFolder"),
Filters.eq(SearchableField.TRASHED, false)))
.build();
Drive.DriveApi.query(getGoogleApiClient(), query)
.setResultCallback(new ResultCallback<DriveApi.MetadataBufferResult>() {
#Override
public void onResult(DriveApi.MetadataBufferResult result) {
if (!result.getStatus().isSuccess()) {
showMessage("Cannot create folder in the root.");
} else {
boolean isFound = false;
for(Metadata m : result.getMetadataBuffer()) {
if(!isFound) {
if (m.getTitle().equals("MyFolder")) {
showMessage("Folder exists");
isFound = true;
}
}
}
if(!isFound) {
showMessage("Folder not found; creating it.");
MetadataChangeSet changeSet = new MetadataChangeSet.Builder()
.setTitle("MyFolder")
.build();
Drive.DriveApi.getRootFolder(getGoogleApiClient())
.createFolder(getGoogleApiClient(), changeSet)
.setResultCallback(new ResultCallback<DriveFolder.DriveFolderResult>() {
#Override
public void onResult(DriveFolder.DriveFolderResult result) {
if (!result.getStatus().isSuccess()) {
showMessage("Error while trying to create the folder");
} else {
mThwingAlbertFolderId = result.getDriveFolder().getDriveId();
showMessage("Created a folder: " + mThwingAlbertFolderId);
}
}
});
}
}
}
});
What you are seeing, is a 'normal' behavior of the GDAA, that can be explained if you look closer at the 'Lifecycle of a Drive file' diagram (warning: I've never seen the source code, just assuming from what I observed).
See, the GDAA, unlike the REST Api, creates a layer that does its best to create caching and network traffic optimization. So, when you manipulate the file/folder from the 'outside' (like the web app), the GDAA layer has no knowledge of the fact until it initiates synchronization, controlled by it's own logic. I myself originally assumed that GooDrive has this under control by dispatching some kind of notification back to the GDAA, but it apparently is not the case. Also, some Googlers mentioned 'requestSync()' as a cure, but I never succeeded to make it work.
What you think you're doing, is polling the GooDrive. But effectively, you're polling the GDAA (local GooPlaySvcs) whose DriveId is still valid (not updated), unlike the real GooDrive object that is already gone.
This is one thing that is not clearly stated in the docs. GDAA is not the best Api for EVERY application. It's caching mechanism is great for transparently managing online/offline states, network traffic optimization. battery life, ... But in your situation, you may be better off by using the REST Api, since the response you get reflects the current GooDrive state.
I myself faced a similar situation and had to switch from the GDAA back to the REST (and replaced polling with a private GCM based notification system). Needless to say, by using the REST Api, your app gets more complex, usually requiring sync adapter / service to do the data synchronization, managing network states, ... all the stuff GDAA gives you for free).
In case you want to play with the 2 apis side-by side, there are two identical CRUD implementation you can use (GDAA, REST) on Github.
Good Luck
Google drive api does not sync immediately, That is why the deleted folders are still showing, so you have to force google drive to sync using requestSync()
Drive.DriveApi.requestSync(mGoogleApiClient).await();
I fount an example snippet here:
http://wiki.workassis.com/android-google-drive-api-deleted-folder-still-exists-in-query/
As Sean mentioned, the Drive Android API caches metadata locally to reduce bandwidth and battery usage.
When you perform an action on the device, e.g. creating a folder, we attempt to apply that action on the server as soon as possible. Though there can be delays due to action dependencies and content transfers, you will generally see the results reflected on the server very quickly.
When an action is performed on the server, e.g. by deleting a folder via the web client, this action is reflected on the device the next time the Drive Android API syncs. In order to conserve battery and bandwidth, sync frequency depends on how the API is being used as this is a priority for users.
If you need to guarantee that a sync has occurred, you can explicitly request a sync using DriveApi.requestSync() and wait on the result. This is currently rate limited to 1 per minute, which is frequently hit during testing, but should have a much smaller impact on real world usage.
Please let us know on our issue tracker if this sync behavior is causing issues for your use case so we can investigate solutions.
Google drive uses its own lifecycle for Drive api and manage all things in cache that's why if you delete some file or folder and try to access using google drive apis it is still available because it is stored in cache so you need to explicitly call requestSync() method for that then after that cache will be updated and gives you that folder or file not found.
below is code for that:
Drive.DriveApi.requestSync(mGoogleApiClient).setResultCallback(new ResultCallback<Status>() {
#Override
public void onResult(#NonNull Status status) {
Log.e("sync_status", status.toString());
if (status.getStatus().isSuccess()) {
setRootFolderDriveId();
}
}
});
and don't call Drive.DriveApi.requestSync(mGoogleApiClient).await() because your main thread will block so it will crash. use above one and after get successful callback you can do your operation on google drive because it's updated.
You can do it in main thread:
Drive.DriveApi.requestSync(mGoogleApiClient).setResultCallback(new ResultCallback<com.google.android.gms.common.api.Status>() {
#Override
public void onResult(com.google.android.gms.common.api.Status status) {
if (!status.getStatus().isSuccess()) {
Log.e("SYNCING", "ERROR" + status.getStatusMessage());
} else {
Log.e("SYNCING", "SUCCESS");
// execute your code to interact with Google Drive
}
}
});
I was having the same issue and using "Drive.DriveApi.requestSync" did the trick.
Also I suggest taking a look at https://github.com/francescocervone/RxDrive because you can concatenate the sync to other drive operations using rxandroid.
For example, this becomes a delete-and-sync operation:
Observable<Boolean> deleteFile = rxDrive.delete(file);
Observable<Void> syncDrive = rxDrive.sync();
Observable.concat(deleteFile, syncDrive);
The reason why you get listed deleted files from your query is that Google Drive has a "Trash" folder that is "searchable". You need to empty your trash first.
I am developing an Android app for connecting to Tridion 2011 SP1 Core Service.
So far I have created Android WS Stubs from the core service wsdl using wsclient.
Imported those stubs, which allow access to all the core service methods.
I can now authenticate to Tridion via the Android application but as soon as I try to perform even the most basic of web service calls, such as getApiVersion(), I get the error:
ReflectionHelper*java.lang.NoSuchFieldException: GetApiVersionResult.
I was wondering has anyone else managed to create a java android app that communicates with the Core Service?
Interestingly enough, if I run the code as a java application, using wsimport stubs everything works a treat.
Any help appreciated. For reference here is a code snippet:
To connect to Tridion:
class TridionConnect extends AsyncTask<String, Integer, String> {
// Called to initiate the background activity
#Override
protected String doInBackground(String... statuses) {
try {
Authenticator.setDefault(new Authenticator() {
#Override
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication("username", "password".toCharArray());
}
});
url = new URL("http://tridion-server/webservices/CoreService2011.svc?wsdl");
System.out.println(String.format("Get Service"));
service = new CoreService2011();
System.out.println(String.format("Get Client"));
client = service.getBasicHttp();
return "Authenticated To Tridion";
} catch (Exception e) {
Log.e("Authentication failure", e.toString());
e.printStackTrace();
return "Failed to authenticate";
}
}
// Called when there's a status to be updated
#Override
protected void onProgressUpdate(Integer... values) {
super.onProgressUpdate(values);
// Not used in this case
}
// Called once the background activity has completed
#Override
protected void onPostExecute(String result) { //
Toast.makeText(FullscreenActivity.this, result, Toast.LENGTH_LONG).show();
area.setText("Authenticated to Tridion OK");
}
}
To get the ApiVersion
client.getApiVersion();
UserData currentUser = client.getCurrentUser();
System.out.println(String.format("'%s' %s", currentUser.getTitle(), currentUser.getId()));
Frank,
It is not possible for a couple of reasons.
If you use wsimport to create the coreservice proxy it will use the javax library, which exists in the JRE. However Dalvik implements only a subset of the javax library which means this approach is impossible in the Android environment.
I then looked at Ksoap2 tools for creating the proxy. This seemed to work OK, in as much as it did create a proxy, however it did not match the coreservice so I was unable to authenticate. I didn't get any further with this approach beyond examining the JRE proxy v Ksoap2 proxy. They were quite different.
At this point I took a step back, had a cup of tea and re-engineered the approach.
I created a c# REST service to sit between the android app and the core service.
This approach seemed a bit complex, but it offers lots of advantages. Lots of the spade work can be done in the REST service, which will be much quicker than similar code on a tablet or phone.
Secondly the REST service sits on the same server as the CMS/CoreService so the comms is quicker and you can make the REST requests from the android app much lighter.
I have got the application to the point where you can authenticate to Tridion, select a publication, and components that is then rendered in a dynamic layout ready for update/save/publish.
The one big downside of this approach is that the REST service 'should' be stateless so superficially you have to authenticate to the coreservice for every request. Of course I don't do that, but you have to come up with some alternative approach Oauth, shared secret etc.
In initial tests this approach has seemed to be fairly slick on an android device.
I am trying to get a list of running applications and the amount of battery used by each of them. I have google for a long time but didnt come up with a solution. However there have been a few references on the PowerProfile, PowerUsageSummary internal classes.
I used them through Reflection technique but didnt get what i was looking for. PowerUsageSummary shows the same details as you can see by going to Device Settings->Applications->Battery Use(This is how it can be seen in a Samsund device).
Then i used PowerProfile class but i got only the mA of current utilized by WIFI, AUDIO, VIDEO,GPS, BLUETOOTH etc(The mA values dont change so often. I am not sure if the values are correct). Another reference was the BatteryStatsImpl class. I tested this class but the values are 0 always. Still i am looking for the list of running applications and the amount of battery used by each of them. Any help is appreciated.
Thanks,
Here is the sample code that i tried for BatteryStatsImpl class.
String BATTERY_PROFILE_CLASS = "com.android.internal.os.BatteryStatsImpl";
Object mBatteryProfile = Class.forName(BATTERY_PROFILE_CLASS).getConstructor().newInstance();
Method batteryMeth = Class.forName(BATTERY_PROFILE_CLASS).getMethod("getBatteryUptime", long.class);
Object arglist1[] = new Object[1];
arglist1[0] = System.currentTimeMillis();
// This is to calculate the batteryUpTime since the current time.
Long batteryUptime = (Long) batteryMeth.invoke(mBatteryProfile, arglist1);
Method dischargeMeth = Class.forName(BATTERY_PROFILE_CLASS).getMethod("getDischargeStartLevel");
// This is to calculate the dischargeTime of the device battery
Integer dischargeTime = (Integer) dischargeMeth.invoke(mBatteryProfile);
First please note that you can't make use of this API unless you are installed on the system image and so can hold the BATTERY_STATS permission. This is not available to third part apps installed separately from the system.
To use this, you don't directly instantiate BatteryStatsImpl. You request an instance of it from the current stats being collected by BatteryStatsService. You can look for the source code of the settings app for how to do this: https://code.google.com/p/android-source-browsing/source/browse/src/com/android/settings/fuelgauge/PowerUsageSummary.java?repo=platform--packages--apps--settings
In particular:
import android.os.BatteryStats;
import com.android.internal.app.IBatteryStats;
import com.android.internal.os.BatteryStatsImpl;
IBatteryStats mBatteryInfo;
UserManager mUm;
BatteryStatsImpl mStats;
mBatteryInfo = IBatteryStats.Stub.asInterface(
ServiceManager.getService("batteryinfo"));
private void load() {
try {
byte[] data = mBatteryInfo.getStatistics();
Parcel parcel = Parcel.obtain();
parcel.unmarshall(data, 0, data.length);
parcel.setDataPosition(0);
mStats = com.android.internal.os.BatteryStatsImpl.CREATOR
.createFromParcel(parcel);
mStats.distributeWorkLocked(BatteryStats.STATS_SINCE_CHARGED);
} catch (RemoteException e) {
Log.e(TAG, "RemoteException:", e);
}
}
the BatteryStatsService maintains the stats. Have a look in there how BatteryStatsImpl is used to do that (those note*() methods are called by the system when e.g. screen turns on)
Maybe you can get the current stats from there
Summary: synchronisation of multiple SQLite databases with server side sequentially.
I'm working on an Android application that is bound to be modular: we have a launcher that fires off intents, based on user choice, to start different application modules (separate installable packages). As it is now, each module has its own SQLite database and that works fine. The task I'm assigned to requires making data synchronisation between handheld and server side (SQL Server 2008 R2) using MS Sync Framework 4.0 (currently October CTP). I had developed android lib according to Sync Framework specs and that works too.
The issue I have is that because of this loosely coupled design (and some other restrictions) I need to have a button in launcher, that forces all modules to synchronise their databases one-by-one (order doesn't matter for now).
My current approach is to have an abstract BroadcastReceiver & Service (I only now discovered IntentService) classes that are inherited in each modules. So in launcher I broadcast intent, each module picks it up using customized BroadcastReceiver and syncs its database using, again, customized Service... In parallel. I have checked ordered broadcasts, but as I have a service doing the actual work it doesn't really help. The only other way I can currently think of is to have a system-wide mutex and use it to lock sync call in every service.
This is my first Android related task so there probably is a better way to solve this, I wouldn't run from redesigning synchronisation part if that makes our teams future life a bit easier.
[EDIT] So it looks like Java doesn't support named mutexes.
[EDIT2] By modules (or separate installable packages) I meant different APK for each module. So when starting a module you actually start a new process for it.
Using 'synchronized' you can implement mutex in java as below. This is a very minimal example.
private final Object mutex = new Object();
...
synchronized (mutex) {
if (myCondition) {
try {
mutex.wait(n);
} catch (XYZException e) {
throw new PQRException(“Wait() issue!”, e);
}
}
}
...
At the end I had to implement global lock using server socket like this:
ServerSocket mServerSocket;
/**
* Simulates global locking using server socket
* #return If lock was successful
*/
private synchronized boolean lock() {
try {
Log.v(serviceName, "Trying to acquire a lock...");
// any port from 49152 through 65535 should work
mServerSocket = new ServerSocket(51515);
return true;
} catch (IOException ioe) {
return false;
}
}
/**
* Simulates global unlocking
*/
private synchronized void unlock() {
try {
Log.v(serviceName, "Releasing a lock.");
if (mServerSocket != null) {
if (!mServerSocket.isClosed()) {
mServerSocket.close();
}
mServerSocket = null;
}
} catch (IOException e) {
e.printStackTrace();
}
}