The edge effect has a color that occurs when you overscroll some list/scrollview.
I've found that you can change at "android:colorEdgeEffect" but I'm using managed workflow.
Copy this file and change it to your needs: ./plugins/withAndroidColorEdgeEffect.js:
https://github.com/wodin/rn-hce-test/blob/a89dcdbc6c642a839bce3ad6a58120627b668d5b/plugins/withAndroidColorEdgeEffect.js#L1
And reference it in your app.json file:
[
"./plugins/withAndroidColorEdgeEffect",
{
"color": "#123456"
}
],
And you will need to use the new "eas build -p android" instead of "expo build:android"
Source: https://forums.expo.dev/t/how-do-i-change-the-color-of-the-android-edgeeffect-color-in-scrollviews-and-flatlists-in-managed-workflow/64021/2
Related
If there is an environment variable SAMPLE_VALUE defined in the ecs task definition like so
{
"containerDefinitions": [
{
"command": [
"./app"
],
"image": "sample-image:latest",
"name": "sample-app",
"environment": [
{
"name": "SAMPLE_VALUE",
"value": "ABC"
}
]
}
]
}
If the same environment variable SAMPLE_VALUE is defined again inside the Dockerfile of sample-image like so
...
...
ENTRYPOINT ["run.sh", "app"]
The content of run.sh is
#!/bin/sh
export SAMPLE_VALUE=XYZ
exec $1
What value would app get from the variable SAMPLE_VALUE? Would it be XYZ or ABC?
The priority here would be:
ENV declarations in the Dockerfile will be used by default.
Environment-variable settings when you launch the container, including the ECS setting you show (but also docker run -e, Compose environment:, Kubernetes env:) override the image's ENV.
Any environment variables the main container process sets itself will override both of these.
So in your example, the main container process is run.sh, and that ignores whatever was previously in the environment and sets $SAMPLE_VALUE itself; when it exec the actual command, it will see SAMPLE_VALUE=xyz.
You can illustrate this a little further by printing out the previous value:
#!/bin/sh
echo "SAMPLE_VALUE was ${SAMPLE_VALUE}"
export SAMPLE_VALUE=xyz
exec "$#"
This will print out the ABC value set in the ECS definition, but then run the actual program with the value set to xyz.
I have a postman collection, with a set of three API calls I'd like to chain together and feed with a data file using the runner function. Lets say they're:
/prepareUpload
/upload
/confirmUpload
and the output of each is needed for the next step. I'm happily pulling stuff out of the responses and putting them into variables ready for the next call, but the bit I seem to be falling down on is the /upload needs a file parameter of type file, but Postman doesn't seem to let me set it to a variable:
I've tried exporting the collection, manually editing the json to force it to a variable and running that, so something like :
<snip>
{
"key": "file",
"contentType": "{{contentType}}",
"type": "file",
"src": ["{{fullpath}}"]
}
],
"options": {
"formdata": {}
}
where {{contentType}} and {{fullpath}} are coming from my data file, but it never seems to actually do the upload.
Does anyone know if this is possible?
Issue:
In postman if we check the UI, we notice that there is no way to define file path as variable.
This looks like a limitation when we need to run file from different systems
Solution:
The solution is to hack the collection.json file. Open the json and edit the formdata src and replace it with a variable, let say file_path so : {{file_path}}
Now in Postman:
in pre request you can below code to set the path
pm.environment.set("file_path","C:/Users/guest/Desktop/1.png")
You can also save it as environment variable directly or pass through cmd using --env-var when using newman.
Note:
set access file from outside working directory as true (settings from top right corner)
It's not possible to read local files with Postman (There are at least two issues concerning that in there tracker on github: 798, 7210)
A workaround would be, to setup a server that provides the file, so you could get the data via a request to that server.
Ok, so found the answer to this, and the short version is - Postman can't do it, but Newman can :
https://github.com/postmanlabs/newman#file-uploads
It's a fair bit more effort to get it set up and working, but it does provide a solution for automating the whole process.
For Postman (as of Version 9.1.5), on Mac os, you can trick postman by naming a file in your shared directory with your variable name (ie. {{uploadMe}}). Then you choose this file (named as the variable) from the file selector and Voilà.
In my case the files I upload are located in the same shared directory and don't forget to set the shared directory in your postman settings.
The solution is quite simple,
Make sure you have the latest version of postman
Go to postman settings to find your working directory and add the desired file to your postman working directory
In the body tab, select formdata
In the pre-request script tab, enter the code below.
pm.request.body.mode = "formdata";
pm.request.body.formdata = {
"key": "preveredKey",
"type": "file",
"src": "fileName.extension"
};
I'm building docker images using cloud builder trigger, previously $BRNACH_NAME was working but now its giving null.
Thanks in advance.
I will post my comment as an answer as it is too long for comment section.
According to this documentation, you should have the possibility to use $BRANCH_NAME default substitution for builds invoked by triggers.
In the same documentation it is stated that:
If a default substitution is not available (such as with sourceless
builds, or with builds that use storage source), then occurrences of
the missing variable are replaced with an empty string.
I assume this might be the reason you are receiving NULL.
Have you performed any changes? Could you please provide some further information, such as your .yaml/.json file, your trigger configuration and the error you are receiving?
The problem was not in $BRANCH_NAME, I was using the resulted JSON to fetch the branch name.
like,
"source": {
"repoSource": {
"projectId": "project_id",
"repoName": "bitbucket_repo_name",
"branchName": "integration"
}
}
and
I was using build_details['source']['repoSource']['branchName']
but now it's giving like
"source": {
"repoSource": {
"projectId": "project_id",
"repoName": "bitbucket_repo_name",
"commitSha": "ght8939jj5jd9jfjfjigk0949jh8wh4w"
}
},
so, now I'm using build_details['substitutions']['BRANCH_NAME'] and its working fine.
My Ember app is actually a child engine. Recently, I observed that the source maps are not working properly in Chrome. So, I have to open the generated engine.js to debug…Instead I want to be able to open the individual source modules/files written in ES6 using Ctrl + P in Chrome Sources and add breakpoints to debug.
I tried both the ways in ember-cli-build.js;
babel: { sourceMaps: ‘inline’ }
sourcemaps: { enabled: true, extensions: [‘js’] }
My question is am I doing something wrong with the above? Does the parent/host app have any impact on the generated source map OR is the child engine configuration for sourcemap totally independent of the parent config ?
I can create a SQL DW using ARM no problem. However, the portal supports an option of also installing a sample database - e.g. AdventureWorksDW. How can I do the equivalent using an ARM script?
BTW, I clicked on "automation options" on the portal add it shows an ARM script with an extension that probably is the piece that installs the sample database, but it asks for some parameters (e.g. storageKey, storageUri) that I don't know.
Here's what I think is the relevant portion of the ARM JSON:
"name": "PolybaseImport",
"type": "extensions",
"apiVersion": "2014-04-01-preview",
"dependsOn": [
"[concat('Microsoft.Sql/servers/', parameters('serverName'), '/databases/', parameters('databaseName'))]"
],
"properties": {
"storageKeyType": "[parameters('storageKeyType')]",
"storageKey": "[parameters('storageKey')]",
"storageUri": "[parameters('storageUri')]",
"administratorLogin": "[parameters('administratorLogin')]",
"administratorLoginPassword": "[parameters('administratorLoginPassword')]",
"operationMode": "PolybaseImport"
}
More specifically, looking at the ARM deploy script generated from the portal, here are the key elements that I need to know in order to auto deploy using my own ARM script:
…
"storageKey": {
"value": null <- without knowing this, I can’t deploy.
},
"storageKeyType": {
"value": "SharedAccessKey"
},
"storageUri": {
"value": https://sqldwsamplesdefault.blob.core.windows.net/adventureworksdw/AdventureWorksDWPolybaseImport/Manifest.xml <- this is not a public blob, so can’t look at it
},
…
AFAIK that's currently not possible. The portal kicks off a workflow that provisions the new DW resources, generates the sample DW schema then loads data. The sample is stored in a non-public blob so you won't be able to access it.
I don't think it's hard to make it available publicly but it does take some work so perhaps you should add a suggestion here: https://feedback.azure.com/forums/307516-sql-data-warehouse