I have asked this question before (here), however it received no attention and I feel like this could really prove as useful to those who chose to embark on a similar issue.
Basically, I am implementing an application that sets alarms for the user, and in my current attempt I am using the ACTION_SET_ALARM intent to set the system alarm. Now this works fine with one exception: whenever I set an alarm, it makes a brand new alarm until eventually the alarm database is utterly filled with redundant alarms.
I'm trying to figure out how to set UNIQUE alarms without having to completely design my own alarm clock application. There must be a way to do this, simply by utilizing some feature of the native Android alarmclock class.
Methods I have employed thus far:
Android developer documents;
Pretty much every forum post on SO about this topic;
Utilizing various other intents i found by searching through the deskclock source code;
Importing the Alarms class, the setAlarm class.
The last remaining option for me is to embark on the AlarmManager class, but this is essentially recreating the alarmclock class and I want this application be generic (it can apply to most alarm clock applications) and not have to rely on its own.
Any assistance would be very appreciated.
There must be a way to do this, simply by utilizing some feature of the native Android alarmclock class.
You are welcome to your opinion, though your opinion may need to be accompanied by your own fork of Android and your own line of mobile devices.
First, there isn't really much of a "native Android alarmclock class". It is mostly just an Intent action string and a series of keys for extras. The implementation of the alarm clock functionality is device- and user-dependent, though many will simply use one from the Android open source project.
At this point, you run into two problems:
The app from the Android open source project does not support what you want
No other app has to support what you want, as it is outside the scope of documented behavior
What you need to do is use AlarmManager to broadcast out a pulse. This is the MOST RELIABLE way to get a pulse to go out. Have a broadcast receiver listen on that pulse an pass over to a service or start an Activity as needed. There you will examine your list of Alarm conditions and see if they have been met. Note you can also check timestamp at this point. Yes AlarmManager is far more reliable than any other service you can use for this.
Related
I've figured out how to get android to run some Java code on the systemwide BOOT_COMPLETED event. It's not clear to me what I need to do next to start my app in some form. As a novice android developer, I'm not even sure exactly if I can call into the JS side of the app at this point - is it even initialized?
Right now, on my personal device, the app crashes around this code:
Context context = getApplicationContext();
Intent myIntent = new Intent(context, BootUpHandlerService.class);
context.startService(myIntent);
...on the startService call, I get a BackgroundServiceStartNotAllowedException.
I presume this means I need to call startForegroundService instead, but the android docs say that may not be possible with Android 12.
The docs also seem to suggest I can start a WorkManager task. Given all the code I've written to use WorkManager tasks actually does so from javascript through a 3rd party library, I have no clue how to even do that from Java. All of my code to prepare for the work I want to do in the background and initialize the tasks themselves is in the frontend, running in an expo/react-native context. Sure, poor practice, but I can refactor once I understand what I need to refactor it into.
While I appreciate what they are doing here as an end user who hates the numerous services running in the background on my phone, it does seem confusing for a novice android developer.
What should I do instead? How do I run JS without the frontend to schedule WorkManager tasks? The docs seem to say I can't even do that, not even with a "notification trampoline".
I need to add a native sticky background service in a flutter application, in order to achieve 2 things:
Starting at boot time and running in background indefinitely
Exchange data with the main Dart activity, in a message passing fashion
However, I cannot find any kind of useful documentation. It seems that for now, you have to choose to go completely native or giving up using low level features and focus only on the UI (until someone pulls a specific plugin out of the hat).
Thus, my question is the following: what is the easiest way to achieve this sort of integration, starting with a basic flutter project ?
Thank you
Make a Sticky Service using native Android service.
The easiest way to exchange data with the main Dart activity is to use deep links or intents.
Note: if you explain more why do you need that, I think I may be able to give you a better solution.
While you can register a BroadcastReceiver to be activated at BOOT your idea of having a service "running in background indefinitely" is highly discouraged in recent version of Android.
Therefore what can you do is have a Broadcast receiver registered in Manifest that will be activate when BOOT completes (See https://developer.android.com/guide/components/broadcasts for a sample) and from here you can use the available API to schedule work. Check out this link to see what from available API best suite you needs.
While there are more complicated solutions you will find that simply sending Intents between components will do the job.
You can use the method channel
Docs : https://docs.flutter.dev/development/platform-integration/platform-channels?tab=type-mappings-swift-tab
I'm wondering, why ActivityRecognitionClient has no method to request updates with standard java listener as parameter? More strange, that in the same time, LocationСlient has such method and it works good.
Official example for Activity Recognition looks terrible. A lot of coupled and boilerplate code. It looks like IntentService is sole variant for handling updates from ActivityRecognitionClient. It's extremely uncomfortable.
#Guys from Android Team, why it happens?
As Developer I hope to see requestActivityUpdates(interval, listener) method in next version of Google Play Services.
For now, does anyone know, is it possible to use BroadcastReceiver for handling updates from ActivityRecognitionClient?
I'm wondering, why ActivityRecognitionClient has no method to request updates with standard java listener as parameter?
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.
Beyond that, quoting the documentation for requestActivityUpdates():
A common use case is that an application wants to monitor activities in the background and perform an action when a specific activity is detected. To do this without needing a service that is always on in the background consuming resources, detected activities are delivered via an intent. The application specifies a PendingIntent callback (typically an IntentService) which will be called when activities are detected.
It looks like IntentService is sole variant for handling updates from ActivityRecognitionClient.
It's not.
For now, does anyone know, is it possible to use BroadcastReceiver for handling updates from ActivityRecognitionClient?
There are several types of PendingIntent, created from various factory methods. The sample shows using getService() to create a PendingIntent that will call startService(). You are welcome to use any other PendingIntent, such as one from getBroadcast(), which will call sendBroadcast().
I have a few questions regarding the WakefulIntentService implementation by CWAC:
1) Is it safe to use multiple WakefulIntentServices at the same time within my application?
2) Is it still ok to use my own code that handles AlarmManager? This would save me re-implementing my alarm handling code. Currently, I have a class with static methods and variables which are used by other classes within the application to set the alarm. My AlarmReceiver then starts the WakefulIntentServices by classing doWakefulWork().
This class is fantastic work!
Thanks
Is it safe to use multiple WakefulIntentServices at the same time within my application?
You should only need one. Use different Intent information (e.g., actions, extras) to distinguish the different commands.
I have not tried multiple distinct services -- while it is possible that it will work, I cannot guarantee it.
Is it still ok to use my own code that handles AlarmManager?
Oh, sure. Follow the "Basic Usage" instructions, calling sendWakefulWork() on WakefulIntentService when you want the work to be done. Just bear in mind that you must do that from a BroadcastReceiver's onReceive() if AlarmManager is the trigger -- that's an AlarmManager requirement.
This class is fantastic work!
I am glad that you like it!
I am developing an android app which makes no reference to the sensor aspect of the phone. At a certain pint the program sends an sms and then sleeps for five minutes. If I move the phone during this sleep period a dialog box displayed earlier reappears. I realise this is rather vague without code at this stage but to start with is this something to be expected. I am wondering if one of the broadcast listeners is being triggered by the movement but even if this is so I cant make the connection with the dialog box. Any pointers will be much appreciated.
Fist off, I would take care of the orientation change possibility by forcing the app into an orientation by using the option in the manifest file.
Second, I would look at what other apps are on the device that might have an affect on this functionality. Assuming by your question, your app uses BroadcastReceivers. If this is the case, provided your business logic permits, use explicit intents ( new Intent(this, )) in place of implicit intents and receivers. If this is not possible because of business logic, then perhaps using permissions to protect against accidental implicit intent receive triggers. Ref: http://developer.android.com/guide/topics/manifest/permission-element.html (its a good starting place anyways).
Without more info on your specific business logic or source code I can't go much deeper into the problem, but my first suggestion would probably give the simplest result. Just remember to set this attribute for each activity that this problem affects.
Steve.