I am trying to detect a hot restart in my Flutter app programmatically, so that I can perform some actions before the app restarts.
What I have tried:
WidgetsBinding.addPostFrameCallback method,
flutter_reload package, but it is not available anymore,
I have been able to detect a Hot Reload using this:
#override
void reassemble() {
super.reassemble();
print("________________________________________________");
print("The app is Reloading...");
print("________________________________________________");
if (user.equipment != null && user.equipment!.isConnected()) {
print("Deconnecting blutooth device");
user.equipment!.disconnectDevice();
print("Disconnecting ended");
}
}
But it don't allow to detect Hot Restart.
I've found this GitHub thread on Flutter official repo, the problem is closed since 2019, so I guess it has been added.
Is there a way to detect a Hot Restart in Flutter?
Please note that this need, is only intended for debugging purposes. However, during testing or demos, it is possible that testers may hit the hot restart button and think there is a bug because the app is unable to connect back to the Bluetooth equipment. In order to avoid confusion and ensure smooth testing, it is important to be able to disconnect when a hot restart occurs.
Thank you for your help and support.
Related
I am currently developing an apple-watch app and I have to refresh something, if the watch gets turned on again from sleep mode. Are there any events I can check because I couldn't find anything on the web.
I got following error on google play store but I have no idea why this error occured. They said that it is happing on (Sharp AQUOS sense2 SH-01L Android 9 (SDK 28) ).
I have logcat but I can't find anything in logcat too. I already released to production. This one is my bugs fixed for new release.
ANR in com.google.android.apps.tachyon;PID: 18069;Broadcast of Intent {
act=android.accounts.LOGIN_ACCOUNTS_CHANGED flg=0x5000010 cmp=com.google.android.apps.tachyon/com.google.apps.tiktok.account.data.device.DeviceAccountsChangedReceiver_Receiver };
A similar Error occurred for me as well.
"ANR in com.google.android.apps.tachyon" at same device "Sharp AQUOS sense2 SH-01L"
E/ActivityManager(1566): ANR in com.google.android.apps.tachyon
E/ActivityManager(1566): PID: 18457
E/ActivityManager(1566): Reason: Broadcast of Intent { act=android.intent.action.LOCALE_CHANGED flg=0x11200010 cmp=com.google.android.apps.tachyon/.common.applifecycle.LocaleChangeReceiver }
I believe this device has com.google.android.apps.tachyon app is installed by default and an automatic update for this app could be running in the background (just a guess) which crashes anytime.
The crash is just a coincidence.
It will not happen every time with the same app and with the same use case. It will also not happen with any other device. just update the versionCode and publish the App again.
One other option is to go to the device catalog and mark this device as not supported.
After a lot of research, I think I have finally solved this for my app.
In my case, other than my main activity, the other Activies were only called by my app. In my activities in my AndroidManifest.xml, I had
android:exported="true"
Of course, this allows these activities to be invoked by other external activities/etc
By changing this to:
android:exported="false"
...it prevents the activity from being called.
In my case and going through the logs, I didn't see anything that jumped out and bit me but my research led me to believe that com.google.apps.tiktok.* was some sort of old transactional piece of Android. Also, I noticed my Tutorial activity was logging well after it should have been.
My suspicion is the test may actually be real and intended to check for either Activities handling external launches or checking for a security injection of some kind.
I think the use case is likely that an Android user is changed on the phone (usually at end of these robo tests), ticktok handles that and sends this intent/message to all externally known Activities. If so, that would mean either the Activities have to not be exported or handle the intent appropriately.
Anyhow, this change helped me tremendously and I haven't hit this with this app since after about 100 robo tests. Hope it helps someone else.
I think this is a problem with Google Play Store testing devices. Problems went away without me making any changes on a new release.
I have an app flutter that runs in Android and iOS.
This app is used in areas without any internet connection. When the user arrives at some place with internet connection, all the offline data must be sent to the servers.
Have an background task running and checking in loop for internet connections, or even a recurrent scheduled task, is not an option because:
The moment between the use of the app in the field and the moment that the user will be in place with internet connection might take many hours.
Running threads in background will consume resources and draw the mobile battery.
Android/iOS might finish the background process and the data not be sent unless the user open the app.
I'm wondering how to register a kind of listener, listening for "internet connectivity events" broadcasted by operating system when they happen and that will awake my app and trigger callback.
Then, I don't have to keep an unnecessary background task running infinitely but I can still do the job when the mobile get connected in the internet, even having my app closed/sleeping.
How can I do it in flutter ?
There's a package that listens to connectivity status called connectivity_plus, you can subscribe to a stream like so:
import 'package:connectivity_plus/connectivity_plus.dart';
#override
initState() {
super.initState();
subscription = Connectivity().onConnectivityChanged.listen((ConnectivityResult result) {
// Got a new connectivity status!
})
}
// Be sure to cancel subscription after you are done
#override
dispose() {
super.dispose();
subscription.cancel();
}
However in the documentation, it states clearly that connectivity changes are no longer communicated to Android apps in the background starting with Android O. You should always check for connectivity status when your app is resumed. The broadcast is only useful when your application is in the foreground.
You might wanna research that and see if it's possible to do so in the background. Here's a similar question which might help you out
I need to call my local notifications at a predefined time. This is working when my app is not closed. but once I closed the app, the notification is not working.
have you resolved this issue?
What you can try:
check if your app autostart/notification permission is enable.
Sometimes, depending on your device model, the autostart permission is
disabled by default, so if the application is closed you can not
receive notifications.
I had the same issue before.
Go thru this thread, where one user commented
On Mi4, with or without the every, after the app is exited,
notifications not received.
On Samsung S5, with "every" notifications stopped after the app
exited. Seems to be fine if scheduled without "every".
As stated in katzer
It might be possible that the underlying framework like Ionic is not compatible with the launch process defined by cordova. With the result that the plugin fires the click event on app start before the app is able to listen for the events.
So, what has work for me is to set in app.component.ts:
window.skipLocalNotificationReady = true;
subscribeLocalNotifications() {
this.localNotifications.on('click').subscribe((notification) => {
});
this.localNotifications.on('trigger').subscribe((notification) => {
});
this.localNotifications.fireQueuedEvents();
}
First you have to make your app can run at the background when you close your app.
Second you have to schedule the local notification through the condition you want. E.x: When you don't have wifi connection , push the notification with user
Did you use cordova-plugin-local-notifications?
I submitted a background audio app for certification and has failed with two reasons in which I could not figure out why.
Reason 1:
This app failed to correctly respond to at least one of the play,
pause, or play/pause events.
I understand that the MediaControl events for Play, Pause, Stop and PlayPause need to be catered, and have done so (and tested on both tablets and local devices that they are working) in the code. However, due to the reason that stopping a media stream and restarting it requires a longer-than-expected time, I used MediaElement.Pause() for both "Pause" and "Stop".
I read another post who had similar problem at the certification phase. Somebody recommended to use MediaElement.PlaybackRate = 0; instead. However, this is not ideal for long pauses as the stream will not move on.
What I wish to know is am I doing this the right way? For all my MediaControl events I have made sure that the MediaControl.IsPlaying property is correctly set as well.
Also, another reason it failed was this:
App failed the Perf test in the Windows ACK. See the following links
for more information: Test cases ran:
http://msdn.microsoft.com/en-us/library/windows/apps/hh920274.aspx
I have ran my app against the ACK and it all passed. The only thing I can think of is that the app does not enter suspend mode when the hardware (or on-screen) media control pause button is pressed. I have placed a debugger in the App_Suspending event but it never hits there.
As the description is too vague I am not sure if this is the problem. But if it's the case, can I know how do I force the app to enter suspended mode? I tried looking in the Window.Current class and Application.Current class, but to no avail.
Thanks!
For your first issue be sure that your media element is ready to play using :
while (CurrentTrack.CurrentState == MediaElementState.Opening || CurrentTrack.CurrentState == MediaElementState.Buffering)
{
await Task.Delay(100);
}
CurrentTrack.Play();
Also you have to stop your media element when the view is unload.
Regards.
After nearly 10 attempts in releasing the app, I finally got to the root of the problem, thanks to some guessing work by the folks at Microsoft too.
My app will automatically start the MediaElement streaming after the app is started. The background-capable audio will prevent the app from passing WACK because it will never enter suspended mode!
So, in order to get pass the store's WACK I had to remove the auto-starting feature, and now the app is in the store! (Phew).