Hello, Mark!

hello, Zaur!

how can I help you today?

oh, I have tons of questions :)

just a min

first question is about sliding menu and activities

I am using SlidingMenu library by Jeremy Feinstein

and this library assumes that you have one main activity

and sliding menu just switches fragments

is this a right approach of using fragments?

there's nothing wrong with it

DrawerLayout also works best when a navigation drawer entry does not switch to another activity

you *can* switch to another activity, but the effect will be a bit more jarring

I already asked a question on SO about using fragments, can you please check it out: http://stackoverflow.com/questions/15611886/am-...

again, there is nothing intrinsically wrong with what you are doing

it will make configuration changes perhaps a bit more interesting, to ensure that when the user rotates the screen, they wind up with the right fragment showing

it may also make the BACK button a bit more challenging, to determine what is the right thing to do there

yes, the second question is about config changes...

what I've done before - I used this bad trick with android:configChanges

now I want to do everything right

for example,

I have feeds fragment

with endless adapter

when I rotate the device, I want to preserve scroll state and all the data in adapter

and if there is networking in progress, I don't want it to reset

I understand how to save simple data in Bundles

example: I have an Activity with FeedFragment

FeedFragment is a ListFragment, with EndlessAdapter of objects that implement Parcelable interface

fragment is saved into backstack, so you can't use setRetainInstance(true)

how can I save listview scroll position and all data in adapter?

so I can restore it after screen rotation or other config change

I am not aware of a limitation on setRetainInstance(true) regarding the back stack

your data presumably should be somewhere outside the activity entirely (e.g., singleton cache of persistent data store)

your scroll position can be saved via onSaveInstanceState()

Android documentation says so: "Control whether a fragment instance is retained across Activity re-creation (such as from a configuration change). This can only be used with fragments not in the back stack."

OK

it does not much matter

again, your data presumably should not be owned by your activity, and a scroll position is a simple int, which works well with onSaveInstanceState(0

er, onSaveInstanceState()

data is owned by fragment

hopefully not

I would really hope that an app that shows "feeds" persists its data

now, if you want a fragment to be a local in-memory cache of that data, that's fine

you can always go with the model fragment pattern

as I did in the tutorials in the book

a model fragment is a fragment with no UI, just there as a data maintainer across configuration changes

it also would manage any tactical background operations for loading that data (e.g., file or database I/O)

since it has no UI, it would not be on your back stack, and therefore can be retained

so I can change adapter data to this fragment, and the restore after FeedFragment recreation, right?

change == save

sorry)

the data that your adapter adapts would be managed by the model fragment

your ListFragment(?) that has the ListAdapter would retrieve its data model from the fragment, either directly or by way of the hosting activity

ah, now I got it.

and how the architecture will look like if I want to persist feeds data?

I have no good way to answer that completely, in the abstract

your in-memory data cache should be scoped to who all needs the data

a model fragment is fine when a single activity needs the data

if multiple activities need the data, you probably will want some sort of singleton cache, reachable from those activities

ok. I need to read that in your book.

one more question:

regarding scrollbars in ListView

if you have items with different height, scrollbar's size is jumping up and down

is there a way to avoid this?

not really

the scrollbar height is an estimate

your results may not match the estimate

because I have seen some apps, that don't have this annoying feature...

I know of no way to affect the scrollbar height calculations

that does not mean that there is no means to do it, just that I cannot think of one

maybe there is another custom AdapterView

that can estimate the height more accurately? :)

as I have seen, Facebook app doesn't have scrollbars at all

when watching my newsfeed

neither do you

scrollbars, by default, only appear while scrolling

unless you specifically arrange for them to show up persistently

even if I scroll, facebook is hiding scrollbars

then they disabled them, perhaps using android:scrollbars

ok, next question is about Horizontal AdapterView

as far as I know, HorizontalScrollView does not recycle views

so app may fail with OutOfMemory error

correct, as it is not an AdapterView

is there any good AdapterView with horizontal scrolling?

I want to create scrolling photo-feed

the only currently-maintained one from Google is ViewPager (which, while not an AdapterView, allows you to do more memory management)

there's a third-party horizontal ListView floating around somewhere

but you can't use ViewPager inside ListView

and I need to do that)

http://stackoverflow.com/questions/15006150/how...

I need photos to be scrolled horizontally

inside ListView

to be honest, I detest that UI structure, and so I have done zero research as to how Pulse, etc. pull it off

if you find apps that have it, use uiautomatorviewer to see what widgets they are using

hello, Andrea!

ok, got it.

hello

Zaur: let me take a question from Andrea, and I will be back with you shortly

Andrea: do you have a question?

yes

I have a problem with content providers

um, could you be more specific? :-)

I have two tables (one for the subject and one for the notes). I am loading the subject list through a content provider. Then I would like that when the user clicks on a subject it displays just the notes of that specific subject. That means I need to join the two tables right? When should I join them?

"That means I need to join the two tables right?" -- not necessarily

ignoring the provider for the moment, in plain SQL you would be doing something like SELECT note,related,columns FROM notes WHERE subject_id=?

yes

there does not necessarily have to be a JOIN there, unless you specifically want to return some columns from the subject table

since you already have moduleName and moduleNumber, you need noteTitle

so the SQL is SELECT noteTitle FROM notes WHERE moduleNumber=?

with no JOIN

at the moment I was keeping the moduleNumber (in the note table) as a foreign key, is that they right way?

ohh right

if I understand your schema correctly, that seems correct

I already got the moduleNumber when a user clicks on the subject

and using a content provider can I do a raw sql?

the provider can; the client cannot

mm

in this case, the client could be providing the moduleNumber=? bit

I don't really get it

query(CONTENT_URI, PROJECTION, "moduleNumber=?", args)

could I obtain it using a cursor loader?

sure

set up the CursorLoader with "moduleNumber=?"

amazing

thanks so much

I need to go, but once again you solved it

happy to be useful

I'll more at the documentaion

:)

Have a nice day

you too!

Zaur: do you have another question?

yes

I wanted to ask about mockups resolutions

what resolutions should a designer use?

to draw a design for handsets

I would argue that the answer is "none" or "it does not matter"

ooh, not again :)

designs need to be fluid, to handle modest changes in screen physical size and density

I haven't seen a plain answer to this question

well, it's akin to asking "what browser resolution should a Web designer use?"

a Web designer needs to ensure that the design works across a range of reasonable sizes

for iOS it is much simpler :)

saying that the browser must be exactly 1024x768, and the design fails for 1023x769, is a #fail

you design for Android much like you design for the Web

ok, I got the idea. but when I design for web, I can think like this:

now, for the purposes of pure mockups, I'd aim at common resolutions, like WVGA800, WXGA800, 720p, 1080p, etc.

most displays have resolution at least 1024 pixels wide

however, the *design* should not be thinking in those terms

so let's make it 1000 pixels wide

yes, that's what I want to hear

what are the most common and popular resolutions

off the cuff, I'd say the ones that I listed

ok, I got it

thank you, Mark

you are very welcome

that wraps up today's chat

the transcript will be posted at http://commonsware.com/office-hours/ shortly

the next chat is tomorrow, 7:30pm Eastern

have a pleasant day!