rx android vs mosby pattern load data recyclerview - android

I am working on an Android app. The code I attach is creating a recyclerview. The very first thing we do is to create an asynctask that would fetch data on an SQLite database and load it into the adapter->recylcerview. While the background task is working, a progressdialog is shown to the user.
public class HomeActivity extends AppCompatActivity
{
private RecyclerView recycler;
private RecyclerViewAdapter adapter;
private SwipeRefreshLayout swipeRefresh;
private progressDialog progressDialog;
// ... some code here
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
// ... some code here
createRecyclerView();
loadRecyclerView();
// ... some code here
}
private void loadRecyclerView()
{
new LoadingBackgroundTask().execute();
}
private void createRecyclerView()
{
Context context = getApplicationContext();
recycler = (RecyclerView) findViewById(R.id.recycle_view_home);
recycler.setHasFixedSize(true);
RecyclerView.LayoutManager lManager = new LinearLayoutManager(context);
recycler.setLayoutManager(lManager);
adapter = new RecyclerViewAdapter();
recycler.setAdapter(adapter);
recycler.setItemAnimator(new DefaultItemAnimator());
}
private class LoadingBackgroundTask extends AsyncTask<Void, Void, List<items>> {
#Override
protected void onPreExecute() {
super.onPreExecute();
progressDialog = ProgressDialog.show(HomeActivity.this, getString(R.string.dialog_load_list),getString(R.string.dialog_please_wait), false, false);
}
#Override
protected List doInBackground(Void... params) {
List<items> lists;
//Data Source Class ( SQLite)
ListDS listDS = new ListDS(getApplicationContext());
list = listDS.getList();
return list;
}
#Override
protected void onPostExecute(List result) {
super.onPostExecute(result);
//it inserts de list on recyclerview performing animation
adapter.animate(result);
progressDialog.dissmiss();
swipeRefresh.setRefreshing(false);
recycler.scrollToPosition(0);
}
}
}
So far, so good. However, as you probably know this code has some well-known issues; for example if I rotate the screen while asynctask is doing its magic, it will crash the app.
I've tried an alternative I've seen Googling, rxandroid.
(Sorry if I typed something wrong, I am doing it by memory)
public class HomeActivity extends AppCompatActivity
{
private Subscriber suscriptor;
private progressDialog progressDialog;
//some code ....
#Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
suscriptor = new Subscriber() {
#Override
public void onCompleted() {
progressDialog.dismiss();
Log.d("SUSCRIPTOR","ON COMPLETE");
}
#Override
public void onError(Throwable e) {
Log.d("SUSCRIPTOR","ON ERROR");
}
#Override
public void onNext(Object o) {
adapter.animate((List<items>)o);
}
};
Observable.create(
new Observable.OnSubscribe<List<items>>() {
#Override
public void call(Subscriber<? super List<items>> sub) {
progressDialog = ProgressDialog.show(HomeActivity.this, getString(R.string.dialog_load_list),getString(R.string.dialog_please_wait), false, false);
List<items> lists;
//Data Source Class ( SQLite)
ListDS listDS = new ListDS(getApplicationContext());
list = listDS.getList();
sub.onNext(list);
sub.onCompleted();
}
#Override
protected void finalize() throws Throwable {
super.finalize();
Log.d("OBSERAVBLE","FINALIZED");
}
})
.observeOn(AndroidSchedulers.mainThread())
.subscribeOn(Schedulers.newThread())
.cache()
.subscribe(suscriptor);
}
#Override
public void onDestroy()
{
if(suscriptor!=null)
{
if(!suscriptor.isUnsubscribed())
{
suscriptor.unsubscribe();
}
}
super.onDestroy();
}
}
Now the app is not crashing anymore when I rotate the screen. However, the observable keeps working on the background until it finishes but as I unsubscribe to avoid crashing, I don't receive the results properly. Moreover, progressbar disappears even though the observable keeps working as I mentioned.
Looking for a solution, I found there is a pattern called "Ted Mosby" which seems to solve my problem. Although it looks promising, I think is too much coding for something I felt it is not worth it and that rxandroid may have a workaround.
So, my question is how can I get what I want without getting immersed in an architectural coding mess too big for my purpose? Could you give an example if you guys have solved this? Do you think I am wrong and I should implement TedMosby pattern?

