Access to files via URI Android 11 - uri

In my project I am using external native library (no source code). One of the library functions receives the URI parameter as input.
On older devices (earlier than android 11) everything works correctly. For instance:
inputUri = Uri.parse("file:///" + inputFileNameConvert); // file:////storage/emulated/0/Android/data/packagename/cache/temp/record.mp3
But for android 11+, due to the restrictions imposed, I use FileProvider.
inputUri = FileProvider.getUriForFile(context, BuildConfig.APPLICATION_ID, new File(inputFileNameConvert)); // content://packagename/cache/temp/record.mp3
The content schema does not work correctly in the native library. I get an error:
The uri source has an incorrect format or an unsupported scheme
How can i pass uri to function with schema file? I need to create a file anywhere on the device without getting permission android.permission.MANAGE_EXTERNAL_STORAGE.
Any ideas?

Related

Firebase emulator hitting DB via the REST feature

I’m trying to setup the emulator so I can develop the firebase functions safely before deploying them. I just noticed that some REST calls I’m doing now fails - anybody know if it is not possible to use the REST feature of the RealTime DB https://firebase.google.com/docs/reference/rest/database
I'm trying to hit it with this URL
http://localhost:9000/?ns=<PROJECT ID>-default-rtdb/development/DISHES.json
because this is what I set the firebaseConfig.databaseURL to (suggested here by Google)
Bonus info: If I try to do a GET to the URL via postman it creates another database called fake-server (http://localhost:4000/database/fake-server: null) 🤔
According to RFC 3986, the path must come before the query parameters in URLs. Your URL should be instead written as:
http://localhost:9000/development/DISHES.json?ns=<PROJECT ID>-default-rtdb
Note how the corrected URL has the query parameter appended to the very end. (The URL you've provided in the question will be parsed as having one query parameter ns with the value of <PROJECT ID>-default-rtdb/development/DISHES.json, which is not a valid namespace name. That explains the errors you've seen.)
FYI, it looks like you're constructing the URL by concatenating the string databaseURL with the path -- this may lead to surprising results as you've seen above. Considering using a URL parser / formatter in your language / framework of choice instead, which handles URL parts correctly. For example, in JavaScript you can use the snippet below:
const url = new URL(databaseURL); // Parse URL (including query params, if any)
url.pathname = '/development/DISHES.json';
yourFetchingLogic(url.toString()); // Reconstruct the URL with path replaced

DocuSign .NET SDK - Esign DLL - Dealing with changes in Docusign Config Params regarding Error: 'Unexpected PEM type'

In Esign version 4.1.1, the VS2019 Docusign project code generators produce this type of config file:
Note that the developer must copy and paste the private key generated on the DocuSign "Quick Start" page into the VS2019 Docusign Project Wizard. The key is converted into a string, with each line in the original key file represented with a carriage return.
Using the private key value in this fashion, inline, with all the other params was very convenient.
This "RSAKey" param value does work with the 4.1.1 version. But does not with the 5.2 version.
In the Esign 5.2 version, we are now in the Asp.Net Core 3.1/.NET 5 style of code, so we now have this configuration file format:
This won't work with Esign 5.2. I surmise the change in 5.2 is this - the Docusign server generates a hash value of the key file, and if the generated hash of the key file submitted by an external client does not match, an "Unknown PEM File" error is sent back. I am trying to highlight the nuance that the first “gate” on the DocuSign server checks the file itself, not the RSA key inside the file.
The ramification, if true, is that we now have to treat the key file with kid gloves. If I wanted to store/retrieve this file from a remote source, I would need to take great care that not a single byte was changed/added/removed. This will require careful testing. As you can see from my sample appsettings.json above, I am forced to add "KeyFilePath" param in order to grab the physical file, which means I must always have it on hand in my project or be able to remotely load it (intact byte-wise) from a remote source. This increases the burden on the developer and maintenance staff considerably.
Ideally, what we need is a way to get that capability to put the key-file-as-a-string back into the config params.
Any ideas appreciated.
One way to solve this is by using https://base64.guru/ .
Using the "File-to-Base64" option allow me to provide this as a string parameter in a normal config file.
Then the C# code to use it looks like this:
var cred = LoadDocusingConfigIntoObject();
byte[] buffer = Convert.FromBase64String(cred.PrivateKey);
this.OAuthToken = docusignClient.RequestJWTUserToken(
cred.IntegrationKey,
cred.ImpersonatedUserId,
cred.AuthServer,
buffer,
1,
scopes
);

How to get uri to included asset in Uno Platform?

For integrating with a android binding project I need to provide a Uri pointing to a .zip file, which I have included in the assets and designated as AndroidAsset. How do I get the Uri for such a file?
I already tried ms-appx:///Assets/file.zip and file:///Assets/file.zip
Update:
Import to note is, that the function consuming the Uri is Android native code, so I suspect that ms-appx:// doesn't get resolved properly.
Update2:
It is not possible to provide a stream.
The method I am calling is shown in the sample here: https://github.com/Laerdal/Xamarin.Nordic.DFU.Android/blob/7244627c09e97e05ee2c8e05744f19055981486b/Sample/Nordic/FirmwareUpdater.cs#L27.
_dfuServiceInitiator.SetZip(firmwareZipFile);
The native implementation is shown here: https://github.com/NordicSemiconductor/Android-DFU-Library/blob/07bdaa50cfc5786790bf1ac589b14931de65d099/dfu/src/main/java/no/nordicsemi/android/dfu/DfuServiceInitiator.java#L620
public DfuServiceInitiator setZip(#NonNull final Uri uri) {
return init(uri, null, 0, DfuBaseService.TYPE_AUTO, DfuBaseService.MIME_TYPE_ZIP);
}
Files read from the StorageFile.GetFileFromApplicationUriAsync() method may not return a stable path on UWP, and this is particularly the case on particularly on Android or WebAssembly, where the file is not necessarily on the file system.
On Android, the file is a Stream directly built from the APK file, and on WebAssembly it is stored in a temporary location.
In order to use keep a stable copy of the file, use the following:
var file = await StorageFile.GetFileFromApplicationUriAsync(new System.Uri("ms-appx:///TextFile.txt"));
var newFile = await file.CopyAsync(Windows.Storage.ApplicationData.Current.LocalFolder, file.Name, NameCollisionOption.ReplaceExisting);
var txt = await FileIO.ReadTextAsync(newFile);
The method StorageFile.GetFileFromApplicationUriAsync can be used to get a StorageFile object from an ms-appx Uri.
Then you can use the Path property of the StoragFile to get the local android path. Make note to set the build action of the file as Content.
var file = await StorageFile.GetFileFromApplicationUriAsync(new System.Uri("ms-appx:///Assets/file.zip"));
Android.Net.Uri zipUri = Android.Net.Uri.Parse("file:///"+file.Path);

Reading a remote URL in Domino LotusScript

I have a remote RSS feed which has to be transformed into Notes documents using LotusScript.
I've looked through the documentation, but I can't find how to open a remote URL in order to retrieve its contents. In other words, some sort of wget- or curl-like functionality. Can anyone shed some light on how to do this? Using Java is not an option.
Thanks.
Check out the NotesDOMParser class - available in LotusScript - which lets you (indirectly) pull XML from a remote URL and process in a an XML DOM object.
You can pull the XML into a string using the MSXMLHTTP COM object, then use NotesStream to send the XML to the NotesDOMParser.
I have not tested, but the code would look something like this:
...
Set objXML = CreateObject("Microsoft.XMLHTTP")
objXML.open "GET", sURL, False, "", ""
objXML.send("")
sXMLAsText = Trim$(objXML.responseText)
Set inputStream = session.CreateStream
inputStream.Open (sXMLAsText)
Set domParser=session.CreateDOMParser(inputStream, outputStream)
domParser.Process
...
Documentation: http://publib.boulder.ibm.com/infocenter/domhelp/v8r0/index.jsp?topic=/com.ibm.designer.domino.main.doc/H_NOTESDOMPARSER_CLASS.html
You can't open a remote URL (whether it's HTTP or some other protocol) using native Lotusscript: the object library simply doesn't support it. If you're running on a Windows server, you should be able to use the MS XMLHttp DLLs to get a handle on your remote file via a URL, as specified by the previous answer. (Alternatively, this link specifies how to parse and open a UNC path with Lotusscript—again, Windows only).
All that said, if I understand you correctly, you're not using HTTP to access the remote file at all. If the RSS file is just on a simple path, why can't you open the file for parsing in the normal way with Lotusscript?

Blackberry http connection not working on 3g

hi friends i'm a newbie in blackberry programming and have managed to make a small application... The application downloads an xml file through http and parses it and displays it on the screen... now the problem is that though it works fine on my simulator... the client complains that he's getting an error in connection if he connects it through 3G... do i need to add anything other than the following...
// Build a document based on the XML file.
url = <my clients url file>;
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
hc = (HttpConnection)Connector.open(url+";deviceside=true");
hc.setRequestMethod(HttpConnection.GET);
InputStream inputStream = hc.openInputStream();
hc.getFile();
Document document = builder.parse(inputStream);
hc.close();
inputStream.close();
Do i need to add anything to make it download http content through 3G also??
Specifying "deviceside=true" requires the device have the APN correctly configured, or you include APN specification in the URL. Have a look at this video.
You need to be able to detect what sort of connection the device is using as was said above deviceside=true works only for APN. If you want to just test it out try using
;deviceside=false //for mds
;deviceside=false;ConnectionType=mds-public //for bis-b
;interface=wifi //for wifi

Resources