My application allows users to chat with friends (like skype or whatsapp), so I have an Activity for displaying a "conversation" (a list).
The user can change from one conversation to another.
So, the problem is changing from one list to another, or "updating" the whole list of messages.
What is the best way to do that? (performance and memory)
- Remove all elements from the list and add the new messages?
- Use multiple ListViews and Adapters?
...
Thanks!
I'd say it all depends on how you're storing the messages, and a lot of other parameters revolving around that.
However, I would probably cache the messages locally so that when the user selects a new conversation, they first get the to see the old messages while loading the new ones. One ListView, one ListAdapter of some sort and a List that I clear out when switching between conversations.
That might not be the most optimal approach, but that's how I'd do it in the given scenario.
Related
I'm trying to achieve isolation and modularization, so I store data in different apps that talk to each other.
I have a custom ContentProvider for public "foos" called FooContentProvider.
A second ContentProvider in a second app should hold some "bar" for some of the foos based on the matching "foo_id".
A third app should now be able to display a ListView with all the foos and if available, also the bars.
Now I'm stuck on how to organize my code. Can I get my FooBarContentProvider to list foos with associated bars or should I join these only in the FooBar ListView App? How can I still leverage the databases involved without duplicating data or having to store the joined table in memory?
Option #1: Two ContentProvider joined into a MatrixCursor using CursorJoiner
I found CursorJoiner that I could use to fill a MatrixCursor which I could probably use for my FooBarContentProvider or optionally just in the FooBar ListView App to back the ListView but I would expect a considerable lag at startup and memory issues if the foos and bars get into the many hundreds or thousands (which power users will achieve) and of course it would not work nicely if the data changes and new foos arrive.
Option #2: Use only the FooContentProvider and provide the BarContentProvider from a precompiled HashMap<String, Bar>
If the FooBar ListView was backed by the FooContentProvider, it could fill the "bar" data from a Map. This way I could reduce having to parse both ContentProvider prior to showing the first data to only one of them. Bars are smaller and strictly less than the foos in my case and changes to the foos are driven from a service, while the bars are mainly user input, so this would probably also be the better option for notifyChange() to work.
Option #3: Let a proxy ContentProvider collect the data into a merged database
A proxy ContentProvider could listen to the other two and provide the database I need but it would waste a lot of storage as especially the FooContentProvider will easily go into the hundreds of MB.
Option #4 ????
Is there a good option #4? How can I have a ListView that is backed by two ContentProvider in a way that all works smoothly especially at startup and changes in the data get propagated to the ListView quickly?
Here's something interesting- How do I display information both from my content provider, and some real-time data from the web (which I don't want to save to my content provider?).
1.CursorLoader and CursorAdapter won't do IMO since I don't want to save the information to my content provider.
2.AsyncTask and updating the view in onPostExecute won't work, since right now I am displaying information from my content provider through cursorAdapter etc. and since the screen itself is an AdapterView subclass, when the loading is finished, the view might belong to some other element (recycled)
3.Service won't do for the same reason as #2 (and besides that, in this case, the background thread is coupled with the UI, so that doesn't seem like a natural solution).
**********Optional specific details starting from here if the picture isn't clear******
Say that I have some app which allows users to follow stocks.
I have a content provider, that at the path content://whatever.my.package.name/follows
has some information about which stock the user is following, whether or not it was sent to my server already (so it does have already some 'real time' data displaying through it), the parameters the user is interested in following, etc.
When displaying this information, I want to include some real time information from the web. I already have the necessary method implemented, but I can't think of a natural solution (see above). In particular, the real time data certainly cannot be saved on the same path (/follows) since this isn't a natural part of what I have in mind when I am thinking about the object "follow",but I do want to present the real time information about the stock, and it does relate to the follow presented on the screen (for example, a follow includes a start price, so we want to present the change from that start price to the real time price of the same stock etc).
I'm can't think of a good design I could use, so help will be appreciated :)
If the only thing that stops you from using the content provider is that you don't want to store the informations in it, then don't store it. Remember that a provider is just some abstraction above some data source. Nobody is going to stop you from using a in memory sqlite database for storing the live data.
Then you have two data sources and can build relations on them for displaying purposes like with sqlites attach_database or in code. Of course the live data is gone as soon as the provider is shut down so you must be able to handle that case.
EDIT
Hmm, ok. So touching the provider is a no go. You said the views are adapter views. How about using Volley or something similar to fetch the data in the adapter itself and cache it there. Whenever a view is requested (i.e in 'onBindView' when using RecyclerView) check the adapter cache for the data. If it does not exist or is outdated start fetching the data. When the request returns notify the adapter that the dataset changed. It then would start requesting views again making the next cache probe a hit. If you are fetching the data for each item in the cursor try to pass the index/position of the item to the request so that you can notify the adapter that a specific item has changed.
I'm constructing an API which is going to be used by an Android and an iPhone app. The app gets a list of events which can regularly be updated. There are currently two ideas.
Creating it using pagination so that it first loads the first 10 events to load results on the screen, and when the user scrolls further it should load more events. I then regularly poll the API to see if there are any new events.
First get the paginated list of id's of events (also first 10), after which the apps should get the full event details in separate threads using one call for every event. In that way it can load all events simultaneously which supposedly makes it faster.
I tend to lean more towards the first solution because it's more simple, but somebody else said the second is a way better idea. I have the idea that the separate threads only add complexity to the case and don't increase the speed significantly. I know that the best way to know is to test it, but building both and testing it takes a lot of time. I therefore wonder whether there are any best practices in getting a continuously updated list of events from an API.
So; which of the two do you think would be best and why?
It depends on the amount of data your events contain. If each event description is only a few fields don't bother to load each event in a separate thread, the overhead will kill any possible performance gain - just get all data in the get events request.
If it is a lot of data per event description, you can argue whether you really want to preload all event descriptions before the user selects an event - probably the user will never click on any of the events, then you did load the data for nothing.
That said, it is also not a bad idea to prepare your API to enable both: Get a list of short event descriptions and a call to get event details for a certain event (or a list of event ids), or get a list which contains the full event descriptions.
I'm trying to make an application for android that consist in multiple choices, each one depending on the previous one.
At first, a list with some options is displayed, after choosing one, I send a petition to a webserver database and send back the new options and create a new activity with the new options and so on till the last list of options.
I use asynctask for the petition sending and use putExtra to send the information between activities.
The problem is that I don't like this approach. Too many activities and cycling through them is a pain, and when the last option is chosen, I would like to go back to the main screen but I have a bunch of activities to handle first and I dunno how to do it.
Any idea I'm missing of how to approach this problem? Is possible to reuse the same activity? Each option is packed differenly as the databse query is different.
Any help would be welcome :)
I can't find a specific example of this, though it seems like it would be a fairly well-tread path, and one of the primary purposes of a sync adapter. I have implemented most of this but still have some problems to figure out. Here is my basic strategy right now
PerformSync
Figure out the last item stored locally
if there are no local items, pull new items to a certain maximum size
if there are local items, pull new items until reaching local items
delete items over the maximum item size
I have a list adapter with a content observer that should reflect the synced information.
Question:
If all of this is sound, my current dilemma is how an when to delete items from the database. I am assuming I should refrain from any deletions while the content is in use, but in my sync adapter, how do I know if the data is currently being observed? (static map of observers?)
Supplemental:
Beyond that, I would love to have some examples of this in action, so I can anticipate other problems. I know about the google IO talk, it has some great high level philosophy, but specifics would do wonders for many non-guru devs.
I would think this is an extremely valuable function that all Android advocates would want to be done, and done right, as the sync adapter presents one of the most desirable features of Android, and can only help to increase the userbase, helping all of us.
Just a suggestion: maybe sync adapter should only add new items but not delete old ones and deletions should be done by the app.
Note: it seems that in Android Gmail deletions are happening while app is showing emails. Try deleting/archiving message in web-gmail and then menu-Refresh in Android: sync will run in the background and then message will be gone without any notification. So it seems to be acceptable.
Update:
Maybe your sync adapter should check if your activity is active and if not delete old items. How to check if your activity is active: http://www.mannaz.at/codebase/android-activity-foreground-surveillance/