How can I provide several types of complications using only one complications provider? I want to achieve the same effect as "android wear" app does. They only have one provider and offer date, next event, photos, step counter, and others.
The documentation is still very poor, and I can't see anything where this is being talked about.
Thank you.
The first list that appears when you bring up the provider chooser is a list of apps. Clicking on an entry there brings up a list of complication providers included in that app.
Therefore 'Android Wear' contains 7+ complication providers, one for each type of data.
There is not only one provider under the app "Android Wear", instead they are independent providers.
Each provider can support multiple types and the complication on watch face slide will determine which type is prefer to display.
For example, the "Next event" in android wear support "LONG_TEXT" and "SHOR_TEXT". If a complication slot in watch face prefer "SHORT_TEXT", the provider will send "SHOR_TEXT" complication data to the watch face.
So what you need to do is implemented one provider for each kind of data.
Related
I made an Android app which can receive text via ACTION_SEND intents from other apps. However, when I try to share content from another app, my app is in the bottom of the long list of available apps. It's not alphabetically ordered because my app begins with "A". So how can I do to raise the position?
The order of options is controlled by the UI showing those options. That might be a system-supplied UI (e.g., platform default chooser) or an in-app API (e.g., ShareActionProvider). You have no means of guaranteeing your app's position in those options in either case. Whether they use alphabetical order, frequency of use, or other criteria is up to their developers, not you.
I want to create a Contact Provider so I can populate it from our database and let our business workforce to have all the customer data. That's the "easy" part.
But what I need is to isolate those contacts and avoid them to be cloned disallowing the people to copy/clone them and loosing track of that information.
Is there a way to do that? I haven't found a way to do that and I think the only way is to show the contacts in a custom Contact app. The problem with that solution is that it wouldn't be possible to know who's calling.
Is there a way to do that?
On an Android device, there will be roughly zero lines of code that knows anything about a custom ContentProvider that you create. If you do not want to share data from that provider, do not offer any UI to allow people to share data from that provider, and do not export the provider to third-party apps.
I haven't found a way to do that and I think the only way is to show the contacts in a custom Contact app
You needed to write that anyway. There are ~2 billion Android devices. None of them will have a Contacts-style app that knows anything about some custom ContentProvider that you create.
The problem with that solution is that it wouldn't be possible to know who's calling.
Correct. After all, the devices' call managers do not know anything about your custom ContentProvider.
Now, it could be that by "create a Contact Provider", you really meant "not create a Contact Provider". In this case, the "it" in "I can populate it from our database and let our business workforce to have all the customer data" might mean the standard Android ContactsContract ContentProvider. In this case, the Contacts app and in-call screens and everything else that works with contacts will work with your contacts. However, this is a system-supplied ContentProvider, exported to third-party apps, with documentation and so on. There are thousands of apps, both pre-installed and available via the Play Store and elsewhere, that can work with ContactsContract. You have no means of stopping that, and you have no means of preventing those apps from doing whatever it is that they want with this data.
IOW, you cannot satisfy "I want the Contacts app to have my contacts" and "I do not want the Contacts app to have my contacts" at the same time.
Applications of these two ideas could include enabling the player to see his or her progress in earlier games within the latest sequel, being able to keep the same character/progress across games, etc. etc.
While the best solution is likely having the player create an account they use across games, I'd like to avoid that if I can (both because players are already logging into Google Play Games, and because I currently do not have access to server infrastructure to handle doing that). Is there any other official/popular mechanism for passing data between games, or is the account route the best bet?
I believe that this is what you are looking for, Interacting with Other Apps especially the Sharing Simple Data and Sharing File section. You may also refer to this documentation for Receiving Simple Data from Other Apps which suggests that you will need an ACTION_SEND intent filter.
Update Your Manifest
Intent filters inform the system what intents an application component is willing to accept. Similar to how you constructed an intent with action ACTION_SEND in the Sending Simple Data to Other Apps lesson, you create intent filters in order to be able to receive intents with this action. You define an intent filter in your manifest, using the <intent-filter> element.
Handle the Incoming Content
To handle the content delivered by an Intent, start by calling getIntent() to get Intent object. Once you have the object, you can examine its contents to determine what to do next. Keep in mind that if this activity can be started from other parts of the system, such as the launcher, then you will need to take this into consideration when examining the intent.
I think this would be a good place to start on how to pass data from one app to another. You will also need to make changes in your current implementation both in your existingt and new app for this to be possible.
The other solution to this is to have all the games share a common Play Game Console configuration. You can have multiple packageIds point to the same appId, so they see the same list of achievements, leaderboards, etc.
Depending on your specific requirements, you could simply change the descriptions of the items to describe which game they are for, or implement custom UIs to display the lists.
I have been asked to add a "share" method to one of my Android applications which allows users to share by 1) Facebook 2) SMS and 3) Email
While researching, I have found that to allow users to select from "messaging" applications, I need to create the following Intent:
Intent messageIntent = new Intent(Intent.ACTION_SEND);
messageIntent.putExtra(Intent.EXTRA_SUBJECT, title);
messageIntent.putExtra(Intent.EXTRA_TEXT, content);
messageIntent.setType("vnd.android-dir/mms-sms");
// title and content set elsewhere...
This kind of works, although I am also given email clients in my list...
My Questions:
Is there a list somewhere of the Android specific MIME types that are available for us to use? The "vnd.android-dir/mms-sms" seemed pulled out of thin air to me from the example I found.
Is there the proper way to get ONLY messaging clients (ie. not mail clients) - or is that pretty much impossible to do in Android.
Disclaimer: The above code snippet was found from another SO post. Perhaps it is just me failing at Google - but I cannot seem to find any documentation on the legit Android developer site which listed out that this was the correct way to do this, or what my options are.
I have been asked to add a "share" method to one of my Android applications which allows users to share by 1) Facebook 2) SMS and 3) Email
Please allow the users to share how the users want, which may or may not be via those means.
I have found that to allow users to select from "messaging" applications, I need to create the following Intent
No, that allows users to share via any application that happens to support that undocumented and unsupported MIME type. Not every "messaging" application will necessarily support that MIME type, and applications that are not "messaging" applications are welcome to support that MIME type.
Is there a list somewhere of the Android specific MIME types that are available for us to use?
Not really, as generally they are undocumented or under-documented (e.g., the constant shows up somewhere without explanation).
The "vnd.android-dir/mms-sms" seemed pulled out of thin air to me from the example I found.
It probably came from the Android source code.
Is there the proper way to get ONLY messaging clients (ie. not mail clients) - or is that pretty much impossible to do in Android.
There are ~7 billion people on the planet. Each of them is welcome to have a different idea of what a "messaging client" is, what a "mail client" is, etc. Those are descriptive marketing terms, not technical definitions.
ACTION_SEND is for sharing content via MIME type. Any application can offer to support ACTION_SEND for any given MIME type, as the developers of any application can write what they want. Whether any given application is a "messaging client", "mail client", or something else is up to the end user. You have no means of reading the minds of users, nor do you have any legal means to prevent other programmers from writing what they want.
Now, there are various script-kiddie hacks for limiting the share list to certain apps, by application ID (a.k.a., package name). However, while there is only one Facebook (though I seem to recall they have a few apps), there are many SMS and email apps, and it would be difficult, if not impossible, for you to come up with a list of all of them, let alone maintain that list over time.
My strong recommendation is to format your content usefully, and allow the users to share that content using the apps that they wish.
When querying a ContentProvider on Android, one specifies the ContentProvider of interest by providing the "content URI" for that ContentProvider. What happens when multiple ContentProvider's serve that same URI, either intentionally? or maliciously?
When trying to open a pic on my phone, I've seen it prompt with apps that can "handle" the image. Will the same kind of thing happen here?
Multiple ContentProviders can't do this. The first application that registers a content provider using the element in its manifest has control over the URI pattern. I'm pretty sure that you'll get an installation error if you try to add another provider that uses the same URI pattern. Android keeps track of providers and URIs.
When you see a prompt with multiple apps for handling a file or situation, that's because the apps have specified an with a child that includes
android.intent.category.CATEGORY_ALTERNATIVE or android.intent-category.CATEGORY_SELECTED_ALTERNATVE. In essence, the app or apps are declaring themselves to be alternatives to the action specified in the child. This allows the user to have multiple choices for handling a type of data.
It makes sense to provide alternatives: a user might want to edit a picture, share it via Twitter, or e-mail it.
Note that two content providers can do the same thing, but they can't use the same URI. An app has to make a conscious choice of which one to use, or provide some mechanism of choosing between the two.