![]() ![]() There is another issue worth considering. To make sure an Android apps remains in memory indefinitely, you need to write a server, which is a different type of app Delphi doesn't directly support at this moment. The operating system has the right to terminate "resource hungry" applications. The user can terminate the application at will (although this might not be very common and will be acceptable), but also the operating system might kill the application if the users starts too many apps or apps consuming a lot of memory and CPU. Does this mean we can use a thread to keep an application running (like polling external resources) continuously? That is not true. Using a timers leaves the UI thread free, Ui updates are fast, and everything is smooth:Īgain, you can use the home button, start another application, and your app thread will keep working in the background until it finishes computing the prime numbers. This code uses nested anonymous methods for the main thread function and the synchronization. := 'Thread: ' + Total.ToString īy the way, remember to Start the thread you create, or nothing will happen! If you haven't use recent versions of Delphi you might be surprised, I know. TThread.Synchronize (TThread.CurrentThread, TThread.CreateAnonymousThread(procedure () Procedure TForm5.Button3Click(Sender: TObject) This is the code, which follows the same blueprint of the original version: When the thread needs to update the UI it has to "synchronize" with the main, UI thread. The anonymous threads supported by the Delphi RTL make this operation really easy. That's why the real solution for background operations that will keep the UI thread responsive is to use a thread. In this respect, Android is not much different than Windows. The issue is that the timer event handler is execute in the context of the main thread, the UI thread, the only thread that processes user interaction. 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 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |