I have some 4500 entries in my database. What is the best way to show them in a ListView. Should I load them all in one stretch when the application initializes or should I use lazy loading? The list will also be searchable and filterable. Could you also point me to some nice articles that would gimme a better idea. Please do give me suggestions.
I would like to point you to here first but I also have some experience I would like to share.
First, showing anything more than say 500 items in a list is probably going to cause users to complain (maybe not though). Users can get overwhelmed with info and it gets annoying for users to scroll to see all of the data (even with filters because some users will refuse to use them if they can scroll).
Second, the data adapter in Android is pretty smart so an adapter over thousands of items will be handled smoothly due to the way Android caches views and iterates through a result set with a cursor which is the subject of that link I pointed you to at the start of my answer.
Related
I was wondering if there is a better way of going about things than the way I am doing it now, any help would be greatly appreciated.
Currently, I am working on a Search Fragment for my app, the idea being that they search (it shows their previous searches whilst they type), then they press enter or click one of their previous searches and results from their search are returned from the API (displaying a list of valid users in the listview) to which the user can then click on the one they want to access.
In total,
Search - > API -> JSONAdapter -> DB/Objects -> Display to User via ListView -> On click in ListView display New Fragment or an overlay.
Currently, I was a bit confused on how to implement it, I made a JSONAdapter that works for the API and submitting the SearchView returns the correct response from the API (However it is not displayed in the ListView). I also have a ListViewAdapter that works with a hardcoded list but doesn't seem to work using the JSONAdapter.
I also made a lot of classes to store the data from the JSONAdapter, I'm not sure if I should be using SQLite to store the values they select after searching (I think I probably should).
I'm sorry this question is such a mess, I'm just a bit lost at the moment.
I can clarify any confusions.
In Summary (TL;DR): Should I just be using the default google suggestions provider for history, should I even be thinking about SQLite or will the API be fast enough, can I use the same listview for previous history & search results?
Thank You.
I think there's no need to store data in Sqlite db, about th list view I think it is better if you used a RecycleView.
I'm developing a personal project with Android and struggling here with some doubts about the better way to develop it.
Well, my project consists of my app consuming a Rest Webservice (which I already developed with Java and Spring) and showing up a list of places on it. The thing is: This list could be huge, something like 2000- 3000 records with description and picture of each place.
I'm using volley and OKHttp to take care of my networking stuff, so far my list of places isn't that long, so everything is alright, but I'm afraid when the list starting to get big, I don't know how my app will handle this.
My questions would be:
1- Should I store the that list on my device and update the list every time I connect to the webservice?
2 - Am I doing correct, retrieving the entire list with just one request? If not, how's the best way to do it?
Thank you guys, I'm new to android stuff, and I'm developing everything by myself, don't have anyone experience around to ask that.
Cheers!
As mentioned in comments You need your app to do "paging" and to load some of the content every time you scroll down.
For example if you will open Facebook app and go over photos you will notice that the first ones always loading the fastest and as you keep scrolling some will be left blank for few moments, thats what paging is all about.
Make sure though not to overload the app with info, specially if you use bitmaps
You can read some good tutorials here
What is the intuition behind views and adapters in Android, that means from where did the person who made this concept get the thought process necessary to create these elements? To elaborate, the concept of circle originated from nature, moon sun such celestial bodies, like wise what is the intuition behind using listview and adapters?
As you probably already know, using ListView (and more recently, RecyclerView) on Android requires the use of an Adapter to get the data from the data source and turn it into something displayable which can then then be shown in the list.
So why did the engineers at Google implement ListView and the backing Adapters the way they did ?
It essentially comes to a few things:
Performance:
Imagine you have 1000 contacts, each with a picture and various pieces of information. You want it to work well, load quickly, and scroll smoothly. The naive way of doing this might be to create a scrollable layout to hold the contacts list, and then simply add a sub-layout for each contact. Unfortunately, this will fail all three requirements: It won't work well, as there won't be enough memory (ram) for all those contacts and especially the associated pictures, and the app will run out of memory and crash; It won't load quickly, as all the contacts and the contact pictures have to be loaded into memory before the list can be shown, which will take a long time; And it won't scroll smoothly because you don't have all of the advanced caching, pre-rendering, and bitmap texture caching that ListView and the adapter does. Use a ListView and an Adapter, and it solves all these problems for you.
Adaptability and ease of use for developers: ListView and Adapters are used for lots of different things, from contacts lists all the way to to complex pages with different answers, comments, and tons of other information in the Stack Exchange Android app. Adapters make working with data from different sources easy: there's a single, common API, which can be used and extended to display any kind of data, much more easily than if every developer had to implement their own solution. Want to load more data when the user has scrolled to the bottom of your list ? Sure, it's easy. Want to have different kinds of items in your list ? Sure, It's really easy.
So, did Google and the Android developers and engineers invent this idea of using adapters ? No.
In fact almost every system or environment which involves showing a list of items uses something similar: The actual list of items, an Adapter behind it, to transform the data and make it displayable, and then the actual data source, which can be anything which gives a list of items, from a database to a web service. It's essentially this: data source > adapter > list where it's displayed. This kind of pattern is used in desktop Windows applications, on iOS, web applications, so the Google engineers took this concept and adapted it to Android.
That's why ListView and Adapters work (and are used) the way they do.
PS: here's a Google IO video by the Google engineers on how to use ListView and Adapters correctly, and a little bit on how they work under the hood: http://youtube.com/watch?v=wDBM6wVEO70.
I am using the endless adapter from https://github.com/commonsguy/cwac-endless
This works great for me, but I am looking to fetch rows not when the users reach the end, but rather before. In other words, I prefer that the user will not see the pending view at all or at least minimize this situation.
I did not find yet the option in this adapter to accomplish this.
Any help would be appreciated..
What is the best approach from a performance perspective to show a ListView with contacts and their phone numbers?
Use CursorAdapter with the contacts cursor and make the phone numbers query when bindView is invoked for each row
Copy all the contacts and phone numbers to an in-memory array in a background thread and then show them with an ArrayAdapter.
Other solutions?
In my opinion a mix solution should be better. Why this? Because you don't know or it's suppose that in most of contexts you cannot know about how and how many contacts your application will need to list. An also how many contacts are stored in the phone. If we know both answers, surely we can take the most approach solution.
So I suggest you to first bring a fix number of contacts using an in-memory array in a background thread, for example the first 20. Also if you consider that your app will perform more than one request to this service.. it will be awesome to use a sort of caching. The worst approach should be to call again and again the contacts service.
Then for a request for contact #21 you can bring next 20 and so on.
So you can use the advantages of both worlds, and minimize the disadvantages too. Always depends on the application and the context that we are talking about.
I think this would depend on three factors:
How many contacts are we talking about here?
How much time does it take to load each contact? (E.g. do you have a very complicated view that needs to be inflated or do you fetch contact images/etc that requires any network I/O?)
How much contacts are showing to the user at once?
Your solution one would fit most of the cases though the second solution offers some advantages as well:
Solution 1:
Advantage:
Delayed view inflation in a "view as you go" can perform well when it's fast enough to inflate the views without any noticeable UI glitches.
Disadvantage:
If your contacts associate with a lot of data and requires some complicate inflation, you might notice a delay.
Less flexible and extensible comparing to solution 2. As discussed below.
Solution 2:
Advantage:
You have control of all the steps, so you can easily simulate it just as easy as one, but adding things might be easier: searches through whole memory, custom sorting through the array, etc. they work better when you have everything queried to an array that's already there. Or if you want to do custom loading later, or adding some more data regarding the contacts that require some more processing (say network I/O), it might be slightly easier than cursor adapter.
Disadvantage:
Execution: this is not the text-book way to do it. making things more custom will need you to handle all the threads well and handle the initial appearance well. Make sure it scales.
So yea, depending on what exactly are you are working on, choose the appropriate one.
I think http://www.higherpass.com/Android/Tutorials/Working-With-Android-Contacts/ will be an option. Where you can find all of the facility you want...
I think CursorAdapter is the best solution.
Also make sure you watch this video http://www.youtube.com/watch?v=wDBM6wVEO70
It talks about optimizations that in my opinion are necessary to make your list scroll smoothly.