I have an android app which needs to keep sending SMS. My problem is that whenever we send a message we get a pop up showing (your SMS charges and your curent talktime balance in phone). When i send many SMS these pop ups keep getting accumulated one over the other which is undesirable for me. I need a way out to either remove or somehow consume these pop ups.
Any ideas ??
a pop up? Do you mean a toast? or notifications accumulating below the status bar?
You'll have to pardon my seemingly simple question. In the US, I've had multiple Android phones on at least two carriers, and I don't get any such message in any form, but may be that's because I've always had unlimited texting so additional texts do not cost me anything.
I bet you're talking about notifications accumulating in the status bar. So if your carrier is doing that, take a look at the code in the "API Demos" > App > Notification > Status Bar
There in the callback attached to the "Clear Notification" button, you'll find the code you're looking for.
And if I could suggest something, I know that many notifications accumulating on top of each other can be super annoying, but if you can try to consolidate all those notifications into one notification at least with the running count (unless your user explicitly opts out from being notified). This way, you still communicate to the user the most important part of the information - how many texts in total his phone has been sending so far, without completely overwhelming him with many-many notifications about basically the same event happening over and over again.
For those who don't know, "API Demos" is a free application you can download from the Market. And there may be several to choose from, so just pick the one with five stars next to it, but "API Demos" is also the same sample code that comes with different SDKs when you download it with the SDK Manager, and you can access that code when you create a new Android Project with the New Android Project... wizard from within Eclipse and then select the radio button "Create Existing Project from Sample" (or something like that, I don't have Eclipse in front of me, so the wording may be slightly incorrect). And of course, if you don't use Eclipse, you can always find that sample code through the Sample code directory itself.
As a potentially more elegant alternative, or may be just in case your carrier is indeed crude enough to pop up an actual modal dialog every time a text is sent, it may be that your carrier is using a broadcast receiver to trigger those notifications or those dialogs, so if that's the case, and hopefully the carrier isn't using "100" as a priority for its receiver, it may be possible for you to register a receiver with "100", and then kill the broadcast before it propagates to the other receivers. But of course, that's assuming that your carrier designed it that way for you.
Related
I am trying to determine the appropriate communication method between the mobile device and wearable for an application. I have been using notifications, which are ok, but the output is not always formatted the way I want. Example: when I include an image (a simple check mark) with no text, the image does not sit right in the center of the wearable. It's just below for scrolling purposes. Also I cannot control things such as vibration variations for different notifications. Also for future enhancements, I might need multiple smaller images in a single alert.
I have been looking at syncing data items but don't know if it will work for my first scenario and was hoping I could get some advice from the community.
Example:
There are a list of items on the wearable (this will be configurable). Each will have a image/png associated with them. Some items may have the same image. When the item is pressed the image (plus some text potentially) needs to appear on the watch with a specific vibration, then disappear.
A running history will be kept on the mobile app, but is not necessary for the watch. My concern with using the data sync is that this is that this is not really syncing data between the two devices, unless there is a "current item" which is being synced.
Hoping for some guidance from the community.
The Data API is really for keeping persistent items in sync between phone and watch. I'm not clear enough about your app's architecture to be sure if this is your best choice, though your configurable "list of items" sounds like a classic Data API use case. If you're not syncing these items, how will the list appear on the watch?
The Message API is more for one-off event signaling: something has happened on one device that needs to trigger an action on the other, and then it's done. And some of your description does sound more like this scenario... but again, I'm not clear enough about what your app is really doing.
And it's always possible that the you'll use both APIs for different aspects of your app; perhaps sending the configurable list of items via the Data API, then triggering events using Message.
Hopefully that's enough clarity on the two APIs to move you forward. If not, some additional details on your particular use case(s) would probably be helpful.
Edit after clarification in comments:
Your use case is still not entirely clear, but here's what I'd say:
If you're only showing a notification (or equivalent) on the watch at the point that an item on the phone is clicked, use the Message API to send those events.
If your watch app will show what has been clicked - whether just the most recent, or more extensive history - use the Data API to both "send the event" (by updating the DataItem) and maintain that record.
I want to try to make an Android alarm app that is impossible to stop. In other words, it keeps going for a predetermined amount of time, even if the user presses the power button, tries to reduce the volume, or anything else.
It does not seem feasible to me, but since I have very little Android experience, I'd like to know if something like that is theoretically able to be done. Thanks.
This question has been addressed on SO here: Override Power button just like Home button
.
There are several answers in the link that will give you options and get you 90% of the way there, but no answer will cover all devices/scenarios. The accepted answer in the link puts it best:
The Android system, as far as is documented, defines (a physical button press) as a
broadcast action. Following the publish-subscribe pattern of message
propagation, this message will notify all concerned parties of this
action. Because this message is sent by the system, because the
message stack is managed by the system, and because the message is
also received by the system, your code simply (cannot be) injected in the
right place to block the reception of this message.
I made a small Google Home App and my service returns a response with a SimpleMessage + Card.
It works perfectly when running the app in the console.actions.google.com simulator. I get the card all good.
But when I test talking to the Google Home, it only sends the text, no trace of the Cards anywhere.
However If i talk to the Google home app on my phone, it does send the card correctly.
Is there something to enable to be able to receive cards sent by Google Home? Is it possible at all?
There is no way to make cards that were sent while the user is talking via Google Home visible, but there are several techniques that you, as a developer, can use if cards are necessary.
First of all - good design suggests that cards should be use to supplement the conversation, not be the focus of the conversation. Make sure the voice conversation itself is important and use the visual elements only when necessary. If your action is overly visual - it may be better suited as a mobile or web app, rather than an Action.
If your device requires a screen, then you can set this in the Action Console when you configure your question. This will, however, prevent it from being used on a Google Home device.
If you don't want to go this route, and want to allow it to be used on a smart speaker, but still take advantage of a screen where it is available, you have a few options.
First is that you can just send the cards. As you've discovered, they won't show up, but they won't cause any problems.
If you want to act slightly differently if a screen is available, you can check for the surface capabilities that the user's Assistant is capable of at that moment. If you're using the node.js library, you can have a command such as
let hasScreen = app.hasSurfaceCapability(app.SurfaceCapabilities.SCREEN_OUTPUT)
to determine if a screen is available and take action based on the variable hasScreen. If you're using JSON, you need to check the array at surface.capabilities or data.google.surface.capabilities to see if "actions.capability.SCREEN_OUTPUT" is one of the available surfaces.
If not, and you get to a point in the conversation where you feel you need to send a visual result, you can also request to continue the conversation on a device that does support screen output.
First, you'll need to make sure that they have a screen available. You'll do this with the node.js library with something like
const screenAvailable = app.hasAvailableSurfaceCapabilities(app.SurfaceCapabilities.SCREEN_OUTPUT);
or by checking the availableSurfaces.capabilities or data.google.availableSurfaces.capabilities parameters in JSON.
If one is available, you can request to continue the conversation there with something like
app.askForNewSurface(context, notif, [app.SurfaceCapabilities.SCREEN_OUTPUT]);
where context is the message that will be said on the Google Home, and notif is the notification that will appear on their mobile device (for example) to let them continue the conversation. If using JSON, you'll need to use a actions.intent.NEW_SURFACE next intent.
Either way, the user will get a notification on their mobile device. Selecting the notification will start up the Assistant on that device and your Action will be called again with parameters that let you check if they are on the new surface. If so - you can send the card.
Basically I'm trying to get the "notifications" present in the notification bar somewhere else, or something similar in effect.*
Mind the ": I'm not really interested in catching and possibly messing with the original notification, I just want to know that it is there. There seems to be more questions around this topic, but mostly the quality is "I WANT THIS" with an expected "YOU CAN'T" answer. Maybe you (we) can come up with another option?
Things I have come up with, but that seem problematic are:
1:
Catching all send notification's. I don't think you can extend/override/change the current notificationManager. People seem to think this is not needed for non-evil apps. I disagree. But nevertheless I don't know any method that can accomplish this. Another option would mean to ask the manager for the current 'live' notification, but there is no such method I believe. Also the conclusion of these threads:
Global intents that are fired for all Android notifications
Receive Android NotificationManager Notifications from Non-System Apps
Is it possible for an app to replace the NotificationManager? (google groups)
2: Catching Broadcasts. This seems more doable, although not everything has a broadcast available. Apart from that last point: This would mean I would have to find out what broadcasts are available, and act on each one hard-coded. How feasable would it be to let users add their own broadcasts? And how would they know if (and what) their favorite program sends out? (I mean: add their own the app should listen to, not add a broadcast itself obviously)
This might involve something like an activity that catches everything for a certain period of time, and then you make sure you let your program send a notification, hoping it also sends something like a broadcast? Once a broadcast is identified, you want to act on that, but I don't know if you can change your behavior this dynamically.
3: Something completely different that will let me send as many different types of information (user choosable in the end) to an 'outside' place.
* I'm trying to send all notifications to a secondary location (a watch in this case). I can make something for all sorts of different situations (SMS, phone, mail, twitter etc), but this means double bandwith and cpu (battery), and everytime I (or a user) wants to add another type of message, I need to code more.
But nevertheless I don't know any method that can accomplish this.
Correct, short of modifying firmware.
Another option would mean to ask the manager for the current 'live' notification, but there is no such method I believe
Also correct, short of modifying firmware.
And how would they know if (and what) their favorite program sends out?
They wouldn't.
You are certainly welcome to:
Define your own broadcast Intent structure for a broadcast saying "hey, if anyone out there has some sort of extended notification thingy, here's one!"
Create one or more end-user applications that consume such events (e.g., routing to your watch)
Document and evangelize your Intent structure, convincing developers to take advantage of it, either to broadcast such events or consume such broadcasts
I want to be able to control incoming text messages. My application is still on a "proof of concept" version and I'm trying to learn Android programming as I go.
First my application need to catch incoming text messages. And if the message is from a known number then deal with it. If not, then send the message as nothing has happened to the default text message application.
I have no doubt it can be done, but I still have some concern and I see some pitfalls at how things are done on Android.
So getting the incomming text message could be fairly easy - except when there are other messaging applications installed and maybe the user wants to have normal text messages to pop up on one of them - and it will, after my application has had a look at it first.
How to be sure my application get first pick of incoming text messages?
And after that I need to send most text messages through to any other text message application the user has chosen so the user can actually read the message my application didn't need.
Since Android uses intents that are relative at best, I don't see how I can enforce my application to get a peek at all incoming text messages, and then stop it or send it through to the default text messaging application.
Espen,
The answer to this is multi-part. Understand first that our company has resolved this problem, but the solution is temporarily proprietary, so I will answer what I can without causing conflict either here or for my company.
1) You can never insure that your App ever gets first pick. What you can do is make your processing "fast enough" that is does not matter.
2) Intents ARE an absolute if you force the issue. Our company uses a concept called intent routing. This insures that the data is sent to the appropriate app. The most basic idea is that when you receive the SMS, you create a New Intent (not the same one) and send it to the class directly. This has some special considerations, but should give you some direction.
Unfortunately, without violating my company's confidence or stackoverflow's policies, I cannot say anymore publicly until the solution is made public (within the next month).
FuzzicalLogic
Retriving all incoming messages is just setting up listener, you can do it easily see here
and after that, its fine if you are at do nothing phase, but in case you want to prevent sms to go into the native messaging app it is not advisable to prevent user.
better you wait for some time and then delete the same from SMS database.