Kostas
Kostas

Reputation: 2474

Android Concurrency issue

I have strictly separated the layers between different parts of my Android application. At some point of execution I am updating my data from xml service on Internet. That updating takes up about 10 seconds and is done completely in the background - meaning the user interface of an application works fine. However further calls to my class (later - DataManager) which is responsible for data updating (after update has been started but not yet finished) makes my application crash. NullPointerException is thrown with objects which NEVER are null.

So I assume that only one Thread can use my DataManager at one time and calls to DataManager from other threads ends up in exceptions.

I tried various combinations of putting 'synchronized' keywords near sensitive methods but it seems that when update is executing - NOTHING can use ANYTHING from my DataManager.

BTW other classes which are related to DataManager during the execution also seem to hold null objects.

I guess I am just missing some kind of design pattern which is used to deal with concurrency problems and maybe anyone can suggest me something?

Upvotes: 1

Views: 723

Answers (1)

Daniel Werner
Daniel Werner

Reputation: 128

I had trouble dealing with using the Apache http client because of threading issues and I think your issue could be similar in that respect. What I ended up doing was setting up a callback scheme. This may or may not work for you, of course.

This may seem a bit Rube Goldberg-like to you, but it worked for me.

I would have my UI thread call my data manager object with a method that spawned a thread to go and acquire the data. The method's return value is an object that would EVENTUALLY have the data in it. I would have my activity extend an interface, something like "DataCallbackInterface", with a method that the thread would call after it acquired the data (i.e. the last line in run()). Since that call will inherently be within another thread, you'll need to use a Handler to run anything useful in your implementation of the DataCallbackInterface method. When that method is called, you will know for a fact that the data is there and not rely on any strange synchronization flags to get it right.

Upvotes: 2

Related Questions