I am building an application for both iOS and Android using Xamarin cross platform. I have one project called "Core", and then one for iOS and one for Android.
In the shared "Core" project I want to show a loading animation that I made, while fetching the current location from the device. I can get my locationWatcher, start it, and call LocationWatcher.CurrentPosition directly, but since it has just started watching for location updates, it hasn't yet had time to get any location.
My solution to this is to wait 2 seconds after starting it and then get the location. However I don't want to wait asynchroneously, I want the UI to be locked while waiting. This is because the user should not be able to do anything until current position os known.
I currently achieve this by having a loop:
DateTime startTime = DateTime.Now();
while ( (DateTime.Now() - startTime).TotalMilliseconds() < 2000) {
//Locking the UI here, but it's what I want so it's ok.
}
This seems like an ugly 'hack' for something that in Java would simply be "Thread.sleep(2000)"
Is there a better way of doing this?
The multiplatform way with Xamarin Forms would be to
await Task.Delay(ms);
Edit:
After reading that you really want to block the mainthread heres the multiplatform way to block a Thread:
Task.Delay(ms).Wait()
Blocking the UI thread is bad practice, since among other things it could cause the device to mark the app as "not responding". You are also not guaranteed that the position will have been determined in two seconds, so in the best case your suggestion is only a partial fix.
What you'll really want to do is to block UI input by disabling the possibility to give input (there should be methods to disable your UI elements) and then see if there's a callback from the geolocation service when it has determined your location. In the callback, re-enable the UI elements. If such a callback does not exist, perform the location lookup synchronously on the UI thread with RunOnUIThread/InvokeOnMainThread, so that the thread is blocked only until it returns.
If you want to go ahead with your solution anyway,
RunOnUiThread(() => Thread.Sleep(2000));
should do the trick, but I really recommend against doing that. On iOS, you'll have to do
InvokeOnMainThread(() => Thread.Sleep(2000));
Related
I'd like to know the code or configuration needed to set that.
In my app, there are some places where I'm willingly make the app to sleep for several seconds, as it's needed for some reasons, with a Thread.sleep(long millis) function.
Problem is that on some Android APIS, at least on 25 and 26, usually that system message pops up in few seconds, confusing the user and maybe even causing the application not to fulfill the needed operations that need to happen while that sleep is happening if the user ends the app, which might cause even malfunctioning of the application.
I'd like to find a way of either forcing Android to wait for a good time like, for example, 1 minute, or to make Android aware that it's not that app isn't responding, that is willingly on a Thread.sleep function.
Is there any way to do that?
I'd like to find a way of either forcing Android to wait for a good time like, for example, 1 minute, or to make Android aware that it's not that app isn't responding, that is willingly on a Thread.sleep function.
TL;DR there is none.
Android apps should at all times be able to yield their position in the foreground to other apps. It's up to the users if they want to wait while some lengthy download is taking place or if they prefer to do something else and come back later.
You can't execute Thread.sleep() on the UI thread for long because this would "freeze the UI".
An example: Users should be able to leave your app by pressing the BACK Button at any time they wish to. If your method is blocking the UI thread, Activity#onBackPressed() can't be executed so the users can't quit.
What can you do? Move the heavy work to another thread (using e.g. AsyncTask or IntentService or some plain worker thread) and show some type of progress indicator to the users if necessary. You can/ should also toggle visibility or enabled state of Buttons etc. if required to avoid clicks which can't be processed at that point in time.
I think you have an implementation problem. The system message, known as ANR (Application Not Responding) occurs when the application cannot respond to user inputs, this may be caused by Ui thread blocking and that may be your case.
To avoid blocking the UI Thread just run your long time operations asynchronously. There are many ways to do that. You could use AsyncTask, AsyncTaskLoader, Thread, RxJava... Here you have some links to help you with that:
https://developer.android.com/training/articles/perf-anr
https://google-developer-training.gitbooks.io/android-developer-fundamentals-course-concepts/content/en/Unit%203/71c_asynctask_and_asynctaskloader_md.html
http://www.vogella.com/tutorials/RxJava/article.html
I'm trying to determine whether or not I download data in my android application. I can do this by making the method return true when it does download data, but the listener doesn't seem to be invoked until all other code is finished running (meaning it waits until a pause in your code). So I'm wondering if there is a way to sort of "forcibly" invoke these listeners? Perhaps by creating the listener in a different thread? Would this work or would it be a waste of time? I've already tried to sleep on the main thread for a few seconds, but that doesn't seem to do it either. If it wouldn't work, could you explain when exactly these listeners are invoked? Thanks in advance.
To add onto my question, I am NOT using the realtime database. I understand how realtime triggers work, but I am using the Firestore, so I am only getting data once, not getting realtime updates :)
As you have already noticed with the API calls that deal with reading and writing data are fully asynchronous. This means that the call always returns immediately, without blocking the code to wait for a result. The results come some time later, whenever they’re ready, since it may take some time for this. Depending on your connection speed and the state, it may take from a few hundred milliseconds to a few seconds before that data is available. So Firebase, already is using another thread (other than the main thread) to get the work done.
Calling a synchronous function on your app’s main thread could freeze the app indefinitely, which is a terrible UX. On Android, it could also soft-crash with an Application Not Responding (ANR) dialog.
Doug Stevenson, has explained in his post everything that you need to know about Fireabse asynchronous behaviour and what you need to do/avoid when dealing with Firebase.
I have been working on an Android application that uses Google maps and then runs some lengthy network intensive operations in the background. Currently, I am using a thread to run them on and they take anywhere from 30 seconds to 7 minutes to finish. After watching a few courses on Pluralsight about AsyncTasks and Background services, I now know that threads should ideally not be used for anything taking more than a few seconds. I am now altering my solution to run live with GPS rather than taking several minutes to perform the operations. The goal is to update an array every OnLocationChanged event.
I am having trouble in thinking about how I could alter a global array every OnLocationChanged event while also accessing it from the UI main thread. What is my best option for accomplishing this? Would I be able to use a process or AsynTask to accomplish this or would I need to go client/server route? Where would the OnLocationChanged be called?
First off, onLocationUpdated is called on the UI thread. So you don't have to worry about multithreading there.
Secondly- if you have a variable that needs to be touched by two threads you just use a semaphore and take it before you need to access it on each thread, and release it when done. Make sure to keep that block of code as small and quick as possible. There's more advanced stuff you can do for high performance needs, but that's good enough for 99% of code.
Thirdly- as I mentioned in my comment, your understanding of threading is wrong. The UI thread should not be used for more than is needed. AsyncTasks should not run for more than a few seconds (as there's a single thread they run on by default, so running long would block other requests). But a Thread can run as long as it needs to, and should be used if it needs long term background processing.
I'm looking to find the "correct" way to get a fix on the user's location as a one-time task. At the moment, my execution flow is roughly:
The user presses a button.
The handler (contained in the main Activity code) registers a GPS location listener with the system, set to update as fast as possible, launches an ASyncTask, and finishes.
Pre-execution, the ASyncTask generates a ProgressDialog, effectively blocking any other UI usage.
For it's background task the ASyncTask waits for either a timeout or for a location fix for the GPS.
Post-execution, the ASyncTask either displays some relevant data to the user if a location was found, or displays an error in a toast if it was not. It also de-registers the listener of course.
Now, while this works, there are numerous downsides. Firstly, and quite obviously, all other UI interaction with the app is blocked while a request is being made. This isn't too bad currently, as the app's main function is to perform this task, and there isn't much else to do while it's working - it also stops the user from spamming the button. Additionally, I'm not sure if the post-execution phase of the ASyncTask is really the place to put my location-found logic (it makes an internet call, which is something that itself might be better off inside an ASyncTask?). However, I'm not sure how else to pass back the fact that a location has been found and that the main thread should do something.
I was hoping that someone could inform me as to the "right" way to do this - i.e. is using an ASyncTask like this correct, should there be a Service involved, and how should I deal with the internet-call post-location-found), and perhaps even give some wise words on how in general to deal with the control flow of an app which has to make somewhat "blocking" calls.
I can provide code if needed, might take a bit to get it cut down to a minimum solution.
Blocking calls and blocking UIs are generally to be avoided. See Reto Meier's take on the subject.
Hence, I'd dump the AsyncTask entirely. Disable the Button that the user uses to kick off the fix request. Use a postDelayed() Runnable for your timeout mechanism. And, allow the user to do something (read help, etc.). Use the progress indicator in the title bar to indicate that you're working on getting the location, dismissing the indicator when you get a fix or when your timeout occurs.
(it makes an internet call, which is something that itself might be better off inside an ASyncTask?)
It certainly should not be done on the main application thread. When the location fix comes in, kick off the AsyncTask to fetch the data.
I'm writing an app using Android 2.1
At some point, I call setOnKeyListener
In particular, I write...
editfield=(EditText)findViewById(R.id.edittext);
editfield.setOnKeyListener(this);
This is in the main thread, in the onCreate callback.
At this point in the code, I would like the processing to stop and wait for the
keyboard input. If I let the code run on, the logic will break, soon enough.
I suppose I could put the machine in a wait loop until a keystroke invokes the onClick method. I could also create a wait loop at the point where the input from the user was required. But I don't feel comfortable with either of these solutions. (A related problem is this -- at a certain point in the code, the screen must be lit up. Must I check this before proceeding past that point?
Perhaps I'm not good with documentation, but I have not been able to find anything specific that answers these questions.
Can someone explain to me how to accomplish the timing I need and, more generaly, where I can find info on these questions?
Thanks in advance.
-looking in DC
The Android key system is event-based, it does not work like the old ask-and-wait mechanisms of C/C++ etc for obtaining user input.
If you blocked/waited - then what would happen if the user pressed the Home key (you can't catch that) or navigated to another app - your app would force close because it would still be waiting and your onPause etc would not execute.
My suggestion would be:
Put all the code that should occur after the click into some function
Place the listener at the end of onCreate, this way no more code will be executed after you set the listener
When you get a key-down, call your function. Thus the statements in your function will only execute after a key down
If however, this is for a game, then it is acceptable to have a thread dedicated to touch/key-events which sleeps for 50s or so to avoid event overload (but this must not be the main UI thread!)