i want to create a chat app using flex 4.5 mobile project for android device. For the chat screen, i wanted it to look glossy and stylish. Hence i thought i would use the list component and disable the selection in it. I m able to add the chat messages into the list. But i doubt if large chat data might hinder the performance. Im using a collection and i ve binded it with the list. Whenever i receive a chat i update the collection and it gets displayed in the list. Can someone tell me if his could pose a performance problem as list component is not intended for this purpose.
Thanks..
Why wouldn't a list be intended for this purpose? I'd say a List is the exact component to use for this kind of task. I don't see any performance issues unless you're doing something wrong with the eventListeners or your ItemRenderer. For best performance, use an AS only renderer.
However, as memory is always a concern on mobile devices, you might wanna consider limiting the amount of items in the list, say 100 or so. You likely won't get back to the beginning of the list (your conversation) anyway.
Related
At this point I am not very sure if what I want to do is recommended or if it even has a pattern name.
I currently have a mobile app as a frontend. It shows a card feed that can be configured from the backend. I can say which cards to show, which information, etc.
Right now, the issue is that I load them all at once. For those familiar with React Native, I use a ScrollView which automatically renders all the cards/requests at once.
I would like to improve this, by having one single requests per page, and the response should return the list of API requests that actually load the information.
Like a first API request that brings the configuration of the screen, and then using a ListView to show each requests. The difference is that every request should be actually loaded when they appear on screen. Also, I could support pagination.
Is there any framework that could help? Best practices?
Thanks
PS. I understand this could be opinion based but I am trying to understand if this already has a patter name or framework that could do this for me.
Having an API request that fires on each screen, solely to tell the screen which other API requests to make, is quite inefficient. It sounds like you want an infinite scroll view with pagination on the API side, so you can load a sensible amount of records each time, and then as the user scrolls, load in more below.
There is a good RN package at https://github.com/expo/react-native-infinite-scroll-view for this - the docs are pretty good, but basically the key props are canLoadMore, which tells the scroll view whether it should try to load more content or if it's at the end, and onLoadMoreAsync, where you can provide an async function to fetch the next page of records.
Hope that helps!
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.
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.
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.