In the app that I'm developing, I want to have re-occuring task on each Monday (possibly at 00.01 AM).
The task is basicly as follows:
I will connect to a web service, to check whether there is a parameter or a new file to be fetched in order to use with the app itself.
Also, I need to send some data, which is basicly some data evaluated on that week, and restart the process on an on again.
After a ton of reading and so on, I think it may be more appropiate to use an AlarmManager implementation, since I do not see any need for using the UI etc (but I am open to suggestions, of course)
Probably the main question is that how can I easily schedule a task that when we are on the next week's Monday, at 00.01 AM or whatever, the system will check for Internet connection and if possible connect with that web services to send & retrieve data? The app is not supposed to be open I guess, but please note that the stored data is basic key value pairs in a preference file on that app.
The best approach for your case would be to use the AlarmManager. More info you can find here: http://developer.android.com/reference/android/app/AlarmManager.html
A small example is here: http://developer.android.com/resources/samples/ApiDemos/src/com/example/android/apis/app/AlarmService.html
And here for a more extended example: Android: How to use AlarmManager
Hope this helps!!
Related
I'm trying to get a feature in my app that opens an ftp connection every night, compares the content of the ftp server to the contents of the sharedPreferences JSON and if there is a difference, upload the missing data to the ftp server.
So far I think I need to use an AlarmManager for this, so that the code runs even when the app is closed at night.
This is a completely new thing to me and I'm looking up some documentation and StackOverflow questions about it, but I can't really figure out if this is what I need to use for what I'm trying to do.
I found the following question which contains a nice example of AlarmManager. But can it also retrieve data from sharedPreferences? I was also wondering if I can run an async task (using coroutines).
EDIT: I read something about a workmanager. Would this be a better solution for what I'm trying to achieve?
Workmanager is introduced from Android 8. It is better then AlarmManager because it can manage the doze mode and more when you phone is in sleep mode. You can configure the workmanager to do the work each x mins with conditions (if the device connected, if the phone has % of battery ..)
The great issus with AlarmManager is that you don't garatute that it will be launched at the specific time because the system will manage all alarm with priority...
For more details : link
Yes, you can fetch data from shared preferences from your BroadcastReceiver. And you can also run asynchronous tasks from your BroadcastReceiver, such as coroutines or threads.
I have gone through many posts.
Its bit confusing to understand that does ionic 2 app send local-notification even if my-app-is-killed-by-user or not ?
I have below scenario.
Assuming that app-is-killed-by-user
Can we run the app in background (like after 24 hours check if some
conditions are true by manipulating local/cloud storage) then send local notification ?
I am new to ionic 2. So can anyone let me know that above scenario is possible ?
If not possible then let me know that can we manipulate (get and analyse) local-storage via push notification server (assuming that app-is-killed-by-user) ?
Both are possible. I'll tell you how i would do them and not share code (it can be long), i'll give you the steps and you can figure it out.
For the first scenario you'll need LocalNotification plugin, LocalStorage, Platform import from 'ionic-angular' and MomentJS(not required, but highly recommended).
You'll need to create a service, at least it's good so you don't need to put everything in your app.components.
You can use 3 of the Platform methods to verify and set the LocalNotification, they're .pause, .resume and .ready.
Pause will check if the user has left the app, but it's still running on background.
Resume will check if the user has come back to the app, but'll not trigger if the app was killed.
Ready will trigger when platform's ready, you'll use this to check if the app was killed and is starting for "the first time".
You'll need MomentJS to manipulate time, since it's easier to add days/hours to your current datetime.
LocalNotification accepts both ISO string and UNIX timestamp to schedule a notification.
Inside your created service you'll have methods to schedule and cancel a LocalNotification, check the plugin wiki for those.
On the pause method you'll call the schedule method and schedule a localNotification having Moment add 1 day to your current time: Moment().add(1, 'day').unix() and use the result in the 'at' of your schedule.
This'll return a promise with the data of your notification and it's id, save this id in your localStorage like this.storage.set('Daily', ReturnedID);
When the app is ready or resume you'll cancel the notification.
So basically that's it, when going off you save a notification, when going in you cancel it.
The second scenario is a little bit harder and you'll need a back-end for this since you'll need to keep checking the time that user has gone off the app. You'll need only MomentJS, the Platform import, you push service plugin and a way to connect to your database (via Http or plugin, if it's a service like Firebase).
The steps are the same for the first scenario, the new service, the platform calling this service methods, but now will add some methods for you push plugin, so when you receive a push you can show and manipulate data.
Most push services (and localNotification) have a Data attribute where you can share some data with the user, in your case it'll be the data you want to safe in the localStorage.
You'll need a token of that user so you can send a push to him, see your push docs to see how you can get that token and save it to the user database register/node.
When the user leave the app you'll store in your database the time you want the user to receive that push (i'm assuming you want to do the same as the first scenario, but in a different way).
When the user come back to the app, you'll detele that time register.
The tricky part: you'll need your back-end to go through every user register and get the time they need to receive the push, so if the time is < the current time you'll send the push and delete that register.
In the app when the user receive the push a function'll save the data to localStorage, manipulate, ready or everything you want.
Sorry i can't share some code, but if you need furter explanation or ideas just ask.
Hope this helps :D
I am making an application which will check for files on storage directory and then utilize the files and upload to ssh server.
I was thinking about making a BroadcastReceiver which will start background Service on system boot, the Service will update AlarmManager which will start every hour/every day a class for utilize/upload file.
Can you give me advice if my logic is ok, or how can I improve it ?
Thanks.
This is why Google created the SyncAdapter.
You should look at the SyncAdapter example on the Android developers site.
Sync Adapters
There are a lot of moving parts; along with SyncAdapter you'll need to learn about Authenticator and ContentProvider (if you are dealing with the file system you can skip ContentProvider). This is the framework Google provides for asynchronously moving data to/from servers. You have the option to use a BroadcastReceiver if you want, but there are a couple other methods for scheduling data syncs.
I'm developing an Android app whose basic behavior is to show the user some pieces of information every certain configurable period of time. Those pieces of information come from my own server, so the app requests the server for new information whenever it is needed. Its behavior should be something like Muzei.
And here comes my question, should I use Repeating Alarms to fire a Service that does the job of downloading the new information, or should I use a Sync Adapter?
I've been reading about both methods, but I'm not very sure about which one is the best solution.
Thanks in advance
Is there a way to cause my app to update itself at exactly midnight every night? I need the new content to be displayed on the app right when it hits midnight. I have an idea of how to accomplish this, but if it isn't in another thread and is in the onCreate and the app is running in the background next time it is opened it would just display the previous info and not the updated?
I could also use help accomplishing this same thing with iPhone as well.
I will clarify a bit. So all the information that is to be displayed on the app will be in the app already. I simply want the content (whats displayed) on the app to randomize and then display the new group of content only once per 24hours or at exactly midnight. Hope that makes it more clear.
Android:
You can set pre-determined times to update with AlarmManager
You can look at a snippet here: Android: How to use AlarmManager
iPhone:
With iPhone you probably have to download the content whenever you re-open the app.
Can't you just have the app update the content upon launch, or when entering the foreground in the appDelegate.
This question is very vague - but if I understand the requirements correctly you will need to serve the application's content dynamically via a content server (or some type of a CDN). In this case there could be various scenarios.
In the easiest possible implementation, you could have the application be powered by data (XML, JSON, etc...) from something like Amazon S3 and have logic within the application to know how to fetch the correct data depending on the current day.
This wouldn't be extremely difficult to implement, but it would require building some type of cross-platform framework that reads the same kind of data for each application.
Is the content available before midnight?
If so, can't you have the app download it in the background beforehand and then make it available exactly at midnight?
If not, there's surely going to be some delay anyway.
app can not update itself at least in iOS apps.