hello, Chandra!

how can I help you today?

Hi Mark

Is it still recommended to use Asynctask? Compare to Loader?

that depends on who is making the recommendation :-)

some would say "neither, use RxJava" or something like that

personally, given the choice of those two, I would use a retained fragment with an AsyncTask

What is your recommendation? :-)

What is "retained fragment"?

a fragment on which you call setRetainInstance(true)

to say "hey, when the activity is destroyed and recreated due to a configuration change, please just pass off this fragment to the new activity, instead of destroying and recreating the fragment"

Is it for not reloading when the device rotated or some other events?

So the fragment is saved in the memory when the activity destroyed?

correct

So, you recommend Loader when DB-related case?

the only time I will use a Loader personally is if I am querying a ContentProvider, and sometimes not even then

Or on what example of case do the Loader best use?

other people are happier with the Loader framework than I am

Ah, I see..

this blog post from ~3 years ago sums up my feelings: https://commonsware.com/blog/2014/03/31/cwac-lo...

the concerns that I present there are a bigger issue for libraries (like my now-discontinued CWAC-LoaderEx)

and so for a private project, having a loader that does not implement the entire contract can be fine

I also still didn't get the function of Content Provider itself if I didn't want my app to publish anything to other apps

I agree -- I only implement a ContentProvider if I am publishing content to other apps

So, basically, I'm already good with only Asynctask and retained fragment right?

there is nothing wrong with that combination IMHO

I just worried since other tutorials show that Content Provider and Loader is a must

the authors of those tutorials are welcome to their opinions, even though I do not share them

Yep I'm on your side, Mark.. mostly because I still didn't understand Loader & Content Provider much :-D

I have another question regarding ViewHolder

What is tag on ViewHolder?

I assume that you are referring to using the view-holder pattern with an AdapterView, such as a ListView

I read description in your book but what I understand is it only give a cache to the View

Yes correct

a view holder pretty much is just that: a cache of findViewById() lookups for widgets inside the ListView row (or the equivalent for other AdapterViews)

with RecyclerView, a RecyclerView.ViewHolder sometimes gets used for more stuff (e.g., as a presenter or controller for that individual RecyclerView item)

but that's less common with the view holder pattern with ListView

the tag is simply a way of attaching the view holder to the ListView row, as ListView deals only with rows

in particular, it is a way of attaching the view holder to the row without having to create some custom View class to do so, which is a pain

the name "tag" comes from Java Swing in the 1990's

(and I do not know why Swing named it "tag")

If I'm just starting up, can I just skip the ListView and directly use the RecyclerView?

sure

in general, for new development, I recommend RecyclerView

it is more flexible, if somewhat more cumbersome to set up initially

Thanks for the clarification, Mark

Regarding the Layout Inflater, do LayoutInflater.from(context) and getLayoutInflater() give the same result?

AFAIK, if context is an Activity, those are equivalent

personally, I trust getLayoutInflater() more

I only use LayoutInflater.from() for non-activity cases (e.g., managing a View from a Service)

I see..

I have another question on ContractClass in SQLite

I do not know what ContractClass is, sorry

I mean the Contract in SQLite

Must we specify Contract? Can we specify with string directly when accessing from other classes?

I still do not know what you are referring to

Something like this

the Contract pattern is mostly for ContentProvider, and frankly is not all that useful there either IMHO

you do not need a Contract class to work with SQLite

I see.. that's why I confused

So if we didn't use ContentProvider, just use SQLiteOpenHelper will be enough right?

sure

I finally understand some stuffs after this conversation :-) thanks, Mark

Most probably last question

Regarding the network connection, what are your recommendation? Picasso, retrofit, okhttp, or other else?

um, well, yes to all three of those

OkHttp is a general-purpose HTTP client

and, it optionally plugs in as the engine behind higher-order APIs for images (Picasso) and REST-style Web services (Retrofit)