Mosby is a Model-View-Presenter (MVP) library. So the pattern you named "ted mosby pattern" is actually MVP.
But you didn't have understood what MVP is all about. It's not about retaining async running taks, even thought this could be achieved with Mosby. MVP is about separation of concerns. View is just displaying UI elements, Presenter is controlling the View, i.e. the presenter tells the view: now display the progress diaolog, now hide the progress dialog, etc. In other words, the presenter controls the state of the view. The Model could be an async task or a RxJava Observable. The Presenter than gets the result back and tell the view to display it. You code is decoupled into 3 layers Model (also called business logic) and Presenter and View. The advantage is that you can change the view (i.e. replace progress dialog with an progressbar widget) without touching any code that loads data (Presenter and business logic). Additionally with MVP your code becomes testable.
So what you should compare is: Should I use AsyncTask or RxJava for loading data. With Mosby you would execute your http request in the presenter. While orientation changes are done the presenter doesn't get destroyed (and hence the background task doesn't get canceled).
However, MVP is not the solution for everything. If you have to ensure that a single http call is executed correctly (i.e. sign up for a community) you should think about using an android service.

What you can do is whatever you do in activity like your AsycTask and RecyclerView, put it inside a fragment and, setRetainInstance(true) in onCreateView() method of fragment and load that fragment in your activity.
setRetainInstance(true) won't let your fragment instance destroy when screen is rotated.

Your Observable should handle himself the fact on unsubscription. There are two mechanism for this:
check subscriber.isUnsubscribed. You can do it between or after "heavy" steps
add unsubscription callback. You can use it to stop long running operations, release resources etc
Take a look at this code:
Observable.create(
new Observable.OnSubscribe<List<items>>() {
#Override
public void call(Subscriber<? super List<items>> sub) {
sub.add(Subscriptions.create(new Action0() {
#Override
public void call() {
cancelLongRunningOperationIfItStillRunning();
}
}));
if (!sub.isUnsubscribed()) {
//start long running operation here
}
}
})
.doOnSubscribe(new Action0() {
#Override
public void call() {
}
})
You shouldn't reference to your activity/context/progress dialog etc inside Observable. Instead use doOnSubscribe if you want to do some side effects.

Related

How to prevent BottomNavigationView animation from stuttering

