I'm developing an app for testing purposes for my company. This app receives notifications via GPRS of a remote hardware, that indicates things like if it is On/Off, battery level/ etc...
To make this easy to interpret, I'm using images that represent these states, and these are shown in a fragment. The app has nice visual design, including new desing library features as navigation drawer, etc.
To read received messages from the socket I use a service.
The problem is that, if I have the app opened, everything shows fine, but if I have the app closed, and even the service notifies that something has been received, when reopening the app it's starts in it's default state. So, everytime I close the app (exit from it), it is getting destroyed.
I'm not sure on how could I manage this. The best would be if I could mantain the app running on background, but I think that this can't be done.
So, how could I save the state of the activity, to when I open it again, to have everything like before closing it?
Have you looked at activity life cycle ?
Related
I've been asked to fix an android application which has issues after switching to a newer device. The switch was from android 7/8 to 11. The application opens up google maps for navigation but very often when returned to the app all data is lost, and clicking on anything will reset it back to the startup activity. It doesn't matter which apps it switches between the issue happens with all of them.
I've tried several things:
-Disabling all battery saving options on the device
-Using OnSaveInstanceState to retain the data
-Using a backgroundservice to retain the data
The issue only occurs on actual devices, using an emulator results in no errors.
When the debugger is attached to the application it loses its connection before returning to the app. It is possible to re-attach when returning to the app but it disconnects as soon as
anything is clicked.
And best of all there's literally no error message shown anywhere.
The following comment provided the solution I needed.
You would need to start a foreground service, complete with its Notification. Even that does not guarantee that your process will remain around.
– CommonsWare Sep 1 at 12:40
My app uses a pagerTabStrip with fragments. When the app goes to background and other memory intensive tasks run in foreground, the app will be killed. Then, if I recall the app, the fragments buttons onclick methods dont fire anymore. (side note: the color of the buttons is then wrong too, but the "visual click" down->up is working)
It is working fine when I manually kill the app or when it's just short term via onPause/onResume in background. It seems that in this system-kill-case sort of image of the app is taken and reloaded (incorrect).
If there is no direct way to fix this, I would like to catch this event, to just recreate the whole fragment, but I can't. I tried onTrimMemory and investigated the call order of onStop/onDestroy/onRestart ... but I couldnt figure out, when this "special kill" happens.
Thank you!
Got it.
First, to reproduce the issue, just launch the app, send to background and then hit the red circle-cross at the left pane of the logcat output frame in android studio as described here:
https://medium.com/inloopx/android-process-kill-and-the-big-implications-for-your-app-1ecbed4921cb
My workaround is to save the processID in onSaveInstanceState and to check if this changed in onCreate as described here:
https://stackoverflow.com/a/47483856/6053524
If so, the app has been killed by system and my issues of not proper working UI occured. To fix this I load the initial Activity via new Intent/startActivity to get a clean new application.
From the beginning of the APP development, I found that if I re launch the APP, the APP crashes and nothing gets displayed. I think it has something to do with the resource that is assigned to the APP and it trying to restore its previous state and it is failing to do so.
I see that, in many APPs, when it re launches the view is reset to its first screen. I would like to do the same in my APP.
Any suggestions on how I should be handling this ?
clear up memory ?
attach an event before-close and on-launch (or on-relaunch) ?
reset APP view to home screen ?
This is the first APP I am building (happens to be in Titanium). Therefore my fundamentals of APP development are weak.
Any help would be greatly appreciated.
I'm not sure what you are doing in your app, but I'm not seeing that in my Titanium apps. My users probably leave my app running/paused for days and then resume them as needed. Until their device runs out of juice, I'm pretty sure they never restart my app. Perhaps a module you are using?
There are events you can handle that will allow you to take an action when the app is put paused and when it is resumed. You can write your code to reset the app to the starting screen, which I'm partial to that idea as well. I'm not aware of a call you can make that will essentially restart your app.
The events you can handle.
Ti.App.addEventListener('pause', _.bind(this.exit, this));
Ti.App.addEventListener('close', _.bind(this.exit, this));
Ti.App.addEventListener('resume', _.bind(this.resume, this));
You would have to write the action taken when these events happen.
Code is from the https://github.com/appcelerator/Field-Service-App. This app has the hooks, but doesn't implement any actions for them. Check out the alloy.js file.
I'm trying to figure out the right way to add Chromecast buttons (pause, play, etc) to an Android Notification. I've set up a custom notification that sends PendingIntents to a ChromecastService. That service is trying to interact with a class I built called ChromecastAdapter. The ChromecastAdapter implements MediaRouteAdapter and contains all the listeners and state that go along with casting. However, all this state is gone as soon as I exit the application. So, my ChromecastService doesn't end up having access to the Chromecast once my app is gone.
It seems to me that the only way to get this to work is refactor all the Chromecast state into a Service that implements MediaRouteAdapter. I really don't want to do this since I'm pretty happy with the way things are now.
Since these interactive Notifications are required by Google, I feel like there has to be a standard way of interacting with a cast from a Notification. Am I on the right track here? Do I have to place all my Chromecast interactions behind a Service?
What the behavior should be depends on the type of app and the requirements of the app. If your app is "gone" (in the sense that the Application instance is gone), then the question that you should ask yourself is whether you would want to keep a notification mechanism to stay around; there are apps that when they are killed, the receiver also gets closed and user is sent back to the home screen on the chromecast device, in which case there is no reason to keep a notification around.
On the other hand, there are apps that based on their requirements, you would want to let the cast device continue what it was doing (for example play the video) even if the mobile app is gone. In those cases, you may want to have a notification mechanism in place for "bringing up" the app. To achieve that, you need to maintain certain amount of information/state/objects in a service, enough to be able to establish a connection again and "join" the running app. In addition, your "service" needs to be aware of the status of the app on your receiver so if that app is killed (say, someone else starts casting a different app to the device), it can be notified and exit.
Is there any way of running 2 (or potentially more) applications on the emulator at the same time?
I have an application that obtains its data from another application, therefore I want to modify data in application A and then see how application B handles it.
I'm intending to have some kind of "slider" on application A, therefore I need them both to be running at the same time to see the "slider" on application B update.
You can't have UI threads of two applications running at the same time, but if one of your apps has a background service, that can be running while the UI thread of the other is active. This service could put a notification in the status bar to signify that the data has been updated (actually, I think it's now required that a background service have something in the status bar anyway).
I believe you can also create a "toast" pop-up notification from a background service.
If it's just for testing, your background service can also write messages to the logs which you can see with logcat.
You can use the emulator like a normal phone, so you can run as many apps at the same time as you want. When you say "running", are you talking about "debugging"? You can install any number of apps using adb install, or by just running it through Eclipse. Running a new app won't stop the previous one (besides, you can always go to the app menu and start your other app).