I have a similar problem to this one: Two Different Response in Retrofit
However, both things that I've tried have not worked. I'm new to this and can't seem to find any other sources that are of use. I'm so so sorry if this is a dumb question, but I've been struggling with this for a week now.
Important information: I am coding in Jetpack Compose and using Retrofit2. To test data calls, I am using postman.
Success Response: [ Info changed for identification purposes, it responds with actual user data ]
{
"data": {
"id": 0,
"name": "First Last",
"first_name": "First",
"last_name": "Last",
"email": "name#yup",
"is_verified": true,
"created_at": 1666202587,
"meta": {
"image": "avatarImage",
"username": "",
"rng": " ",
"date_of_birth": null,
"city": null
}
},
"token": "correct token"
}
Error Response:
Error response
Data class:
Data class
In my first attempt, I made two data classes and split up the different responses. However, that just led to them both being null regardless of what I input. Once I moved them to once data class, it allows the user to sign in just fine, but the error is never caught and instead just crashes my app.
Related
I have created a webhook that is using the even extraction.updated that should trigger when a job is in progress. I want to retrieve multiple calls on the progress of the translation so that I can show it in my progress bar. Unfortunately I only retrieve a callback when the job translation is finished. When I create the job I set the misc.workflow parameter and same goes for the hook. Am I missing some parameters when creating a webhook or posting a job?
I was following this tutorial: https://forge.autodesk.com/en/docs/webhooks/v1/tutorials/create-a-hook-model-derivative/
The job payload takes the input which is my urn, output which is the filetype(svf2) and views(2d,3d), and misc which is the workflow(testworkflowname)
Callback result:
{{
"version": "1.0",
"resourceUrn": "<my-resourceUrn>",
"hook": {
"hookId": "<my-hookId>",
"tenant": "testworkflowname",
"callbackUrl": "<my-callbackUrl>",
"createdBy": "<my-createdBy>",
"event": "extraction.updated",
"createdDate": "<my-createdDate>",
"lastUpdatedDate": "<my-lastUpdatedDate>",
"system": "derivative",
"creatorType": "Application",
"status": "active",
"scope": {
"workflow": "testworkflowname"
},
"hookAttribute": {
"progress": "test"
},
"autoReactivateHook": false,
"urn": "<my-urn>"
},
"payload": {
"TimeStamp": <my-timestamp>,
"Env": "production",
"URN": "<my-urn>",
"EventType": "UPDATED",
"Payload": {
"status": "success",
"bubble": {
"guid":"<my-guid>",
"owner": "<my-owner>",
"hasThumbnail": "true",
"startedAt": "my-startedAt>",
"type": "design",
"urn":"<my-urn>",
"success": "100%",
"progress": "complete",
"region": "US",
"status": "success",
"children": []
},
"scope": "<my-scope>",
"registerKey": []
},
"WorkflowAttributes": null
}
}}
You've got your webhooks setup correctly. I'm afraid this is a limitation on the Model Derivative service side. The service can translate over 60 different file formats today, and as you can imagine, different formats must be converted using different libraries. And while some of the converters support progress reporting, others may not, so being able to get notified of translation progress really depends on the file format you're processing.
I am correlating json response, but from the captured json I need to replace a value with some different text.
For example - captured response is as below and saved to "corr_json"variable:
{
"data": [{
"type": "articles",
"id": "1",
"attributes": {
"title": JSON:API paints my bikeshed!,
"body": "The shortest article. Ever.",
"created": "2015-05-22T14:56:29.000Z",
"updated": "2015-05-22T14:56:28.000Z"
},
"relationships": {
"author": {
"data": {"id": "42", "type": "people"}
}
}
from this I need to replace string
API paints my bikeshed
with text Performance Testing and pass to next request, so the json to be pass as below:
{
"data": [{
"type": "articles",
"id": "1",
"attributes": {
"title": "Performance Testing",
"body": "The shortest article. Ever.",
"created": "2015-05-22T14:56:29.000Z",
"updated": "2015-05-22T14:56:28.000Z"
},
"relationships": {
"author": {
"data": {"id": "42", "type": "people"}
}
}
Is there a way to do this in Loadrunner?
Check lr_json_replace api provided by LoadRunner.
Depending upon your protocol in use, the language of LoadRunner is either C, C#, C++, VB, or JavaScript. Use the sting processing capabilities of your language, combined with your programming skills to reformat the text in question to include your tag.
Hint, you might consider two correlations on the returned data, one which begins with the first curly brace and ends with '"title":' with the second beginning with '"title":' and ending with the '\t\t}\r\t}' (if I am reading the text right) structure. Then you could simply sprintf() in C to pack a few strings (corr1+ your tag+corr2+ end structure) together to hit your mark.
I'm getting a 400 error when trying to do a search both through the Graph Explorer and through my own code. Both worked a few weeks ago but have stopped working recently. Another developer has been able to replicate it in their Tenancy, but Microsoft will not provide me support as we are not a Premier Customer.
If I run this query:
https://graph.microsoft.com/v1.0/drives{drive_id}/root/
it succeeds and returns information about the drive.
Following the documentation at https://learn.microsoft.com/en-us/graph/api/driveitem-search?view=graph-rest-1.0&tabs=http a search can be used via
https://graph.microsoft.com/v1.0/drives/{drive-id}/root/search(q='foobar')
But this returns a 400 error with "One of the provided arguments is not acceptable."
However, if I search for items in our entire Tenancy via the group search it succeeds so it doesn't appear to be a permissions error, but is not a viable solution as I need to search a particular drive.
please confirm whether you are still facing the issue. I was not able to reproduce the same from my side.
I ran this query:
https://graph.microsoft.com/v1.0/me/drives/drive-id/root/Search(q='Practices Checker')
And was able to get the desired result as below:
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#Collection(driveItem)",
"value": [
{
"#odata.type": "#microsoft.graph.driveItem",
"createdDateTime": "2020-12-09T11:55:47Z",
"id": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"lastModifiedDateTime": "2020-11-03T06:51:27Z",
"name": "Practices Checker",
"webUrl": "https://microsoftapc-my.sharepoint.com/personal/ribera_xxxxxxxx_com/Documents/Documents/Practices%20Checker",
"size": 0,
"createdBy": {
"user": {
"email": "ribera#xxxxxxxxxx.com",
"displayName": "Rinki Bera"
}
},
"lastModifiedBy": {
"user": {
"email": "ribera#xxxxxxxxxx.com",
"displayName": "Rinki Bera"
}
},
...
]
}
Thank you.
I have an intent where I might say 'Transfer 4 to Bob' and it identifies this as 'Transfer for to Bob'
Also I might say 'Transfer 10 to Bob and it identifies this as 'Transfer 102 Bob' treating to word to as 2 on the end of the previous number.
What is the best way to get API.AI to recognise these parts correctly so 4 is not for and to is not 2?
You mentioned that you're using the Actions on Google platform. This means that speech recognition - the process of translating what the user says into text - is happening before the data gets to API.AI.
The problem you're experiencing is that Actions on Google is misrecognizing some numbers as words, e.g. four becomes for.
Because this happens before - and separately from - API.AI, you won't be able to fix the misrecognition.
Below, I'll explain how you can work around this issue in API.AI. However, it's also worth thinking about how you could make your conversation design as robust as possible so that issues like this are less likely to cause problems.
One way you could increase robustness would be to mark the number as a required parameter in API.AI so the user is prompted if it isn't detected due to a recognition error. In that case, the dialog would go like this:
User: Give me four lattes.
App: Sure, four lattes coming up.
User: Give me for lattes.
App: How many do you want?
User: Four.
App: Sure, four lattes coming up.
Regardless, here's a workaround you can use to help recover from misrecognition:
In your intent, provide examples of these commonly misrecognized values. Highlight and mark them as numbers.
Test out your intent out in the console and you'll see that "for" is now matched as a "number" entity with value "for".
In your fulfillment webhook, check the parameter for this value and convert it to the appropriate number using a dictionary. Here's the JSON for the above query:
{
"id": "994c4e39-be49-4eae-94b0-077700ef87a3",
"timestamp": "2017-08-03T19:50:26.314Z",
"lang": "en",
"result": {
"source": "agent",
"resolvedQuery": "Get me for lattes",
"action": "",
"actionIncomplete": false,
"parameters": {
"drink": "lattes",
"number": "for" // NOTE: Convert this to "4" in your webhook
},
"contexts": [],
"metadata": {
"intentId": "0e1b0e72-78ba-4c61-a4fd-a73788034de1",
"webhookUsed": "false",
"webhookForSlotFillingUsed": "false",
"intentName": "get drink"
},
"fulfillment": {
"speech": "",
"messages": [
{
"type": 0,
"speech": ""
}
]
},
"score": 1
},
"status": {
"code": 200,
"errorType": "success"
},
"sessionId": "8b0891c1-50c8-43c6-99c4-8f77261acf86"
}
I'm using the Instagram API to fetch images with a certain hashtag that have been liked by my organization. But when the API makes the get call, the response comes back with data like this, where the like count is 83 (!) and the actual like data returned only shows 4 (!). I've seen postings here that indicate that Instagram returns about 120 data for likes. How come I'm only getting four?
The api call I'm using is:
https://api.instagram.com/v1/tags/mytag/media/recent/?client_id=myclientID
"likes": {
"count": 83,
"data": [
{
"username": "something",
"profile_picture": "picture",
"id": "idhere",
"full_name": "namehere"
},
{
"username": "",
"profile_picture": "",
"id": "",
"full_name": ""
},
{
"username": "",
"profile_picture": "",
"id": "",
"full_name": ""
},
{
"username": "",
"profile_picture": "",
"id": "",
"full_name": ""
}
]
},
When you fetch medias from Instagram using these endpoints:
/users/<user-id>/media/recent
/tags/<tag-name>/media/recent
You wouldn't have all likes in the response; same for comments. It's just limit set by Instagram. I think it might be really expensive to return all (or a lot) likes/comments in each media users fetch.
But don't worry, If you get medias you want, you will have their id and you could use this endpoint:
/media/<media-id>/likes
And then you will have all likes (use pagination to fetch them all) and do a great stuff with them.
Hope it helps you.
This could be three things:
1) A bug, but that's unlikely (ha a pun!)
2) Pagination. You need to ask for more data in another call with MIN_TAG_ID and/or MAX_TAG_ID set.
3) Privacy. Instagram users have privacy settings on their profiles. Described here. This would definitely lower the count even with pagination.