which of those three you use depends a lot on what sorts of HTTP requests you are making

for example, if you are not working with a REST-style Web service, you have no need for Retrofit

on the whole, I have been happier with that trio of Square libraries than anything else that I have tried (Volley, Ion, HttpClient)

So if my purpose is to use REST and to download images, combination of Picasso and Retrofit would be good right?

yes

Or better to use Picasso or Retrofit only if I consider the app size?

sorry, but I do not understand that question

Can I just choose Picasso or Retrofit for both purpose (REST and image downloading)?

no

I see.. ok..

For uploading image like Instagram/FB apps, picasso would be enough right?

Picasso only downloads, unless I missed a part of its API

it is an image loader, that happens to support HTTP/HTTPS as a source of images

Ah I see.. So, what is your recommendation on image uploading?

for uploading images, you might be able to use Retrofit, and if not you would be looking at using a general-purpose HTTP client API like OkHttp

(and Retrofit would only be relevant if the image-uploading were part of a REST API)

image uploading is a complicated topic, in part because your client-side options are limited based on what the server wants

You meant the network related on client side?

hi all

I mean that if the server wants the images to be base64-encoded and put into a form field, that is different than expecting you to do an HTTP PUT of the image to a REST-style URL, which is different than other approaches

Chandra: let me take a question from Ace, and I will be back with you in a bit

Ace: your turn! do you have a question?

Ok, Mark, many thanks :-)

Hi Mark, I'm trying to query my product table using AsyncQueryHandler but I don't understand why Im getting this error: android.database.CursorIndexOutOfBoundsException: Index -1 requested, with a size of 1

does that mean the cursor did not return a row?

no

the "size of 1" means you got one row back

what does the -1 Index -1 mean?

IIRC, the index -1 part means that you did not call one of the move...() methods to position yourself on a valid row

by default, a Cursor is positioned before the first row

if you are expecting a one-row result, you typically call moveToFirst(), then retrieve values from that row via getString(), getInt(), etc.

if you are expecting N rows, a while(cursor.moveToNext()) loop works, where you process each row inside the loop

hmmn okay. thanks. that makes sense. I just tried it now and it works

Android's Cursor is fairly typical of cursor-style APIs, but this particular hiccup is fairly commonplace

I'm glad that it is working for you now

let me take another question from Chandra, and I will be back with you shortly

I was wondering is it best practise to use AsyncQueryHandler?

(personally, I just use my own threads)

or is there some other way?

Chandra: your turn! do you have another question?

okay

Chandra: if you come up with another question, let me know

Ace: back to you! do you have another question?

yes please could you elaborate what you mean by using your own thread?

how to I do that?

when I want to query a database, I fork a thread and do the query there

in particular, I never wrap a database in a ContentResolver

fork a thread? using runnable interface?

or a subclass of Thread, or an Executor, or RxJava

lots of threading options

ohhh interesting. how comes you never wrap it in ContentResolver?

I always want to get away from contentresolver

IMHO, it adds no value for the in-app case

(BTW, I really meant ContentProvider, not ContentResolver)

for publishing content to third-party apps, ContentProvider is fine

for using content within an app, ContentProvider adds overhead and complexity for little added value IMHO

okay yes. that's good to know. I just find all the syntax weird especially having to join multiple tables

agreed

I would like to option to send raw sql query

because Im quite good at sql

just work with SQLiteOpenHelper and SQLiteDatabase directly

you may still want to centralize that logic

but you do not have to sit it behind the ContentProvider facade

ah yes. that is what im looking for.

my tables are getting bigger

and more

so I have to join multiple tables

and the syntax just getting me confuse

okay no more questions

Thanks for your help today.

you are very welcome!

Chandra: if you have another question, go right ahead

that's a wrap for today's chat

the chat transcript will be posted to https://commonsware.com/office-hours/ shortly

the next chat is Thursday at 9am US Eastern

have a pleasant day!