How can I construct a URI to table MediaStore.Files.FileColumns ?
I try like this:
Uri uri=Uri.parse(MediaStore.Files.FileColumns);
But in Eclipse "MediaStore.Files.FileColumns" is underlined. I guess, I do this wrong. How to correctly construct a URI?
FileColumns is interface. You cannot reference interface. If you need explicit column, use
Uri uri=Uri.parse(MediaStore.Files.FileColumns.<COLUMN>);
for example:
Uri uri=Uri.parse(MediaStore.Files.FileColumns.MEDIA_TYPE);
MediaStore.Files.FileColumns is an Interface, the method Uri.parse() receives a string.
Related
i want to get a data on Internet use Retrofit Library
my code look like this :
#GET("?key={key}&q={quotes}")
Call<List<Pixabay.hits>> getTheData(#Query("key") String key, #Query("quotes") String quotes);
java.lang.IllegalArgumentException: URL query string key={key}&q={quotes} must not have replace block. For dynamic query parameters use #Query.
for method api.getTheData
I get that problem, how to solve this? thank you.
you don't have to write query parameters in your path.
#Query will do that for you.
replace
#GET("?key={key}&q={quotes}")
with
#GET("/")
Precisely, {something} parameter can be used only in path variable.
For example,
#GET("/key/{key}")
In this case, you can use #Path annotation instead of #Query.
If you specify #GET("key?a=5"), then any #Query("b") must be appended using &, producing something like key?a=5&b=7.
If you specify #GET("key"), then the first #Query must be appended using ?, producing something like key?b=7.
So in your case no need to implement here like ?key={key}&q={quotes} just add
your domain #GET("your_domain/")
Android API has DocumentFile class. This class has canWrite() method.
Suppose I called this method and it returned true. Also suppose this object was representing "raw" file.
Now how can I do what it said I can?
Namely, how to write "Hello world" text into that file?
Thanks.
Namely, how to write "Hello world" text into that file?
It is not necessarily a file.
To write to the document identified by that DocumentFile, call getUri() on that DocumentFile to get the Uri to the document. Pass that to openOutputStream() on a ContentResolver. Then, write to the stream, flush() the stream, and close() the stream. Basically, once you get the OutputStream, from there ordinary Java I/O takes over.
I am newbie to Android development and I am confused between the difference of URI and Uri?
Please mention the main differences.
java.net.URI is mutable
android.net.Uri is immutable
Immutable URI reference. A URI reference includes a URI and a fragment, the component of the URI following a '#'. Builds and parses URI references which conform to RFC 2396.
In the interest of performance, this class performs little to no validation. Behavior is undefined for invalid input. This class is very forgiving--in the face of invalid input, it will return garbage rather than throw an exception unless otherwise specified.
More infos here
I have read the documentation on the Android ContentResolver
I have also searched for a suitable example to no avail.
According to the documentation, there is a method call that can be used as a way to get access to custom provider methods when the standard content provider methods are insufficient:
final Bundle call(Uri uri, String method, String arg, Bundle extras)
Call a provider-defined method.
so in my code I execute:
getContentResolver().call(uri, method, arg, extras);
but it always returns null bundle. In fact, the method in the provider never gets called.
Further research points to a (perceived) discrepancy of the contract where the RESOLVER has a uri argument with no equivalent PROVIDER parameter:
Bundle call(String method, String arg, Bundle extras)
Call a provider-defined method.
I am obviously not understanding something. Can anyone point me in the correct direction?
Further research points to a discrepancy of the contract where the RESOLVER has a uri argument with no equivalent PROVIDER parameter
That's the way they wrote it. The Uri is simply to identify the ContentProvider -- the ContentProvider knows who it is and therefore does not need the Uri.
the provider method does not allow #Override annotation
Yes, it does, as you can see in this sample ContentProvider:
#Override
public Bundle call(String method, String arg, Bundle extras) {
if (SET_KEY_METHOD.equals(method) && arg != null) {
key=arg;
}
return(null);
}
However, your build target (e.g., in Eclipse, Project > Properties > Android) must be set to API Level 11 or higher.
The corresponding call() from the client looks like:
getContentResolver().call(Provider.Constants.CONTENT_URI,
Provider.SET_KEY_METHOD, "sekrit", null);
Yes. I have a method in the provider that is declared 'public' that is passed into the contentresolver argument 'method.'
That's not how it works. call() on ContentResolver calls call() on your ContentProvider.
To answer your second question, my guess is that the ContentProvider version of call() does not need a Uri argument because, unlike a ContentResolver, it doesn't need to find a ContentProvider; it calls the method on itself.
I am creating a content provider for an android application, but I am having a problem correctly matching the uri using UriMatacher.
For example, I add the uri's to match (snipped from the link)
sURIMatcher.addURI("content://com.example", "people", PEOPLE);
sURIMatcher.addURI("content://com.example", "people/#", PEOPLE_ID);
sURIMatcher.addURI("content://com.example", "people/#/phones", PEOPLE_PHONES);
And then attempt to access contacts/people/1/phones. The successful match ends up being with PEOPLE_ID instead of PEOPLE_PHONES.
The query is initially generated by this code.
Uri uri = Uri.parse("content://com.example/people/#/phones");
ContentUris.appendId(uri.buildUpon(), 1).build();
With some logging statements thrown in, I see that the following:
The uri passed to the query gives this:
content://com.example/people/1#/phones
but uri.getPath() gives this:
/people/1
The third path part of the uri is clearly dropped, which explains why it was matching the wrong uri.
The example from the Android developer website seems to indicate that there shouldn't be a problem with this. Am I creating the uri incorrectly? Is it just a bug? Is this intended functionality (and therefore the example from android developers is a bad one)?
Uri.parse() is ignorant of the UriMatcher's wildcards; here, the # is the fragment identifier of a URI, so when you parse content://com.example/people/#/phones, it becomes content://com.example/people + fragment /phones. The id is correctly appended to the end of the URI, and then the fragment is carried over. In this case, you can't rely on ContentUris, but rather need to build the Uri the long way:
path = new Uri.Builder()
.scheme( ContentResolver.SCHEME_CONTENT )
.authority( DataProvider.AUTHORITY )
.appendPath( "people" )
.appendPath( "1" )
.appendPath( "phones" ) ).build();