I'm creating an app which copies the functionality of the default alarm app. I'm storing all of the user's entries (alarms) in a Room database (to display all of my alarms in a RecyclerView). Whenever I store an entry, I set an alarm using the AlarmManager.
How do I make sure that the user can edit an alarm which is already set?
As I understand, I need to create an identical PendingIntent (which includes also the same requestCode and then use the cancel method).
I want to use the rowIds from the DB as requestCodes for the alarm.
How do I make sure that when the user modifies an alarm I have access to the corresponding rowId?
Of course, I can make DB queries to get back the rowId based on the other properties which I save in the TextViews from the RecyclerView (title, description, date), but is there a better way?
Should I also save the rowId in an invisible TextView (for easy access to the data)?
The answer to a somewhat similar question posted here was to set an alarm only when a previously set alarm fires. I don't think this is a solution since I can have multiple alarms which need to be triggered at the same time.
Also, please help if you know a better method.
Related
As title suggest I want to know which approach will be best suited for my situation.Here is what I need.
In my app I am having a list of events. when clicking on any event from list, it will take user to event details page. On that page I have a Remind Me button on press of which user will be notified few hours/days before event. I want to know which of the two approach will be better.
First Approach
I register an alarm manually with the system which will get trigger according to the time which I will provide at the time of setting alarm.
Second Approach
I should use a web service along with push notification and when push is received show notification to the user.
the first approach is sufficient. A local notification is all you need in this case. Using the second approach is definitely overkill. The benefits of the first method are it will work offline and it save you cost to send a remote notification.
The first approach is the best. If you go with the web approach there can be chances that the user isn't using data-plan. And yes it will surely work for multiple instances. Instead of relying solely on alarms. You can use the calendar API and set a reminder. You can set multiple reminder with alarms that way.
I hope it helps.
I have the following situation.
I need to set many alarms to start the same Activity at different specific dates.
In order to accomplish this, I obviously use an AlarmManager.
Since the PendingIntents given to the AlarmManager are all equivalent, in order to have Android create all of them (and not just 1) I use a different requestCode to differentate among them.
All of this works fine, all alarms are created correctly.
The point is that sometimes I have to cancel them!
If I do not do it with the same requestCode the AlarmManager does not cancel them.
It is very difficult to retrieve the original requestCode in the code, since they are created at runtime at different moments/days...
Any suggestion on how to address this situation?
You have the right approach, as the only way I know to cancel the alarms would be cancel the pending intents with the same requestCode, however your issue is retrieving the same request codes made at run time. You would have to store these codes some how either by SQLite, or shared preferences perhaps to have them stored on the device then retrieve them as needed. Alternatively you could pass the requestCode as a bundle in the intent and then cancel it immediately after it fires off, or when ever through the alarms life cycle you choose. Hope this helped a bit.
I have been struggling with an approach to this problem for some time now. There is no Intent action fired off when a contact is added (as far as I know). What are my options to solve this issue?
Here are some ideas I have been playing with:
Firstly I kept a record of user locations with timestamps and periodically scan the Contacts DB and add new entries to my own DB with a timestamp. I could then compare these and try to find a decent match. I do not like this approach as it is very error prone.
Recently I've been looking at a ContentObserver for the Contacts DB, but I am not sure how to set this up so that it will constantly be observing, and not just when my app is in focus. Perhaps in a service? The documentation isn't clear to me about the life-cycle of a content observer, i.e does it die after the service/activity that registered it dies?
So really what I want is a seamless way to record where and when a user adds a contact when my app is installed on the device. It is not enough that the app should be in focus/running.
The second idea of yours is the correct one. The observer needs to be in a service as you had rightly guessed. Register the observer in the onCreate(). You will use contentProvider in the onChange of the contentObserver. You will need to maintain time when you last read the database using shared preferences. Note the changes of entries after the time stored in shared preferences. Now update the time of shared preferences to current time. Also unregister the content observer in onDestroy().
I am writing an Android app that needs to be notified whenever a given SQLite database changes (any new row added, deleted or updated).
Is there any programmatic way to listen to these notifications ?
Is writing DB triggers for each table the only way ?
SQLite provides Data Change Notification Callbacks. I don't think that Android exposes them directly but it does have for example CursorAdapter which provides some change notifications.
As thinksteep asked however, do you expect your DB to be changed outside the scope of your own application?
You can register an observer class such as DataSetObserver
Then whenever you change something you can call cursor.registerDataSetObserver(..) to register observe changes.
It's not well documented but I'm sure that there are some examples out there
You can use also use the getContentResolver().registerContentObserver but unfortunately it doesn't tell you what kind of change was made, it could be a delete, insert or update.
If you control the ContentProvider that interfaces with the DB then you could fire an Intent or use getContentResolver().notifyChange to send a special Uri notification that identifies both the table and action. An example Uri you could notify with might be: content://my-authority/change/table-name/insert
But even then you don't know exactly which rows were effected by the change.
Seems like triggers that write to a change log table will guarantee you hear about all changes regardless of where they came from, and you can know the exact id and action that occurred. Unfortunately it means slower inserts/updates/deletes and it means you probably need a Service of some kind to process and delete changes.
I'd love to hear if these is some better solution out there!
I have an Android application which depends on the value returned by a webservice. This value changes only once a week. Clients should detect this changed value, but the exact time they detect this change is not really important, 12 to 24 hours later should be no problem.
My current implementation starts an IntentService in the onCreate() method of my custom Application class which retrieves the value from the webservice. I also persist the last retrieved value in the SharedPreferences, so the application does not have to wait until this value is retrieved.
Now my question is if it is necessary to schedule the retrieval of this value after it's first retrieval in the onCreate() method, lets say after 12 hours. I know the onCreate() method is called only once in the lifecycle of an application, but I do not know how likely it is an application will be terminated by the Android system. Is it reasonable to assume that the application will be terminated enough times so that scheduling is not necessary? And in the case I should schedule the operation, what will be the best way to achieve this?
If you used onCreate(), I don't think you'd have any guarantees that it would be called a second time. E.g. if the user plugs their phone in to charge, has go-to-sleep turned off and leaves your app running for days on end. Very unlikely, but not impossible.
If I were you I'd set up some sort of scheduled task. Maybe this link will help:
http://developer.android.com/resources/articles/timed-ui-updates.html
The example uses an OnClickListener to cancel the task.
OnClickListener mStopListener = new OnClickListener() {
public void onClick(View v) {
mHandler.removeCallbacks(mUpdateTimeTask);
}
};
You would want to put this elsewhere, in onDestroy() perhaps.
There are a couple of options, as I have had similar design challenges. Both have pros and cons.
Option A
You could have a splash screen, like many apps, and use the asyncTask class to make web requests and update your shared preferences. You could set a custom timeout so the app doesn't get stuck on the splash screen for too long. No matter what the result, if it updated or did not, you can then load what ever is in sharedPreferences and use that for app usage on that run.
The good thing about this is that every time the app starts you won't have to worry if the data is up to date or not, as you will just go and get it. For performance updates you could also store the last time the sharedPref value was updated (e.g. you got the value less than 12 hours ago) and therefore skip the web request - the result makes your splash screen quite quick to come and go.
Option B
You could use an Alarm via the AlarmManager, this is would be much better than a service which would be a unnecessary battery drain. There is even an enum for the interval of a day "INTERVAL_DAY". When the alarm is triggered a broadcast recevier will execute your custom code that would make the web request and get the values and store them. You can state if the Alarm repeats is a single use.
Hope that helps.
EDIT: there aren't the only options just the ones i picked out of relevance.