(First of all: no, it's not a duplicate of mentioned question :P read, then push the button.)
I'm using the BottomNavigationView in one of my apps, loading Fragments with lists, which get their data from a ViewModel/LiveData/Dao. When selecting a Fragment via the BNV, it seems its animation somehow fights for UI-Thread time with the Fragment loading, causing it only to finish completely after the lists are displayed - which confuses me. I was under the impression, that LiveData calls are being handled async by default?
Stuttering gif
Is this a known thing?
ViewModel
public class ScheduleViewModel extends ViewModel {
private final LiveData<List<ScheduleInfo>> arrivals;
private final LiveData<List<ScheduleInfo>> departures;
public ScheduleViewModel() {
arrivals = SigmoDb.schedule().getArrivals();
departures = SigmoDb.schedule().getDepartures();
}
public LiveData<List<ScheduleInfo>> getArrivals() {
return arrivals;
}
public LiveData<List<ScheduleInfo>> getDepartures() {
return departures;
}
}
Fragment
public class ArrivalsFragment extends MainFragment {
private ScheduleDetailsAdapter adapter;
private ScheduleViewModel viewModel;
private final Observer<List<ScheduleInfo>> arrivalsObserver = new Observer<List<ScheduleInfo>>() {
#Override
public void onChanged(#Nullable List<ScheduleInfo> infoList) {
adapter.setData(infoList);
}
};
public static ArrivalsFragment newInstance() {
return new ArrivalsFragment();
}
#Override
public void onCreate(#Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
adapter = new ScheduleDetailsAdapter(getActivity());
// using the parent fragment as LifeCycleOwner, since both its
// child Fragments use the same ViewModel
Fragment parent = getParentFragment();
if (parent == null) {
parent = this;
}
viewModel = ViewModelProviders.of(parent).get(ScheduleViewModel.class);
}
#Override
public void onActivityCreated(#Nullable Bundle savedInstanceState) {
super.onActivityCreated(savedInstanceState);
reObserveViewModel();
}
// remove and re-add observer until Google fixes the multiple observer issue
// TODO: remove when Google fixes the issue
// https://github.com/googlesamples/android-architecture-components/issues/47
private void reObserveViewModel() {
viewModel.getArrivals().removeObservers(this);
viewModel.getArrivals().observe(this, arrivalsObserver);
}
#Nullable
#Override
public View onCreateView(#NonNull LayoutInflater inflater, #Nullable ViewGroup container, #Nullable Bundle savedInstanceState) {
View view = inflater.inflate(R.layout.fragment_arrivals_departures, container, false);
RecyclerView recyclerView = view.findViewById(R.id.rv_schedule_details);
LinearLayoutManager llm = new LinearLayoutManager(this.getContext());
recyclerView.setLayoutManager(llm);
recyclerView.setAdapter(adapter);
return view;
}
}
For info: I timestamped the ViewModel's constructor start and end (to rule out those calls somehow being on the UI thread - takes 1 millisecond).
Narrowed down the issue
After Robin Davies' answer, I tried the Android Profiler and although I get some GC events now and then, I don't get them all the time with the stuttering being there every single time. However, delaying setting of the adapter data in the observer by 100ms seems to let the BNV animation complete when switching to the ArrivalsFragment:
No stuttering gif
All I did was changing
private final Observer<List<ScheduleInfo>> arrivalsObserver = new Observer<List<ScheduleInfo>>() {
#Override
public void onChanged(#Nullable List<ScheduleInfo> infoList) {
adapter.setData(infoList);
}
};
to
private final Observer<List<ScheduleInfo>> arrivalsObserver = new Observer<List<ScheduleInfo>>() {
#Override
public void onChanged(#Nullable final List<ScheduleInfo> infoList) {
new Handler().postDelayed(new Runnable() {
#Override
public void run() {
adapter.setData(infoList);
}
}, 100);
}
};
So it seems that this part of your answer
Also if you post list results back to the foreground thread and
populate the adapter while the animation is running, that will force a
layout pass that will interfere with animation.
is the one I was struggling with in my particular case. While I'm a bit disappointed having to revert to using delays to make the animation fluent, I'm happy to have found the culprit and thank you very much for your help :)
Yes this is common enough problem.
Assuming that you've already moved heavy processing onto an background threads...
If you are doing really heavy lifting on the background thread, you can trigger garbage collects, which can block the foreground thread long enough to cause stuttering. Also if you post list results back to the foreground thread and populate the adapter while the animation is running, that will force a layout pass that will interfere with animation.
Try using the CPU usage/profiling tools to see what exactly is holding up the foreground thread.
Solutions to consider would be to postpone population of the fragments until the animation is finished. Or pre-populate the fragment. Or maybe block the background thread while animation is running (perhaps). Or postpone the animation until the fragment is populated and laid out (which gets potentially unpleasant). If the problem isn't caused by a garbage collect, you could delay creation/population of the adapter until the animation is finished.

Android manage multi request rxJava on rotation device

