I have been developing an application to download whole calendars from all users in domain and save them in ICS format. The app is written in Java. I get access using 2L OAuth. So far I'm able to get most of calendar's data, excluding exceptions from recurrent events. Google API docs say that every recurrent event should contain a list of recurrence, including EXRULEs. But when I call the API I got only recurrent rule without exception.
It there any way to get these exceptions?
You get the exceptions as regular item and
event.getOriginalEvent()
will return reference to reccuring event.
Related
What should I use instead of ContactsContract.Contacts.LAST_TIME_CONTACTED? According to documentation, LAST_TIME_CONTACTED variable was deprecated. Even it was written in ContactsContract.class
/** #deprecated */
#Deprecated
String LAST_TIME_CONTACTED = "last_time_contacted";
Since it was deprecated then there must be another alternative. But why there's no alternative? Or why the documentation didn't link any alternative?
This constant was deprecated in API level 29.
Contacts affinity information is no longer supported as of Android version Build.VERSION_CODES.Q. This column always contains 0.
In Android Q or higher version, there's no alternative variable either?
There's no alternative - and it's intentional.
Google no longer wants developers with Contacts permission to be able to get access to data related to communication between the user and their contacts.
If you app is eligible to get the CALL_LOG or SMS permissions you can figure out the last contacted timestamp based on the call log / messaging history.
But these permissions are not allowed in Google Play unless your app is of a very specific use-case documented here.
I just want to know the high level steps of the process. Here's my thought on the process:
Assumption: the API returns JSON format
Check the API document to see the structure of the returned JSON
Create a corresponding Java class (ex: Employee)
Make Http call to the endpoint to get the JSON response
Using some JSON library (such as GSON, Jackson) to unmarshall the JSON string to Employee object.
Manipulate the Employee object
However, what if the API returned JSON is changed? it's really tedious task to exam the JSON string every now and then to adjust the corresponding Java class.
Can anyone help me out with this understanding. Thanks
You describe how to consume a json over http API, which is fine since most of the APIs out there are just that. If you are interested in consuming Restful HTTP resources however, one way would be:
Check the API documentation, aka. the media-types that your client will need to support in order to communicate with its resources. Some RESTafarians argue that all media-types should be standardized, so all clients could potentially support them, but I think that goes a bit far.
Watch out for link representations, and processing logic. media-types do not only describe the format of the data, but also how to process them. How to display it if its an image, how to run code that might be part of the message, how to layout onto the screen, how to use embedded controls like forms, etc.
Create corresponding Java classes. If the resources "only" describe data (which they usually do in API context), then simple Java classes will do, otherwise more might be needed. For example: can the representation contain JavaScript to run on the client? You need to embed a JavaScript engine, and prepare your class to do just that.
Make call to a bookmarked URI if you have it. There should be no hardcoded SOAP-like "endpoint" you call. You start with bookmarks and work your way to the state your client need to be in.
Usually your first call goes to the "start" resource. This is the only bookmark you have in the beginning. You specify the media-types you support for this resource in the Accept header.
You then check whether the returned Content-Type matches one of your accepted media-types (remember, the server is free to ignore your preferences), and then you process the returned representation according to its rules.
For example you want to get all the accounts for customer 123456 for which you don't yet have a bookmark to. You might first GET the start resource for account management. The processing logic there might describe a link to go to for account listings. You follow the link. The representation there might give you a "form" in which you have to fill out the customer number and POST. Finally, you get your representation of the account list. You may at this point bookmark the page, so you don't have to go through the whole chain the next time.
Process representation. This might involve displaying, running, or just handing over the data to some other class.
Sorry for the long post, slow day at work :) Just for completeness, some other points the client needs to know about: caching, handling bookmarks (reacting to 3xx codes), following links in representations.
Versioning is another topic you mention. This is a whole discussion onto itself, but in short: some people (myself included) advocate versioning the media-type. Non-backwards compatible changes simply change the media type's name (for example from application/vnd.company.customer-v1+json, to application/vnd.company.customer-v2+json), and then everything (bookmarks for example) continues to work because of content negotiation.
There are many ways to consume RESTful APIs.
Typically, you need to know what version of the API you are going to use. When the API changes (i.e. a different version is exposed) you need to decide if the new functionality is worth migrating your application(s) to the latest and greatest or not...
In my experience, migrating to a new API always requires some effort and it really depends on the value of doing so (vs. not doing it) and/or whether the old API is going to be deprecated and/or not supported by the publisher.
I'm using Android Studio to create an app that utilizes google maps api. I am having trouble validating if the user input is an actual location.
i.e if the user enters "fdfdfaef", program crashes.
i have the following code to store the user "location" input:
address = geocoder.getFromLocationName(location, 1)
Any help on how to check if the input is valid or not or at least to prevent a crash. Thanks and appreciate it.
Since you haven't posted any code, I will go out on a limb and suggest that you might be doing this on your main UI thread.
From the doc,
The query will block and returned values will be obtained by means of
a network lookup. The results are a best guess and are not guaranteed
to be meaningful or correct. It may be useful to call this method from
a thread separate from your primary UI thread.
Try doing a async task that requests information using the Geocoding API. On getting a result, update the UI. Offloading to an AsyncTask will prevent the crash, at the very least.
Does that help you?
I have been using Facebook4j for a Facebook graph API related requirement and my requirement is quite simple.
Requirement : I need search Facebook objects (all public objects- posts/comments/pages/ etc..) for given keywords frequently and persist all results into the db.
Problem : Although the requirement looks straight forward I am stuck in handling pagination of the results and calling the API later without losing any items ( posts/pages/comments ) in the consecutive calls to the API.
Doing some research I have found graph API provide several Pagination methods and Cursor based is the best and recommended. But unfortunately cursor based search is not available for all kind of objects. So I had to choose time-based pagination which uses until and since parameters.
Q1.Is my decision is correct?
Following is a sample previous and next URLs I get when I do a search API call using Facebook4j
previous = https://graph.facebook.com/v1.0/search?limit=200q=infographic&access_token=
[ACCESS_TOKEN]&since=1400152500&__previous=1,
next = https://graph.facebook.com/v1.0/search?limit=200&q=infographic&access_token=
[ACCESS_TOKEN]&until=1399983583
Say I did a API call and using the Facebook4j API method then I should be able to use
fetch next method and continue.
facebook.fetchNext()
But when ever I get an exception in my application OR at the point there are no further results I assume that I should be able to persist since/until values and use them for later API calls in the future and continue getting search results from where I stopped last time.
Q2. Is the assumption regarding the pagination correct ?
So I am assuming that my future API calls would be something similar to the below. I am not sure whether to use 'since' or 'until'.
Q3.Is the way I call the API below to continue searching from a previous search is fine ?
ResponseList<JSONObject> results = facebook.search("KEYWORD",new Reading().limit(200).until("1399983583"));
Also I am not sure whether these results are paginated in such a way I get the newest result set when I use the "NEXT url" / fetchnext() provided ?
Q4.Please clarify me on now the NEXT url provided exactly works in terms of pagination and future API calls?
If my above approaches are wrong, please suggest the best practices which I should follow to handle this requirement.
I have an old application that uses Web-To-Lead. I'm updating it to use the REST API. We have a bunch of assignment rules set up for Leads. When we create a lead through Web-To-Lead, the Lead is assigned according to our assignment rules. However, when we create a Lead through the REST API, the assignment rules are completely ignored, and the Lead is assigned to the account whose credentials we used to authenticate through OAuth. This has slowed our sales team to a crawl, because now they have to assign leads by hand.
Any ideas how to fix this?
#sangfroid
You want to make sure you set the Assignment Rule Header which should then get the rule to fire off for you.
Paul
====Edit===
It doesn't seem that you can which is a pain. You could try creating a new web service using the Apex REST services stuff (new in Summer '11) which then takes in your Lead data as you have created and runs it using the code at this link.
That should allow you to have the assignment rules run on the inserted Lead and still use a RESTful API. Your own implementation on Salesforce in fact. You could try that code in a trigger on Lead which should get run by the native API as well.
Hope that helps. Apologies for not paying attention on the SOAP REST thing first time round.
Paul