how to send SMS after 4 days from a Symbian app by running the application in the bachground. Means application sends SMS after 4 days? Is that possible?
Please reply soon.
I don't think you would want to achieve this by running your application in the background for 4 days. For a start, if the phone was rebooted or ran out of battery in that time then the SMS wouldn't get sent when it was switched on again.
Instead, you can use the message centre API to schedule the SMS to be sent at a particular time.
The TMsvEntry class lets you call:
SetScheduled(ETrue);
SetSendingState(KMsvSendStateScheduled);
and then you can set TMsvEntry::iDate which is a TTime to the date/time you want the message to be sent.
This example shows how to send an SMS, try looking at:
void CSmsEngine::SendSmsL(const TDesC& aAddr, const TDesC& aMsg)
Comment out the SendSMSInThirdEditionL call, since you need to use the older API.
Make your changes in:
TMsvId CSMSExampleMtmsEngine::CreateSMSMessageL(const TDesC& aAddress,
const TDesC& aMessage)
Alternatively, if what you want to achieve is to send an SMS every 4 days, then you can use the Symbian Task Scheduler to do this. You can create an EXE which sends the SMS, then create a task which will run the EXE every 4 days. It will not keep anything running in the background so it won't waste battery, and it will remember to run the task even if you reboot the phone in between runs, since it persists the schedule to disk.
This example
shows how to create a task - so in the DoRunTaskL function you can send an SMS, for instance.
This example
shows how to schedule the task itself.
So to start your SMS sending schedule you would need to do something like that but edit the schedule to be every 4 days.
I would say that this is a relatively advanced programming challenge on Symbian. So if you are new I'd recommend doing some of the tutorials, reading the books etc. before starting it.
Related
I am currently using Twilio Studio to build a customer service process that allows clients to make calls to a Twilio number, which redirects to representatives.
How can I allow clients to send a voice message (voicemail) if the call is not picked up or if the call is not within working hours. Thanks!
Twilio developer evangelist here.
With the Connect Call To widget you can connect further widgets after either the call ending or the caller hanging up. In your case, you need to decide whether the call ended successfully or because the call wasn't picked up. You can do this by adding a Split Based On widget after the Connected Call Ended transition and testing on the DialCallStatus.
DialCallStatus can be any of completed, answered, busy, no-answer, failed, or canceled. In your case you are looking for "no-answer". You can use the Split widget to direct the flow onto the Record Voicemail widget when that happens.
As for calls not within working hours, that is a bit more complicated. To get the current time and compare to working hours will require you to run some code. You can do this with a Twilio Function, for example. There is an example application in the Twilio Code Exchange that implements this functionality but you would need to adjust it to use within your Studio Flow.
I have built a react native app/game where a user has 30 mins to finish a task....when they start task, the 30 mins starts to countdown and it is registered in DB (Firebase) that user is "in play". When they complete task (or 30 mins run out) then DB is again updated to "not in play".
Countdown function is operating on phone and not on server.
Problem is that if the user exits the app, then the counter on the phone ceases (the user is no longer "in play") but the DB does not know about it.....there appears to be no "user has exited app" event/handler that I can use to let DB know that user has quit.
I was thinking maybe the countdown logic should be running on backend but I cant think how.....any ideas?
Currently there is no way to handle app terminated in React Native so I think your best shot is to implement it on the backend.
How about when the user starts, you save the time the user started, and if the time difference between now and when the countdown was started surpasses 30 minutes the user is no longer "in play".
One way to detect that the user has left the game would be with Firebase's onDisconnect handler. With this call you register a write operation on the database that is executed when the server detects that the client is gone.
The server can detect this in two ways:
If the client disconnects cleanly, it sends a message to the server that it is disconnecting and the server runs the disconnect handlers for that client straight away.
If the client disconnects in another way, the server will detect that the client is gone when the socket times out, which may take a few minutes.
So in your case you could use an onDisconnect handler to either remove the player from the game, or otherwise mark them as "gone".
The only problem with this approach is that dirty disconnects may take a few minutes, which might be too long for your scenario.
An alternative would be to have the client write a message into the database periodically to signify that it's still here, e.g. a lastUpdated timestamp.
You can then in any code that reads the data use that timestamp to detect if the player was still recently playing, and consider them "gone" after a certain period that works well for your game. This code can then remove the player from the database.
This code can run in a server-side component if you want, but I've in the past also run this type of code in the client and then used (server-side) security rules to ensure it can only remove users that are "gone".
I am writing tests for an HTTP REST-like API. These tests are end-to-end tests, communicating with running application (web server, database, everything).
I am looking for a good way to test time based features. Since it is end-to-end test, I cannot simply mock time related functions.
As an example think about the google calendar.
Scenario: Event notification
Given it is 15:09
When I create new event starting at 15:20 with email notification 10 minutes in advance
Then I receive email notification within next 3 minutes
For single test I can just create on time and wait for email, but when I have repeated events (say weekly) than I need to test notification comes next week.
I was thinking about sending header that would (in dev environment) change application time, but the worker that sends notifications runs in separate process and would not be affected.
I am trying to make a chat app using XMPP protocol. The app is working fine except it doesn't show message notification when the app is in background. In Android I have used a Service for this purpose, however in Windows Phone I couldn't find anything similar to this.
I am trying Background Tasks for this, but as far as I have understood, they're made to run on prespecified trigger and I cannot add any custom trigger to it. In Android I have put my socket connection and parsing message calls in the service itself so that they can run on background too and the socket doesn't get closed even when the app is stopped.
So my question is, is there any similar way to do it in Windows Phone 8.1 (WinRT, not silverlight) or if Background Task is the only option, can you suggest a way to implement the notification functionality. I don't need the exact code, I just need a push to the right direction.
First: You cannot run a network connection in background.
Suggested way is using PushNotifications:
Either directly with a Toast Notification
Or with a PushTrigger to handle a Raw Notification, work out what to do
with it (who was it from, prepare data, etc.) and then create a ShellToast from it. Adds flexibility and improves user experience, but is quite complex.
Known downside: You have to use a server.
Only workarounds: Background-Tasks that checks for new messages about every 30 Minutes.
I want to push data to from a server to Windows Phone 7 client in an intranet environment.
I certainly don't want to use Microsoft Push Notification Service for this.
Is it possible to use WCF and long polling
I wrote this article on long polling - perhaps it would help?
http://xyzzer.wordpress.com/2011/03/10/real-time-client-server-communication-on-windows-phone-with-long-polling/
Long polling is just asynchronous programming with a, potentially, very long time out before the callback is called.
There is nothing in WCF (assuming that's what you meant in the title) or Windows Phone 7 that prevent this from being used. There is, however, a big consideration specific to using this technique on Windows Phone 7 though.
The issue you'll have with this on WP7 is that the app you create cannot run in the background and so must be constantly running from the time that the request was sent to the time that the response is received. Depending on how long your polling will be this may or may not be an issue.
As a partial solution you could consider disabling idle detection as this would keep the app running until the user stopped it (or triggered tombstoning).
Push Notifications are THE solution to sending a message (or a response) to a phone when the application isn't running.
Hopefully this will change in the future but that's how it is for now.