I'm using MVVM on android application and i want to manage requests and rxJava on device rotation, how can i disable request after rotation device and countinue from last request?
this is my simple code to know how can i doing that, but i can't find any document and sample code about it
#Override
public void onCreate(#Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
binding = DataBindingUtil.setContentView(this, R.layout.activity_register);
...
Observer<String> myObserver = new Observer<String>() {
#Override
public void onError(Throwable e) {
// Called when the observable encounters an error
}
#Override
public void onComplete() {
}
#Override
public void onSubscribe(Disposable d) {
}
#Override
public void onNext(String s) {
// Called each time the observable emits data
Log.e("MY OBSERVER", s);
}
};
Observable.just("Hello").subscribe(myObserver);
}
I'm using latest version of rxJava
Handling rotation is a cool challenge in Android. There're a few ways to do that.
1- Services: You can use a service and handle your network requests or other background operations in service. Also with Services, you'll seperate your business logic from ui.
2- Worker Fragment: Worker fragment is a fragment instance without a layout. You should set your worker fragment's retainInstanceState to true. So you'll save your fragment from orientation change and will not lose your background operations.
Why Worker Fragment? If you set retainInstanceState true to a fragment with layout, you'll leak views.
If you're using MVVM you can implement ViewModel as a Worker Fragment which as setRetainInstanceState = true
3- Global Singleton Data Source: You can create a global singleton data source class which handles your operations in an independent scope from Activity / Fragment lifecycle in your application.
4- Loaders: Loaders can recover state from orientation changes. You handle your operations with loaders but they are designed to load data from disk and are not well suited for long-running network requests.
Extra: You can use Path's Priority Job Queue to persist your jobs:
https://github.com/path/android-priority-jobqueue
Edit: You can check my repo for handling device rotation without using Google's new architecture components. (As an example of Worker Fragment which i pointed in my answer.)
https://github.com/savepopulation/bulk-action
You have the following options:
Use some global Singleton, or your Application class, that holds your logic, not within your Activity's lifecycle
Use a Service that runs next to your activity/application
Use a Loader
Global state is often bad and makes your code hard to test / debug. Services tend to be overkill.
For your use case of device rotation and continuing where one left off you'd usually use a Loader, which keeps running on rotation and only gets destroyed once you leave the activity.
I also recently wrote an article about one possible solution to use Loaders together with RxJava to keep state during orientation changes.
You can take advantage of Fragment#setRetainInstance(true). With that flag set, fragment is not destroyed after device rotation and can be used as an object container. Please look at this sample which also stores Observable - https://github.com/krpiotrek/RetainFragmentSample
you need to override
#Override
public void onSaveInstanceState(Bundle outState) {
super.onSaveInstanceState(outState);
}
When device is rotated store data in bundle then inside on create check
#Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
if(savedInstanceState == null){
//saved instance is null
}else{
//get your stored values here
counter = savedInstanceState.getInt("value",0); //here zero is the default value
}
}
How I'm doing this is to have a singleton class (or any long living Object as explained by savepopulation earlier, but - the trick is to store the loaded data in a BehaviorSubject, and subscribe to that subject in the Activity instead of the original network request.
This way:
public class MyNetworkSingleton {
// This static service survives orientation changes
public static MyNetworkSingleton INSTANCE = new MyNetworkSingleton();
private final BehaviorSubject<String> dataSubject = BehaviorSubject.create();
public Observable<String> getData() {
if (!dataSubject.hasValue()) {
refreshData(); // No data is loaded yet, load initial data from network
}
return dataSubject;
}
public void refreshData() {
someDataSourceCall().subscribe(new Observer<String>() {
#Override
public void onError(Throwable e) {
// Remember, this point also needs error handling of some form,
// e.g. propagating the error to the UI as a Toast
}
#Override
public void onComplete() {
}
#Override
public void onSubscribe(Disposable d) {
}
#Override
public void onNext(String data) {
dataSubject.onNext(data); // this refreshes the internally stored data
}
});
}
private Observable<String> someDataSourceCall() {
return // some network request here etc. where you get your data from
}
}
and then:
#Override
public void onCreate(#Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
...
Observer<String> myObserver = new Observer<String>() {
#Override
public void onError(Throwable e) {
// Called when the observable encounters an error
}
#Override
public void onComplete() {
}
#Override
public void onSubscribe(Disposable d) {
}
#Override
public void onNext(String s) {
// Called each time the observable emits data
Log.e("MY OBSERVER", s);
}
};
MyNetworkSingleton.INSTANCE.getData().subscribe(myObserver);
myRefreshButton.setOnClickListener(new Button.OnClickListener() {
public void onClick(View v) {
// refresh data from network only when button is pressed
MyNetworkSingleton.INSTANCE.refreshData();
}
});
}
This way only first time you need the data from network it will be loaded, or when the user clicks a refresh button (myRefreshButton).

