Hello, I am a beginner in Android development.
Currently, the Android app implements the part where the service is running and the processing continues.
So I had an abstract interface implemented to a class that would receive a callback (assuming class A), and I held a reference to class A and called back, but the reference to class A disappeared during the application kill, so I couldn't call back.
The solution is to extend BroadcastReceiver to the listener class, callback without having a reference to class A, and keep the reference to class A in the WeakReference.
Therefore, if there are any problems with these two methods, please let me know, and if there are any other better methods, please let me know how to implement them.
Thank you for your cooperation.
I'll write the code of the method I'm thinking about.
Method 1
public class Aextends B{
@ Override
public void onB(String name) {
// Push notification is given below.
}
}
public adstract class Bextends BroadcastReceiver {
@ Override
public void onReceiver (Context context, Intent) {
Bundle extra=intetn.getExtras();
String name =extras.getString("key");
onC(name);
}
public abstract void onB (String name);
}
Method 2
public class Aimplementations B{
@ Override
public void onB(String name) {
// Push notification is given below.
}
}
public address interface B {
public abstract void onB (String name);
}
public class C {
private AmClassA;
public static void b(String name) {
mClassA.onB(name);
}
}
I don't know the connection between Activity and Service, which is closely related to Android's life cycle, so I wonder if I call Activity by intent in push notification on B and notify users in dialog.I will write with the expectation thatAlso, I think AndroidManifest.xml is set up properly.
First of all, method 1 and method 2, but the sure thing is method 1.I can't tell where Method 2 is in terms of life cycle, but I think it will be killed along with service and other kills.Also, this depends on the Android version, but there is a bug that disables START_STICKY, the automatic recovery flag when the service is killed in Android 4.4.It may not be possible to recover even if it is killed by user manipulation, and it is a commonly used version now, so we need to deal with it, so we usually have to deal with it using Method 1.
Next, regarding Method 1, there are some problems with the code as it is, so if you correct it, it will look like this:
@Override
public void onReceiver (Context context, Intent) {
// Get WakeLock
WakeLock wakelock=(PowerManager) context
.getSystemService(Context.POWER_SERVICE)) .newWakeLock(
PowerManager.Partial_WAKE_LOCK
| PowerManager.ON_AFTER_RELEASE, "Sleep_Lock");
// Force the app to wake up (if processing takes longer, processing is done in a way that is not timed)
wakelock.acquire(150);
// Intent filtering (equals are used differently depending on usage)
String action=intent.getAction();
if(action.equals(Intent.X)){
Bundle extra=intetn.getExtras();
String name =extras.getString("key");
onC(name);
}
}
To illustrate the addition, this BroadcastReceiver needs to obtain WakeLock and avoid sleep conditions to ensure user notification.Otherwise, the processing will be interrupted due to user interaction and screen OFF due to terminal neglect during BroadcastReceiver processing.Also, if you don't filter the intents properly, they will respond to all received intents and run every time.
Depending on the implementation of BroadcastReceiver, set your own permissions for invocation intents and AndroidManifest.xml, if necessary.
Other better ways, depending on the type and implementation of the app kill, it is possible to prevent Activity kill itself.In this case, it is possible to prevent the user from swiping the application history by pressing and pressing the home button.To prevent this, for example, set .setFlags (Intent.FLAG_ACTIVITY_EXCLUDE_FROM_RECONTS | Int.FLAG_ACTIVITY_NEW_TASK) as the intent for a particular Activity call.This will make it impossible to swipe kill (depending on the implementation) because it will no longer appear in the application history.However, if this method fails due to insufficient memory, that is the end of the process.Also, there is nothing you can do if you are forced to stop from the Settings screen.However, this method and method 1 may be useful, so why not consider it in some cases?
© 2024 OneMinuteCode. All rights reserved.