Hi Mark!

hello, Drasko

how can I help you today?

Well, I have that design for row and I am not sure what would be the correct approach to set layout for it.

I will give you URL soon.

So, this should be one row in RecyclerView and I am trying to avoid nested layouts.

um, nested layouts are unavoidable

For example, I used RelativeLayout as a parent layout

I don't see how you can implement that with just a RelativeLayout

And everything besides that little table are direct children of RelativeLayout, but I am not sure what should I do with that table. Since these columns should be evenly distributed, I guess I should put it into another LinearLayout and setting weight.

personally, I wouldn't do it that way, and I'm not sure that you can get it to work the way you want, but you are welcome to try

But when I put it, then I have to use another vertical LinearLayout for each column, right?

great, how would you do it?

:)

outermost: horizontal LinearLayout

that holds two TableLayouts, using weights to divide the space between them per whatever rules you have

left TableLayout has the league, teams, time, and score

right TableLayout has the title and... ummm... whatever the 1/X/2 table is

ok. :)

nine-patch PNGs for the backgrounds of the cells for the 1/X/2 part

and that's about it

how many passes would be needed to generate TableLayout? For this horizontal LinearLayout two passes will be needed, right?

beats me

IMHO, that's not a major concern

Hahahahaha..

I am curious about it, beacuse I have a performance issues on my mind.

if you have 100 developers working on this, and therefore you have tons of engineering time to spare, and you want to optimize to that level, fine

otherwise, I would start with something that works, then worry about it if and only if there is a user-perceptible issue

no, I have only 1 developer, and that developer is men. :)

...and that developer is me. sorry, typo.

particularly since this is all just text (no lazy-loading images), and since there are only so many football matches, I doubt that the user will perceive lag when scrolling

and yes, you are right about it.

now, you could try PercentFrameLayout or PercentRelativeLayout instead of the horizontal LinearLayout

my performance tests showed no advantages, but Google claims the Percent... classes are faster

hm, interesting idea. i will try one of these options you gave. thanks a lot!

BTW, what *is* that 1/X/2 table?

the rest is recognizable, even to an American like me

hahaha, 1/x/2 represents three types of betting for game called in this example "Final score". So, coefficient that home team (1) will win is 2.40, coefficient that they will have tie (X) is 3.40, and coefficient that guest team will win is 2.90.

ah, OK

data will be changed in every eight seconds and that is why I am curious about performances.

the performance from rendering will be mostly seen when scrolling; rate of model data change should not matter at that level

ok, thanks

oh, one more question.

go ahead

In my project, couple of fragments are registered to listen to Green Robots' EventBus events. Now, I have in some separate thread some data fetching and storing and when that cycle is finished I simply post that this is over. I would like to be notified of it in onEvent and somehow try to update views in UI thread, without using onEventMainThread. What would be the best approach for doing this?

what is the specific problem with using onEventMainThread()?

UI fragments shouldn't be using onEvent(), IMHO

Because of what is stated in documentation: If the posting thread is the main thread, event handler methods will be called directly. Event handlers using this mode must return quickly to avoid blocking the main thread.

I mean, there's nothing stopping you from using runOnUiThread() or something in onEvent(), but I fail to see what you're gaining over just using onEventMainThread()

in this case, you know that the posting thread is not the main thread

are you against of using onEventMainThread() in UI fragments, too?

no; onEventMainThread() is what UI fragments should be using

ah, ok.

thanks!

pure model fragments, which are mostly just containers of data, could use other onEvent...() flavors

but if you're trying to update the UI, you need to be on the main application thread, and onEventMainThread() is the most straightforward way to do that

Don't know what I just did...:)

I don't have any question. Good bye and Happy New Year! If you come sometimes to Belgrade, Serbia, I will be more than happy to meet you. Bye.

have a pleasant day!