If you wait too much time, your algorithm will take forever. If there is too much processing, you might still have a unresponsive application. Using a timer seems nice, but it is really not ideal. Now what is interesting is that the timer events will keep being executed and processed even if you hit the home button or bring another app to the foreground. For a slower phone, you might want to device the process in smaller chunks. This time the listview content is updated for each tenth of the calculation, and you should not get the "unresponsive error". Procedure TForm5.Timer1Timer(Sender: TObject) įor I := TimerI to TimerI + MaxValue div 10 - 1 do Procedure TForm5.Button2Click(Sender: TObject) In this scenario, the counter and total value (TimerI and TimerTotal) must be global form variables, and we need to disable the button to avoid re-entrance: This can be achieved using a timer and doing some of the processing for each timer execution, suspend the work, and wait for another timer event. One is to split the long computation is many shorter ones. What is the alternative? There are at least a couple.
The issue is that if you run the code with a large enough MaxValue ( I used 200,000) you'll see the following:Īndroid sees the app is not responsive and suggests killing it.
The display of the status actually doesn't work because the screen is not refreshed until the end. counts the prime numbers below the given value The simplest solution is to compute the value in the OnClick event handler of a button: If you've read my book, the code won't be new: let's compute how many prime numbers are there below a given value. To better explain the scenario and show some possible solutions, let me start with some code.
In fact, the Android OS does complain almost immediately if your app is not responsive. You should probably avoid those also on desktop, but on mobile the scenario is worse as your app will own the entire screen. You should never do slow, blocking operations on mobile.
0 kommentar(er)