Design solutions for fragments and asynchronous processing in Android

I struggled with some issues about design complex tasks with fragments
use. Fragments and asynchronous approach are quite new for me, so I think it will be better to describe my app.
Application
App works with GitHub API and has two screens: list of repositories and details about selected one. For retrieving data from json I use Retrofit and store it in SQLite. Little remark As I understood Retrofit can be used asynchronously but in case of additional work with DB it is better to use asynchronous approach for operations under DB also. In my case I'm checking internet connection: in case of absence I load data from DB. Otherwise I upgrade DB and then use it. Now I want to add fragments for different screen density support( usual master - detail workflow).
And my questions are
Where is the better place to run async tasks? Is it a right solution to make it in activity and then pass result to fragments?
What is the better solution for asynchronous processing? As I understood from my search about that, AsyncTask is deprecated but the easiest solution.
AsyncTask is a pain in the rear. Many beginners still seem to use it, but imho it's not worth learning it. Sooner or later you'll be bugged out by it because AsyncTask is error prone, has lots of caveats and tons of boilerplate code.
Retrofit does make it's calls asynchronously automatically, so you've got that covered already. Retrofit also plays very nice with RxJava which is I guess considered the way of doing asynchronous things on Android these days.
RxJava has a steeper learning curve initially than other patterns, but it's worth learning. If you got your database stuff working already, it won't be much work making ti asynchronous with Rx.
As for
Is it a right solution to make it in activity and then pass result to
fragments?
If you don't follow an MVP design approach, which is okay, in my opinion it's absolutely okay to do 'business logic' stuff in the Fragment and not let the Fragment call the Activity, then let the Activity get back to the Fragment. Whichever is easier for you and suits your app.
You can place your background thread anywhere, but make sure it is cancelled if the class is garbage collected, and don't keep references (Context, callbacks) in your thread.
public class MyActivity extends Activity {
private static interface OnDownloadThreadCompleteListener {
public void onDone(String data);
}
private static class DownloaderThread extends AsyncTask<Void, Void, String> {
private OnDownloadThreadCompleteListener mListener;
public DownloaderThread(OnDownloadThreadCompleteListener listener) {
mListener = listener;
}
#Override
protected String doInbackground(Void... args) {
// Do your network request here
return result;
}
#Override
public void onPostExecute(String data) {
if (mListener != null && !isCancelled()) {
mListener.onDone(data);
}
mListener = null;
}
#Override
public void onCancelled() {
mListener = null;
}
}
private DownloaderThread mThread;
private OnDownloadThreadCompleteListener mListener;
#Override
public void onCreate(Bundle bundle) {
super.onCreate(bundle);
mListener = new OnDownloadThreadCompleteListener() {
#Override
public void onDone(String data) {
Fragment fragment = getFragmentManager().findFragmentByTag("fragment_git");
fragment.show(data);
}
}
mThread = new DownloaderThread(mListener);
findViewById(R.id.btn_download).setOnClickListener(new View.OnClickListener() {
#Override
public void onClick(View v) {
mThread.execute(null, null, null);
}
}
}
#Override
public void onPause() {
super.onPause();
if (mThread != null) {
mThread.cancel(true);
}
mThread = null;
mListener = null
}
}

Update TextView for different fragments from AsyncTask

I was looking over this answer and it seemed to only deal with a single textview.
Basically, I have an Android application with n fragments, each of which has a textview that is populated from a remote call to a database. Each time the fragment is selected, that remote call will fire and the textview should be repopulated.
Currently, I am using a central AsyncTask to accomplish this, however I am starting to wonder if it is the correct way to go about doing so (some textviews take too long to update for small amounts of data, some don't get updated at all, etc.).
Here is the code from my RetrieveData class. Essentially, it figures out which textview is to be updated, and then populates that textview.
public class RetrieveData extends AsyncTask<String, String, String[]> {
private int txtViewID = -1;
private Activity mainActivity;
public RetrieveData(Activity a) { mainActivity = a; }
protected String[] doInBackground(String... urls) {
String[] data;
// call web script to return JSON data
...
// figure out which fragment called which script
if (urls[0] == "get_A.php") {
data = parseJSONdata(); // parse out the JSON
txtViewID = R.id.txtViewA; // find INT-based ID
} else if (urls[0] == "get_B.php") {
data = parseOtherJSONdata(); // different type of call
txtViewID = R.id.txtViewB;
} else ... {
...
}
} catch (Exception e) {
System.out.println("Error: " + e.toString());
}
return data;
}
#Override
protected void onPostExecute(String[] op) {
if (txtViewID != -1) { // call was made
TextView tv = (TextView)mainActivity.findViewById(txtViewID);
tv.setText(op[0]);
}
and here is how I call this from a Fragment:
public class MainFragment extends Fragment {
Activity mainActivity;
public MainFragment(Activity a) { mainActivity = a; }
#Override
public View onCreateView(LayoutInflater inflater, #Nullable ViewGroup container, #Nullable Bundle savedInstanceState) {
View v =inflater.inflate(R.layout.main_tab,container,false);
new RetrieveData(mainActivity).execute("get_A.php","1");
return v;
}
}
To me, its very kludgy and probably belies my newness to Android, so any suggestions for improvement are heartily appreciated.
You can do a couple of things to improve the robustness and performance and fix some issues which will creep in later:
Don't use findViewById() outside of init/setup type methods. It is an expensive call as it has to "search" your hierarchy for the ID you are requesting.
Don't use an overloaded constructor for your Fragment which takes the Activity. The Fragment default constructor should be empty. This allows the system to properly re-create your Fragment when configuration changes (screen rotates.) The Fragment will receive its attached Activity at the correct time when its onAttach() method is called, so there is no need to do this.
You shouldn't need the Activity at all for what you're trying to do. Instead, have your Fragment get the correct TextView from your layout in its onCreateView(). What you do from there is really up to you:
Pass the TextView instance to your RetrieveData class constructor as the one to be updated. This eliminates the hard coded IDs in your RetrieveData class, which gets rid of some explicit coupling and is a better approach. This is still very tightly coupled, though, since it depends on having a specific View so still not a great option IMHO.
Have the RetrieveData class define an inner Callback interface and have the Fragment implement it. The constructor for RetrieveData can then take an instance of the Callback interface (e.g. your Fragment instance) and when its onPostExecute() runs it just calls back the Fragment with the appropriate data. Now it is up to your Fragment implementation to make the right decision on what UI element it is hosting to update with the data. It may be a TextView now, but in the future you could make it something else, etc. Now you have decoupled the class from all explicit UI ties and put the responsibility on the thing hosting the UI elements: the Fragment.
Here's a brief example of the 2nd bullet:
public RetrieveData extends AsyncTask<String, String, String[]> {
// Define the interface used to provide results
public interface Callback {
public void onDataLoaded(String[] result);
}
private Callback mCb;
public RetrieveData(Callback cb) {
mCb = cb;
}
...
#Override
public void onPostExecute(String[] result) {
mCb.onDataLoaded(result);
}
}
public MyFragment extends Fragment implements RetrieveData.Callback {
TextView mResult;
RetrieveData mAsyncRetriever;
#Override
public View onCreateView(LayoutInflater inflater, #Nullable ViewGroup container, #Nullable Bundle savedInstanceState) {
View root = inflater.inflate(R.layout.main_tab,container,false);
// Get the TextView now where we want to show results.
// This avoids calling findViewById() constantly.
mResult = (TextView)root.findViewById(R.id.example_result);
...
}
#Override
public void onResume() {
// Keep a reference to the AsyncTask so we can properly
// cancel it when our lifecycle events dictate so.
mAsyncRetriever = new RetrieveData(this);
mAsyncRetriever.execute("get_A.php");
}
#Override
public void onPause() {
// If we have a pending data load going on, kill it.
if (mAsyncRetriever != null) {
mAsyncRetriever.cancel(true);
mAsyncRetriever = null;
}
}
#Override
public void onDataLoaded(String[] result) {
// Only pulling the first result provided
mResult.setText(result[0]);
// The RetrieveData is done, get rid of our ref
mAsyncRetriever = null;
}
}

Fragment and AsyncTask

I have got the same problem for 8 days now and i hope that someone can help me, i am working on an application that parse multiple RSS feeds and display them on listview with fragment but the problem is that the UI get blocked for 2 to 4 seconds, and every time the user touches the screen the application crashes.
I tracked the problem and i found out that i had to bring the data asynchronously, which i actually did, but every time i have a fragment, the same problem occurs.
In fact,the fragment blocks when it brings data if it does it from a main thread, while i actually bring data asynchronously, that's why i can't get the reason for the blocking.
This is how i change my code, this is my interface
public interface OnTaskFinishedListener {
void onTaskFinished(ArrayList<Article> articles);
}
i am getting the ArrayList in the AsyncTask like this
public class AndroidSaxFeedParserAsync extends AsyncTask<String, Long,ArrayList<Article>> {
ArrayList<Article> rssItems = new ArrayList<Article>();
public URL feedUrl;
OnTaskFinishedListener onTaskFinishedListener;
public AndroidSaxFeedParserAsync(OnTaskFinishedListener _onTaskFinishedListener)
{
onTaskFinishedListener = _onTaskFinishedListener ;
}
#Override
protected void onPostExecute(ArrayList<Article> result) {
super.onPostExecute(result);
onTaskFinishedListener.onTaskFinished(result);
}
#Override
protected ArrayList<Article> doInBackground(String... params) {
//....
return rssItems;
}
}
and finally i get it here in my fragment like this
public class FeedPlayerIndexFragment extends SherlockFragment implements OnTaskFinishedListener{
String url="http://www.whatever.com/index.php?format=feed&type=rss";
ArrayList<Article> feeds;
ItemAdapterArticle lfa;
public View onCreateView(LayoutInflater inflater, ViewGroup container,
Bundle savedInstanceState) {
new AndroidSaxFeedParserAsync(new OnTaskFinishedListener() {
#Override
public void onTaskFinished(ArrayList<Article> articles) {
}
}).execute(url);
View view=inflater.inflate(R.layout.main, container, false);
//....
return view;
}
#Override
public void onTaskFinished(ArrayList<Article> articles) {
lfa = new ItemAdapterArticle(getActivity().getApplicationContext(), articles);
}
}
Problem is that you're using AsyncTask.get() call which is actually blocking. There's another solution on this problem which doesn't block the UI thread. You need to define a simple interface:
public interface OnTaskFinishedListener {
void onTaskFinished(List<Article> articles);
}
The calling Fragment should implement this interface. When instantiating the AsyncTask you send your Fragment as an OnTaskFinishedListener instance as a parameter to constructor. The AsyncTask should hold the reference to OnTaskFinishedListener instance, and when the work is done, in onPostExecute(), you call onTaskFinished() on the instance. Now, in the Fragment you can respond to this call and use the articles parameter to populate your UI components. Hope this helps.

Categories

Resources