I am using Crouton as alternative to native android toasts. I have to display 5-6 croutons one after the another and then call System.exit(0) to exit my app.
The problem is, I see first crouton for 1-2 seconds and the app just exits! The rest croutons aren't displayed at all. This is because when the code is being executed the undisplayed croutons are added to queue. And when it comes to System.exit(0) it exits the app without displaying those queued croutons. I have tried searching for solution for this and came across a solution in which I have to create a new thread, then sleep it for time = sum of durations of necessary croutons and then call System.exit in that thread. But then if I have more or less croutons in another situation then that becomes useless.
So can anyone think of a solution?
Why do you have to quit the app?
In general, in Android, applications should not quit, and show not provide a way for the user to quit them. Quitting an app is handled by the system when the user navigates away from it and goes back to the home screen.
If your application must quit (for example, because of an unexpected condition it can't deal with) and you want to make sure the user sees the information, then the best approach would be to use an AlertDialog to display the information.
So, long story short: revise your UI... if you're sure that this is the right way to do it, then simply don't call System.exit(0). Just show the toasts and then stick around. Eventually the system will decide to quit your app when memory is needed.
Related
I am making a javafx application that simulates a robot vacuum.
I want it to be automated so it would vacuum the environment by itself.
I need to insert a delay so a human can see the steps the vacuum is taking as it traverses the environment.
So far all the delay methods I have tested crash my program if they are inside a while loop.
If I put it outside the while and just click a button for the next step, everything works fine.
It also works fine if I set the delay to really short time, like 1 ms.
Any ideas of why this is happening?
Any application that executes a set of instructions for a while (is busy) and cannot respond to user input or system events is "seen" by Windows as "not responding" and when you try to interact with a "not responding" program, Windows will tell you it crashed.
The problem, you see, is that you try to delay interface updates with a while loop, and that makes your program execute something for a while and while is busy executing your loop it cannot respond to system or user events.
If you want to make delayed updates, use multithreading. Your while loop is blocking the main thread which is also responsible for rendering and taking any input, so you cannot block this thread. Create another thread and share state (eg. use observer pattern). And then you can execute TimeUnit's sleep() in this helper thread and it won't make your app "crash".
I am developing an app which has to perform some background work. For that reason, I am using a Service. Now what I want to achieve suppose the user start the background work and while the work is loading then the user has an option to either minizine the app or wait till the loading is over.
After the loading is over I want to open another Activity. Now my issue supposes the user starts the loading and minimizes the app then when the loading is over the user has not yet returned to the app then if I start the Screen without even the user having my app in his view then the user might get interrupted with his work.
So what I want is when the loading is over, I want to only open if my app is visible to the user and if the app is not visible to the user then I want to wait till the user return back and only when the user returns back I want to open the Screen if the loading is over.
Now what I have thought is I should have a boolean which will track whether the app is visible to the user. On onStop I will set the boolean value to false and onStart I will set the value to true. And again onStart I will check if the loading is finished and if yes then I will open the Screen.
But I want to know whether there is a better way to achieve this? If yes then how. The reason I am looking for a better way is that I want to write a clean code for my app which might avoid bugs and crashes.
That is exactly the scenario LiveData and RxJava are for. Your activity will get the data only when the activity is visible. Your Viwemodel will provide your live data to the activity only when your activity is available and it's lifecycle aware. You can also consider using WorkManager if your app needs to continue to work even after your user closed your app, even if user restarts your app. It also comes with Constraints to optimize your work based on Network, Battery life...and provides livedata for your Viewmodel to consume.
Synopsis: I need a way to start a task and have it persist through onDestroy() of app until it completes, or ability to pick up where it left off.
In my app, I have a ListView containing some items from a database. Hopefully only about 10-30 items, but potentially thousands (if the user never clears it, although I have prompts to clear it from time to time).
I have set up an AsyncTask to perform clearing the selected items from the list when the user wants to. However, I've noticed that the AsyncTask is killed when onDestroy() is called, for example if the user selects all items to delete, presses delete, then swipes app out of Recents while task is still performing.
I remember learning somewhere that a Service persists longer than an AsyncTask, so when the task gets killed I hand off the data to delete to a Service that I created. It does this by
intent.putIntegerArrayListExtra(list);
and get data from it in the Service. The Service persists far longer than the AsyncTask (only about 4-6 seconds), but still not all the way to completion. I know a little about START_XXXX flags, but that would be bad practice for this task, since they'd either send the whole list back to itself, or never really stop.
What is the preferred method to delete selected items from a database without it stopping when the app is killed, or at least to pick up where it leaves off?
Thanks all!
Your problem is very much like this: You have an application open in your favorite OS which is doing things in the background and then in the middle of it, the user force closes it. Logically, it will stop everything it's doing and stop executing and there's not much you can do to interrupt it.
There's no ideal solution to stop this from happening so what most people end up doing is to warn users that stopping the app when this operation is in process can have unwanted consequences.
In Android however, you have another option which is slightly more robust: you can write a persistent background service what continues running even if your app isn't running, but that still wouldn't solve the problem of what happens if the user switches off the phone when you're deleting from the DB? which would be the next logical question given your context. (personally, I would not recommend this approach for your task).
Best you can do is to maybe write a shared preference for every row you've not yet deleted (this will be the full list of rows you want to delete when you start deleting). For every row (or bunch of rows) you delete, change this preference to remove those rows from the preference and then if the app is interrupted, when you restart your app, read this preference and continue where you left off.
Alternatively, do what others do and warn users (by use of dialogs for instance) that they shouldn't stop the app until the delete is done otherwise bad things happen, etc.
I would strongly discourage you from using a service simply because it lasts longer than an AsyncTask. That's way too hacky and not at all reliable.
I have a startingActivity on Google-glass
I want to run it sometimes silently,
meaning it will run, communicate with the server,
get and send data - but the user won't see the app.
The user will see a static card from time to time,
but basically can be in a context of another app.
my tries:
I have thought to create a service instead of my
startingActivity,but there are too many things that relays on the main UI views
If I comment out the setContentView(), all my code that refers
view.findViewById() will fail. no? and besides the user will see a
black screen instead of silent run which i desire.
any other solution for silent run, but yet running the
startingActivity fully?
I'm trying to write a simple app that should mute my mobile phone for a given time. It's my first Android app, but after many hours of reading I think it is nearly completed. But it still has one problem that I can not fix.
I'm using a activity to display the GUI. It has Buttons to set the start and end time, and everything else needed. When the user has entered all the parameters, they are passed to a service. This service uses a handler object, to register 2 callbacks (with Handler.postDelayed). One for start Mute and one for End Mute (in SetMuteIntervall).
The first tests seemed to work, but if I try to mute it for like 30 minutes, it never unmutes. I think it has something to do with the fact, that the mobilephone is or was in standby mode. I also tried to use Handler.postAt() but that didn't work either (and time relative to uptime was somewhat confusing).
So, what should I do to guarantee, that my callbacks are called, regardless whether the phone is in standby or not?
Here's the source of my program:
http://pastebin.com/XAgCeAq9
http://pastebin.com/33nepFV5
Try to use AlarmManager for planning some actions in future. AlarmManager is not standby-mode-dependend and will fire even if device is sleeping.
Your thread are actually stopped then the phone is in stand by mode. If you still want to use thread you can use WakeLock to prevent CPU from going to stand by mode (but still to switch screen off) but this is not the best way in your case.