I have a database with datas and my android application when it was launched checks if there is a new record in the database.
I created a Service and it checks every ten seconds if there is a new record and alert me with a notification.
I think it isn't the best solution cause it checks every ten seconds so it use the battery and internet every ten seconds.
Is there another solution to do that without check every ten seconds, for example, by using some code in my php form which add content in my database.
Thanks in advance.
You are right, there is plenty of solutions.
One of powerfull solutions is implementation of publish subscribe pattern.
In short: All subscribed clients will be notified on any change for which they are subscribed.
For quick info and start point use this link: https://developers.google.com/cloud/samples/mbs/pubsub_messaging.
General about publish subscribe: http://docs.oracle.com/cd/E19798-01/821-1841/bnced/index.html
Related
In a microservice architecture, suppose there is a business scenario where a user purchases something that will expire after two years, and the system needs to notify the user a little bit in advance.
In this case, how should we handle the situation so that the users can be notified on time even if there are many users who need to be notified?
For example, using a delayed queue of message queue will cause the messages to pile up when there are many users; using a timed task, too many users will overload the server CPU.
Is there a good way to do this?
While "microservices" do not inherently mean "REST", they usually are. And in REST you shouldn't store in memory anything that needs to survive more than one request. Two years is an extreme case, but even if it is for just 10 minutes, it should probably go to the DB.
Building up a queue for two years will just be very impractical and likely to fail if the queue contents are not persisted somewhere. Since you mention purchases I am assuming you have some sort of data store to record them either in sql or no-sql.
You can simply add purchase date/time column(s) to the table to make life easier. If you volumes are low enough for daily purchases then I would start with date based lookup only. You will need a scheduled execution of some service method say at 6am everyday that looks up purchases close to expiry i.e 7 days before 2 years purchase_date = now - 723days and then send rest request somewhere or publishes an event or jms message with order number and purchase_date as content for each purchase order. This will then be picked up by event/message listener somewhere and processed accordingly i.e. send a notification to customer. To avoid sending duplicate notifications you should also persist the expiry notifications in a database and ensure you check that notification has been sent for purchase id before sending it again.
If you ever reach a situation where you are processing thousands of orders a day and don't want to publish large number of events in one go then extend the functionality to filter by purchase timestamp and process chunks of purchases multiple times a day by changing the lookup condition.
This is just general idea of such requirement and you will have to fine-grain a lot of implementation details such as what happens if your email server is down.
You can use quartz job and configure it to use persistent mode in database (JDBC JobStore) to not loose information and also it is suitable for clustering mode.
Quartz checks periodically the database for the nearest task (configurable parameter) if the time comes, it will process the notification.
You can configure the thread pool size in order to avoid overload.
My app is an Android app for booking tables.so the app directly communicating with the server.I need to call a specific event that is generated by the Android app.say an item is purchased by the Android app, so I need to hold that item for 2 hour so no one can use that item.i'm thinking change the flag inside the database to not available. After the use that is after 2 hour I need to release the item for the other users.
I know from trigger will done the job but is it possible to delete the crown trigger from the table and remove the scheduling.
Why would you hold/release like that? It doesn't seem robust... if there's some kind of communication error, the bike could get hung up permanently. I would run something based off timestamps and calculate the bike's availability in realtime based on the date. These calculations are going to be cheap to do.
If you want to handle this on the client side then you have to do it using AlarmManager, schedule an event to make an api call or just release it locally. But as u said cron job will be a better way to do it where u update the db after 2 hrs.
If you want to run particular Rest API
, after every 2 hr , You can either set Repeating ALARM , or you can user Timer and Timer Task
OR
If you want to just notify the user after 2 hr,
Then you can use cron-trigger with cloud messaging like FCM (firebase clod messaging )
This question is a follow up to How to implement an atomic integer in Java App Engine?. Basically I am create a push Task Queue to implement SMS verification. I am using Twilio to send the SMS. Each SMS is a five digit pin number. The following is my queue.xml file for app-engine.
<queue-entries>
<queue>
<name>sms-verification</name>
<rate>200/s</rate>
<bucket-size>100</bucket-size>
<max-concurrent-requests>10</max-concurrent-requests>
</queue>
</queue-entries>
I want the best rate I can get without creating a new instance. I believe instance creation is expensive on app-engine, though I am not sure if it's the same for task queues. So is this configuration file good? Is it missing anything? This is my first time creating one so thanks for any guidance.
There is no right or wrong answer to this question. You will have to play with the configuration settings to get the optimal results for your requirements. You need to take the following into account:
You load throughout the day/week: more or less even or with sharp peaks.
Delay tolerance: how long it is acceptable to wait until the message is sent.
Obviously, it will be more expensive if you want to send all messages immediately, and less expensive if you can tolerate even a small delay (e.g. 1 minutes) as it would smooth out at least some sudden peaks.
Note that the higher the volume, the less important these optimizations become, as 1 new instance over 20 live is not as expensive as 1 new instance over 1.
I'm using C2DM in my application, and it works well, but sometimes, when I'm sending lots of messages, the delay is appearing, in it is up to 5 minutes.
All of my messages have the same collape key. Is it normal for C2DM?
EDIT: I'm sending approximately 1-2 messages per second
EDIT2: It is slow only for one device; another device receives notifications instantly
It is slow only for one device; another device receives notifications instantly
Probably due to network lags, you have to take network transience into account.
By the way, if you are sending 2 messages per second, your are sending 172800 messages to one device per day. You have a limit of 200,000 messages per day for one C2DM account. Clearly you aren't using C2DM the way it's supposed to be used. :)
Keep the application state in the server, not in the device, using a collapse key. So that only the most fresh result is delivered. Or else attenuation will be used to save battery.
Yep, as Reno linked to:
There is a attenuation. One post on Google Group suggest that each device has 20 tokens, and a new token is created every three minutes. So when you hit the limit, it'll take 3 minutes before you get the next token, thus the delay.
https://groups.google.com/forum/#!topic/android-c2dm/gY2RZBoFth4
I am a complete newbie to Android development;
Basically, I am about to write an application, that will let the user to take photo, which (with a bunch of extra data) will be submitted to the remote webservice.
So I'm guessing I will need:
A Photo-taking application (Activity) that will gather all the extra data and put in the SQLite DB.
A background service looking up the DB in time intervals and sending the data over the Internet, optionally making web requests with current GPS location (I'm trying to keep in mind, that sometimes network would not be accessible).
A receiver object that will run the service at boot, and optionally check if the service needs to be restarted.
My concerns are:
Do I really need to monitor the service and care about anything bad that could kill it.
Will the battery last for at least 12 hours with a non-stop running service, making some networking/GPS actions in, let's say, 30-minute intervals. (G1/Dream)
What else should I be careful about?
Any ideas/suggestions will be appreciated.
a word of advice needed
Rutabaga.
Oh, wait. You're probably looking for something related to Android. OK, carry on.
A receiver object that will run the
service at boot, and optionally check
if the service needs to be restarted.
Yuck. Use AlarmManager and have your service behave more like a cron job/Windows scheduled task.
Do I really need to monitor the
service and care about anything bad
that could kill it.
Not if you use AlarmManager and have your service behave more like a cron job.
Will the battery last for at least 12
hours with a non-stop running service,
making some networking/GPS actions in,
let's say, 30-minute intervals.
(G1/Dream)
If you use AlarmManager and have your service behave more like a cron job, a 30-minute interval should be OK. Just make sure you shut down the GPS radio when you are done with it. Note that using the GPS radio from a cron job sort of task is a bit tricky, since it takes a while to get its first fix. You will also want to take a look at using PowerManager.WakeLock to keep the device awake until your work is completed.
What else should I be careful about?
Mynd you, moose bites kan be pretti nasti.
Beyond that and what I wrote above, you should be in OK shape. Note that what you are diving into is not exactly "newbie" material.