For the same url, Google's PageSpeed Insights gives different scores on Mobile and Desktop. I am trying to understand how to differentiate the device level data while using the PageSpeed Insights API call.
Or does the PageSpeed Insights API call give results at an overall level?
Can someone please help me with it?
The strategy parameter of the PSI API is used to differentiate between desktop and mobile results. Note that when the parameter is omitted, STRATEGY_UNSPECIFIED defaults to desktop.
The PSI API docs have an API explorer that lets you run queries and see the results in a web UI. Here are a couple of examples:
Desktop:
{
"url": "https://www.example.com/",
"strategy": "DESKTOP"
}
Mobile:
{
"url": "https://www.example.com/",
"strategy": "MOBILE"
}
If you only have the PSI API results and want to know whether it relates to desktop or mobile data, you can look at the the lhr.lighthouseResult.configSettings.formFactor property, which will be 'desktop' or 'mobile' (where the response object is the value lhr).
See the ConfigSettings docs for more info on the formFactor field and other metadata about the results.
Related
Years ago I built a temperature sensor that would push (http post) readings to a server / dashboard system I had written. In lieu of expanding requirements, I've decided to switch to Home Assistant as my backend. Though it is possible to send the data to HA, the documentation is spotty. Namely I'm looking for the full JSON for the post body (an OpenAPI spec would be nice) and more details around how sensors function, and things "like can I set a unique_id so that they are editable in HA?", etc.
So far I've been working off the little bits of information around the API, some examples, and inferences from other documents for the python api (internal server code).
REST API
https://developers.home-assistant.io/docs/api/rest/
Sensor post info from HTTP integration
https://www.home-assistant.io/integrations/http/#sensor
General Sensor Docs
https://www.home-assistant.io/integrations/sensor#device-class
Perhaps what you're looking for is value_json?
Here's how I'm fetching value out of a simple webserver which returns this basic json object { key: value }, although one difference is that I'm polling and using GET.
rest:
- resource: http://192.168.0.122/status
sensor:
- name: "Data from my server"
value_template: "{{ value_json.key }}"
Tip: Go to Developer Tools -> Template for a sandbox-like environment where you can rapidly prototype your value_template
In azure when adding a user, group, or service principle to a role you can search by name and email address in the same search (screenshot below). When I look at the MS Graph APIs there are separate APIs for users, groups, and service principles (MS Graph API documentation links below). And it looks like the search options cannot be mixed (just display name or just email).
Does anyone know how to achieve a search like this using an Azure REST API. I'm curious if anyone knows what calls Azure is actually doing and if they are part of the published rest API? Or if one search is combining like multiple API calls which would be confusing since are paginated that would be hard to figure out what to display from which....
I'm building an app to add permissions and I'm trying to recreate a feature like this search.
Only way I can think of to achieve this now would be to select an option to search for either 'groups', 'users', or 'service principles'. Then another options to select search by 'email' or search by 'displayName' (but not both as the same search). This seems more clunky but technically ok.... but I'd rather do it like the azure screenshot below.
https://learn.microsoft.com/en-us/graph/api/user-list?view=graph-rest-1.0&tabs=http
https://learn.microsoft.com/en-us/graph/api/group-list?view=graph-rest-1.0&tabs=http
https://learn.microsoft.com/en-us/graph/api/serviceprincipal-list?view=graph-rest-1.0&tabs=http
Microsoft Graph API provides batching functionality where you can batch multiple requests together and send them as a single request for processing. In your case, on the server-side (Graph API side) three requests will be processed but from your application you will be sending a single request and get a single response.
Your request would be something like:
{
"requests": [
{
"id": "1",
"method": "GET",
"url": "/users?$filter=<your-filter-criteria>"
},
{
"id": "2",
"method": "GET",
"url": "/groups?$filter=<your-filter-criteria>"
},
{
"id": "3",
"method": "GET",
"url": "/servicePrincipals?$filter=<your-filter-criteria>"
}
]
}
You can learn more about the batching capability in Microsoft Graph API here: https://learn.microsoft.com/en-us/graph/json-batching.
So the batching answer was not exactly what I wanted but something really cool that I'll likely end up using in the future!
Since batching could get ugly with the paging results since say I want 30 total results (so i set paging to 10,10,10) then if one gives 10 and has nextlink and the next gives 0 and the last give 5. I now have 15 results to display but paging with the other and the sorting of results after the next could throw results earlier. It might just be weird and I don't have time to think it through.
I just ended up doing a drop down for users, groups, and service principals. And you have to search separate. Not as cool as how MS does it internally but its consistent, predictable, and works.
Using your API for an fun app I am developing and I just started using your eendpoints, This particular endpoint gives me this responseError:
body: '{"errors":[{"status":500,"code":141,"title":"SYSTEM ERROR HAS OCCURRED","detail":"ORIGIN AND DESTINATION NOT ALLOWED FOR AMA4DEV EXTREME SEARCH REQUESTS ON ENVIRONMENT"}]}',
The endpoint I am hitting is:
amadeus.shopping.flightDates.get({
origin : 'PHX',
destination : 'MEX'
}).then(function(response){
console.log(response.data);
}).catch(function(responseError){
console.log(responseError.response);
});
To make sure it was not something with the auth token/secret I made sure to make a test call using your example on github that works which was:
amadeus.shopping.flightDates.get({
origin : 'MUC',
destination : 'MAD'
}).then(function(response){
console.log(response.data);
}).catch(function(responseError){
console.log(responseError.response);
});
No problem in hitting that endpoint. Thank you again for looking into this
If you use the test environment: it is free of charge but limited (limited number of API calls you can do per month and limited set of data (a subset of production data)). For each API you can find the data collection available here.
For Flight Cheapest Date Search API, the test environment doesn't have data for PHX as origin.
I tried in production and it does return data. Please note that Flight Inspiration Search and Flight Cheapest Date Search are built on top of a pre-computed cache (in production). As they are inspirational APIs we do not offer all pairs of origin-destination but only the most searched all over the world. If you want to get the full list of origin-destination pairs (even smaller cities), you need to use the Flight Offers Search API.
I added product in "In-app Products" in Chrome Developer Dashboard. Now I'm trying to integrate in-app purchase in the code for the extension and attempting to test it out locally using "Load unpacked extension".
I'm trying to test google.payments.inapp.getSkuDetails with something like this
google.payments.inapp.getSkuDetails({
parameters: { env: "prod" },
success: onDoit,
failure: onFail
});
I get the following response INVALID_RESPONSE_ERROR.
Is there a way to get all available products without publishing extension?
Docs states in Testing purchases that this is only done through publishing the app:
Prior to publishing your app to the world, you can test the In-App
Payment experience by publishing it only to trusted testers. When your
app is published to trusted testers, the purchase flow will proceed
normally, except they will not be charged.
With regard to your INVALID_RESPONSE_ERROR error, this SO post states that
Make sure to use the originalId(nmmhkkegccagdldgiimedpiccmgmieda)
while calling chrome.runtime.connect() in buy.js, if not then it is
the place where it triggers INTERNAL_SERVER_ERROR.
Hi I have done with following steps to implement Universal Link for IOS.
1.My sub domain is npd.nowconfer.com, and my apple-app-site-association file contains,
{
"applinks": {
"apps": [],
"details": [
{
"appID":"R3UDJNSN2P.com.sampleUniversal.teledna",
"paths": ["*"]
}
]
}
}
this file is uploaded into my subdomain npd.nowconfer.com and its serveing over https.
2.I tested using AASA Validator i.e https://branch.io/resources/aasa-validator/#resultsbox and i got Test result as all pass.
you can see attached screenshot.
3.Now In app side,my colleague did configuration such as
Added the domain to Capabilities i.e applinks:nowconfer.com and applinks:npd.nowconfer.com
Handled Universal Links in app i.e in delegate like this
- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void (^)(NSArray *))restorationHandler {
NSURL *url = userActivity.webpageURL;
// handle url
}
4.my universalink is https://npd.nowconfer.com:5000/calendar/deeplink?url=nowconfer when i click on this link from email ,my app is not opening instead it is redirecting to app store(becasue server side request came handling to redirect app shore if app is not installed on device)
But when i tested universalink validator here https://search.developer.apple.com/appsearch-validation-tool ,i have got some error
Link to Application : Error no apps with domain entitlements
The entitlement data used to verify deep link dual authentication is from the current released version of your app. This data may take 48 hours to update.
I have seen lot of tutorials but not used anything for me.Can you guys help me to figure out what is happening here?
Universal Links have to be standard http:// or https:// links. This means they need to use the standard web ports, of which 5000 is not one. That is why your link is not working — it's not actually a valid Universal Link.
The Apple validator checks for some additional things, and is also somewhat unreliable. This particular error message is confusing, but it has nothing to do with whether your Universal Linking configuration is correct. What it actually means is Apple can't detect applinks: entitlements and 'proper' handling of passed-in link values in the version of your app that is currently live in the App Store. This is expected if you are just implementing Universal Links for the first time. You don't need to worry about this — a number of large and successful apps with working Universal Links implementations fail this step too.