I'm actually seeing the handler code show up in my profiler. And I'm passing
a lot of small data many times. As the code was initially built for parsing
while loading from the network with xml. And not the download then parse
json code.

In terms of synchronization issues, I use an interface between those pieces
of code anyway. So that shouldn't be a problem.

On Wed, Jan 26, 2011 at 10:24 PM, Pepijn Van Eeckhoudt <
pep...@vaneeckhoudt.net> wrote:

> I tend to prefer the handler approach over synchronized methods just
> because it's less easy to shoot yourself in the foot if only a single thread
> touches your data structures.
>
> Performance wise there shouldn't be any fundamental difference between the
> handler approach and the synchronized method approach since it's all within
> the same process. No data copies are occuring in either case. The one thing
> you might notice is a little bit of additional latency when using the
> handler as this posts a runnable to the end of an event queue.
>
> Pepijn
>
> Op 26 Jan 2011 om 21:28 heeft Anders Aagaard <aagaa...@gmail.com> het
> volgende geschreven:
>
> Thank you! I wasn't sure what was the cleanest way of doing it. And I'm
> very familiar with threading, just not how java does it (and the
> synchronized isn't something I'm familiar with from other platforms).
>
> I'll try to push some of the sorting/filtering into the threads as well, to
> reduce amount of time I spend in the main thread.
>
> On Wed, Jan 26, 2011 at 8:09 PM, Hari Edo < <hari....@gmail.com>
> hari....@gmail.com> wrote:
>
>>
>> If you're sure that all users of the data are within the same process
>> (the
>> same app), then using Java synchronized is the best way to go.
>> However,
>> you will need to be very careful to understand your semaphore
>> dependencies,
>> or deadlock will occur.  "Not responding" is almost as bad as "Data
>> corrupted" due to bad inter-thread communication.
>>
>> The use of Bundles and/or ContentProviders are to enable inter-process
>> data
>> passing, and to avoid some of the danger of errant deadlock
>> situations.
>>
>> On Jan 26, 10:37 am, neuron <aagaa...@gmail.com> wrote:
>> > Hi
>> >
>> > I've got an app that spawns of a seperate thread. Parses JSON data into
>> a
>> > structure. And passes it back to the main thread through a handler. Each
>> > part of data is sent through the handler individually. That worked
>> fairly
>> > well with my previous XML parser, as XML parses data while it downloads.
>> But
>> > JSON doesn't (atleast I haven't found a way to get that working). In
>> either
>> > way the JSON data is much smaller and much faster to parse.
>> >
>> > I've recently added a feature that requires me to load several sources
>> of
>> > json in parallel, parse in the background, and pass all the data back
>> again
>> > using a Handler. This is a bit slower than I was hoping.
>> >
>> > Would it be faster (and possible) for me to do this:
>> > BackgroundThread extends Thread {
>> >     onCreate (Parent) {
>> >         this.parent = parent;
>> >     }
>> >     onData {
>> >         parent.addParsedData(x);
>> >     }
>> >
>> > }
>> >
>> > Parent extends ListActivity {
>> >     ListAdapter list;
>> >     onCreate {
>> >        setListAdapter(list);
>> >        new BackgroundThread(this);
>> >     }
>> >     public synchronized addParsedData(data) {
>> >         list.add(data)
>> >     }
>> >
>> > }
>> >
>> > I'm thinking this won't be thread safe, as ListAdapter is in the parent
>> > thread. Am I right?
>> > Should I instead inside the listadapter (which puts data in an array)
>> have
>> > synchronized access to it's items?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Android Developers" group.
>> To post to this group, send email to
>> <android-developers@googlegroups.com>android-developers@googlegroups.com
>> To unsubscribe from this group, send email to
>>  <android-developers%2bunsubscr...@googlegroups.com>
>> android-developers+unsubscr...@googlegroups.com
>> For more options, visit this group at
>>  <http://groups.google.com/group/android-developers?hl=en>
>> http://groups.google.com/group/android-developers?hl=en
>>
>
>
>
> --
> Weeks of coding can save you hours of planning.
> - <http://code.google.com/p/aagaande/>http://code.google.com/p/aagaande/
>
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to <android-developers@googlegroups.com>
> android-developers@googlegroups.com
> To unsubscribe from this group, send email to
>  <android-developers+unsubscr...@googlegroups.com>
> android-developers+unsubscr...@googlegroups.com
> For more options, visit this group at
>  <http://groups.google.com/group/android-developers?hl=en>
> http://groups.google.com/group/android-developers?hl=en
>
>  --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-developers@googlegroups.com
> To unsubscribe from this group, send email to
> android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com>
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en
>



-- 
Weeks of coding can save you hours of planning.
- http://code.google.com/p/aagaande/

-- 
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

Reply via email to