This is likely an issue with me not properly understanding threading, however I often try and group code into a seperate class and become hindered by some it not being on the UI thread. I can't find anything that properly explains this however. As an example:
public class MyActivity extends Activity {
#Override
public void onCreate (Bundle bundle) {
HelperClass = new HelperClass(context);
}
}
public class HelperClass extends ContextWrapper {
someMethod () {
// Do stuff
}
}
When someMethod is called, if it's trying to do something thread dependant, I will get an error. I've had this with trying to keep some WebView logic in a seperate class as well as trying to access a realm database.
Using runnables seems very messy and I clearly don't understand exactly what's happening to beable to properly structure my code.
Can anyone explain why? and what the best soloution is?
Related
I have built an Android Java MVVM app, based on some google codelabs no longer published.
But to demonstrate my issue, I found that Google currently has 'Room With a View' app https://github.com/googlecodelabs/android-room-with-a-view, so I cloned it and it exhibits the issue I am experiencing.
In the Activity or Fragment, google suggest to Observe Livedata with a construct like:
public class MainActivity extends AppCompatActivity {
...
protected void onCreate(Bundle savedInstanceState) {
...
mWordViewModel.getAllWords().observe(this, words -> {
// Update the cached copy of the words in the adapter.
adapter.submitList(words);
});
}
}
Which is communicating with a ViewModel :
public class WordViewModel extends AndroidViewModel {
....
LiveData<List<Word>> getAllWords() {
return mAllWords;
}
}
And all works nicely.
However, if I annotate the Activity with #UiThread, and the ViewModel with #WorkerThread, most of my observe methods, asuch as the one above in MainAvtivity, I am told (by lint):
Method getAllWords must be called from the worker thread, currently inferred thread is main thread
Inspection info:Ensures that a method which expects to be called on a specific thread, is actually called from that thread. For example, calls on methods in widgets should always be made on the UI thread.
I see three options:
My Observes and VM are badly constructed and need re-work
I can ignore Lint's warning in this case
I have erred in useing #UiThread on MainActivity and #WorkerThread on ViewModel?
Happy to hear which it is. First SO question, so apologies if I have fumbled in my submission.
I tried an Observe on Livedata as listed above, and I annotated MainActivity #UiThread and ViewModel #WorkerThread. I expected to not see a lint warning on the Observes.
I'm using an ASyncTask in my app to get some data (a short URL) via a REST API from a web service (Bitly).
When the ASyncTask completes I want to pass the result back to my MainActivity.
Getting the data back to the MainActivity is acheievd by using the onPostExecute method of the AsyncTask.
I've read and read and read about how to do this and there seem to be two general approaches.
Originally I was using a 'WeakReference' approach whereby at the start of the AsyncTask class you create a weak reference to your MainActivity as follows:
private class getShortURL extends AsyncTask<String, Void, String> {
private WeakReference<MainActivity> mainActivityWeakReference;
myASyncTask(MainActivity activity) {
mainActivityWeakReference = new WeakReference<>(activity);
}
{etc etc}
With this approach your AsyncTask class sits outside of your MainActivity class and so a lot of things need to be referenced via the weak reference.
This worked fine (except I suspected - possibly incorrectly - that this weak reference may have been the cause of occassional NPEs), but I then found another way of doing things.
This second approach involved moving the ASyncTask class inside of the MainActivity class.
This way I was able to access everything that was accessible in the MainActivity class directly, inlcuding UI elements and methods defined in the MainActivity. It also means that I can access resources such as strings etc and can generate toasts to advise the user what is happening.
In this case the whole of the WeakReference code above can be removed and the AsyncTask class can be made private.
I am also then able to do things like this directly in onPostExecute or to keep this in a method within the MainActivity that I can call directly from onPostExecute:
shorten_progress_bar.setIndeterminate(false);
shorten_progress_bar.setVisibility(View.INVISIBLE);
if (!shortURL.equals("")) {
// Set the link URL to the new short URL
short_link_url.setText(shortURL);
} else {
CommonFuncs.showMessage(getApplicationContext(), getString(R.string.unable_to_shorten_link));
short_link_url.setHint(R.string.unable_to_shorten_link);
}
(note that CommonFuncs.showMessage() is my own wrapper around the toast function to make it easier to call).
BUT, Android Studio then gives a warning that "the AsyncTask class should be static or leaks might occur".
If I make the method static I then get a warning that the method from the MainActivity that I want to call from onPostExecute cannot be called as it is non-static.
If I make that method from MainActivity a static method, then it cannot access string resources and any other methods that are non static - and down the rabbit hole I go!
The same is true, as you would expect, if I just move the code from the method in the MainActivity into the onPostExecute method.
So...
Is having an AsyncTask as a non-static method really a bad thing? (My
app seems to work fine with this warning in AS, but I obviously don't
want to be creating a memory leak in my app.
Is the WeakReference appraoch actually a more correct and safer approach?
If I use the WeakReference approach, how can I create things like toasts which need to be run on the UI thread and access string
resources etc from the MainActivity?
I read somewhere about creating an interface but got a bit lost and couldn't find that again. Also would this not have the same kind of reliance on the MainActivity that a WeakReference does and is that a bad thing?
I'm really looking for best practice guidance on how to get some data back to the MainActivity and the UI thread from an AsyncTask that is safe and doesn't risk memory leaks.
Is having an AsyncTask as a non-static method really a bad thing? (My app seems to work fine with this warning in AS, but I obviously don't want to be creating a memory leak in my app.
Yes, your Views and your Context will leak.
Enough rotations and your app will crash.
Is the WeakReference approach actually a more correct and safer approach?
It's lipstick on a dead pig, WeakReference in this scenario is more-so a hack than a solution, definitely not the correct solution.
What you're looking for is a form of event bus from something that outlives the Activity.
You can use either retained fragments* or Android Architecture Component ViewModel for that.
And you'll probably need to introduce Observer pattern (but not necessarily LiveData).
If I use the WeakReference approach, how can I create things like toasts which need to be run on the UI thread and access string resources etc from the MainActivity?
Don't run that sort of thing in doInBackground().
I'm really looking for best practice guidance on how to get some data back to the MainActivity and the UI thread from an AsyncTask that is safe and doesn't risk memory leaks.
The simplest way to do that would be to use this library (or write something that does the same thing yourself, up to you), put the EventEmitter into a ViewModel, then subscribe/unsubscribe to this EventEmitter inside your Activity.
public class MyViewModel: ViewModel() {
private final EventEmitter<String> testFullUrlReachableEmitter = new EventEmitter<>();
public final EventSource<String> getTestFullUrlReachable() {
return testFullUrlReachableEmitter;
}
public void checkReachable() {
new testFullURLreachable().execute()
}
private class testFullURLreachable extends AsyncTask<Void, Void, String> {
...
#Override
public void onPostExecute(String result) {
testFullUrlReachableEmitter.emit(result);
}
}
}
And in your Activity/Fragment
private MyViewModel viewModel;
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
viewModel = ViewModelProviders.of(this).get(MyViewModel.class);
// ...
}
private EventSource.NotificationToken subscription;
#Override
protected void onStart() {
super.onStart();
subscription = viewModel.getTestFullUrlReachable().startListening((result) -> {
// do `onPostExecute` things here
});
}
#Override
protected void onStop() {
super.onStop();
if(subscription != null) {
subscription.stopListening();
subscription = null;
}
}
I have to communicate between an Android Activity and another Java class. In a very, very stripped down version of what I want, I want the Java Class to run, and when it's done, set some information. To get a more specific idea of what I want to happen:
Activity {
CallJavaClass(); // Doesn't return anything, would be very bad form
GetInfoFromJavaClass() // Once the JavaClass has finished what needs to be done
}
What I could do:
Set a global variable in JavaClass that my Activity can access. I'd rather not do it this way, as I would have to implement some kind of OnChangedListener on that object in the JavaClass.
Use an Interface with Setters/ Getters. The problem with this is my JavaClass is a Singleton, and most of its methods are static, which is a no-go when working with an Interface.
Create a separate class that handles these variables. I would rather keep it simple and not have to use a bunch of different classes to do this, though.
So what do you think would be the best solution? If needed (and probably will be), I can provide more information about what exactly I want done. Thanks for your help in advance.
Sounds like something you could use AsyncTask for http://developer.android.com/reference/android/os/AsyncTask.html
then again, it depends on the specifics of what you're going for
AsyncTask should resolve your problem:
private class myTask extends AsyncTask<Void, Void, Boolean> {
protected void onPreExecute() {
super.onPreExecute();
// do something before starting the AsyncTask
}
#Override
protected Boolean doInBackground(Void... params) {
// do what you want to do
return false;
}
protected void onPostExecute(Boolean success)
{
super.onPostExecute(success);
// do something right after you finish the "doInBackground"
}
}
I currently have developed an app with some GUI and network operations, but I need to make it more of a library without the GUI.
I know that there is a "is library" option under Properties/Android. But the question is: how to move the GUI elements out of the project to a different app, so that the library/project will have only java code; any suggestion ?
Thanks.
If you are making code into a library, you want to try and decouple it as much as you can from anything else. This makes it much more portable so that more people can use the library how they wish. Even though you are using this library just for yourself right now, later on you may wish to release it to others.
For example, maybe your code is like this currently:
public void computeSum(int a, int b) {
int sum = a + b;
mTextView.setText(String.valueOf(sum));
}
Right now this code is tightly coupled with mTextView. Instead, it makes sense to rewrite the code like this:
//In library
public int computeSum(int a, int b) {
return a+b;
}
and
//Somewhere in your app
mTextView.setText(String.valueOf(computeSum(3,4)));
This is a small change, but you can see that computeSum() is no longer coupled with mTextView. This makes it much easier to use throughout your project and even other projects. Now the computeSum() method is part of an API.
So for your network calls, try to decouple them from your GUI stuff either by using callbacks or return values.
In regards to your latest comment:
You could create a wrapper like so:
public class UIWrapper {
public Runnable runnable;
public SomeUiCallback callback;
}
And then use this in your AsyncTask:
public class YourTask extends AsyncTask<UIWrapper, Void, Void> {
SomeUiCallback mCallback;
protected void doInBackground(UIWrapper... wrapper) {
mCallback = UiWrapper.callback;
UIWrapper.runnable.run();
}
protected void onProgressUpdate() {
}
protected void onPostExecute() {
mCallback.runYourUiStuff();
}
}
I wrote that code quickly so it likely won't compile, but hopefully you get the idea. I think something like this would work, not sure if it's the most elegant solution. You can replace the Runnable with whatever you want to run in the thread.
So both UIWrapper and YourTask would reside in your library. You would create the UIWrapper and then use that in the YourTask.
I'm using Parse with my Android app, and my code looks like this:
public class SignupActivity extends Activity {
//Collect signup data
User.signupInBackground(data);
}
public class User{
//User methods, constructors, etc
public static void signup(data){
ParseUser pUser = new ParseUser();
//Build data into pUser
pUser.signUpInBackground(new SignUpCallback() {
public void done(ParseException e){
if (e!=null){
Log.v("Signup",e.toString());
}
}
});
So the question is, how do I notify my activity when the signUpInBackground process is complete? I can't have SignupActivity implement SignUpCallback because it's an abstract class and I have to extend Activity.
Ultimately, what I'm trying to do is display a dialog box or waiting animation, and then get rid of it when the background thread is done. Alternatively, the background thread could launch an activity. The problem with this is that the User class and the anonymous inner class don't have their own Context, so they can't start activities.
I'm fairly new at this, so thanks for your help.
Several approaches might work given your current code structure.
Create a Handler in SignupActivity and pass that to the User so it has a way of interacting with the activity.
Make SignUpCallback an interface instead of an abstract class.
Create an instance of a concreate subclass of SignUpCallback in your SignupActivity class; it will have access to the methods of SignupActivity.
I'm assuming that signUpInBackground is executing on a worker thread and that the callback is invoked from that thread. If that's correct, then in all cases you will need to interact with SignupActivity through a Handler. Thus, I'd suggest method #1 unless the other approaches allow for cleaner code.