I need help understanding how I would approach making an Android application that allows the user to scroll through 365 different bitmaps. I'm worried that I will go outside of the memory limits that android allows. I've tried googling, but haven't been able to understand how to approach the problem. Could someone write a very brief hint at where i can start researching this?
It depens on the source of those. I think you would like to use "lazy load ListView".
Checkout this
how about using any class that extends from AdapterView (like listView, gridView,...) ?
the idea is that since the user doesn't really see all of the views at the same time , you can re-use views that are being disappeared when scrolling , and show them as new ones .
watch the video of google called "the world of listView" .
anyway , if you don't wish to use this solution , consider being very "cheap" on the memory , as you are correct - android will kill your app if you use too much RAM .
you can read about handling bitmaps here .
Related
I would like to export data from Android Profiler, I would like to create a comparison graph between two applications. Problem is that I would like to get a percentage of say RAM-usage over a timespan. I know I could do it manually by hovering over the timeline. Problem is this would take an extremely long time doing it for both of the applications, covering both CPU and RAM.
Yes, I've done it manually just for one of the application, but the values aren't correct.
How would I go to tackle this problem. Anyone here that had experience working with Android Profiler and collecting data to later make a graph of some sort out of it?
Would appreciate the help or a beneficial way to do it.
I have been working on an android project that has a feed similar to Instagram/Facebook and I am trying to figure out the best strategy for consuming the data from my database.
Specifically I am wondering if I should query all the data at once (assume 50 records +) or if should I perform queries as the user scrolls -- grabbing so many records at a time. If the ladder, about how many posts/records should I get per query assuming the content/size is similar to that of a Facebook post.
I've spent a descent amount of time researching this issue and haven't come across anything so any suggestions would be much appreciated. I do apologize if this issue has already been addressed and if you could you just post the location of the answer that'll work too.
Thanks in advance!!
Fetching all the data can be too much at times and your app will have very slow response time, that why it's better to load some data at a time and just add it as you get it. In my opinion it's best to load 2 screens of data at a time, so try and see how many posts you can have in a screen and get x2 (if on one time you can see 5 posts, load 10 at a time) or load for example 10 at the first time and 5 each next time. This truly is your preference as I think.
If this is the method you want to use keep in mind that there are different screen sizes for android (from android wear to different sized mobile phones, tablets and smart tv-s) so try making different methods for each group if devices. You can maybe have an abstract class (or interface) with the method and have every other class for different size extend or implement (regarding of using class or interface) to make the code more well written, easier to change and reusable.
But all in all it's in your hands and you can make it by your liking. Hope this helps, and gives you some matter to wrap your head around.
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
as a Java developer I have been tasked to develop a small application for Android. Basically, it should download certain images from a web source of ours, then display them. Usually, there are four images, the number will not change.
The download works fine, checking a version number, fetching the files, and they get sent to the application specific files directory.
Now, leaving the safe Java haven and sailing into Android waters, I find myself struggling alot. There's an almost impenetrable wall of incompatabilites, wrong information and bad or non-working examples.
I have found at least 15 examples for displaying images and switching between them. I've tested 5 so far, including a professional training DVD. Each and every one of those had at least one problem that made it impossible to continue. From not having an "R.styleable" to using varaibles where they are not available to implementations of inner classes that are different from the example.
As this could mostly be a problem of compatability and badly written information sources (I'm looking at you, developer.android.com), I'll try to ask you, the friendly guys of StackOverflow.
So far, I understand that by downloading the images dynamically, I need to use an Adapter that provides the images to the Gallery. I am using API level 7 or 8 (I've tried the most recent level, but the examples did not work there, as well), and I'm just looking for an example that will actually work.
Please help a fellow out. I really want to like the platform, as it's openness and community speak to my freedom-loving side.
You have done hard bit, this is easy. First you scan the folder and save file paths into an array. Then in a gallery view which gets its images from a custom BaseAdapter in getView you display them. At which stage do you get stuck?
Have you tried this: http://developer.android.com/resources/tutorials/views/hello-gallery.html
What considerations should one be mindful of when constructing a GLSurfaceView-centric UI?
This is for a game and the bulk of the UI will be an intro screen (start, options, about, exit) and a level selector screen. I've put a lot of time into the rendering/animation for the game using OpenGL, and I'm no graphic artist, so taking the OGL UI route seems to make sense to me. But I'm an Android novice and need some outside input. Thanks for reading.
There is nothing wrong with that, especially for a game. The only problem is that you will have to do everything yourself. Most games seem to be doing this.
Due to the ease from which one activity can start another, I would say it is worthwhile to abstract your options and level selection from the game itself. If you're unfamiliar with starting activities and/or passing information between activities, there are plently of good tutorials and examples to help. You could try the ubiquitous Notepad tutorial if you haven't already ( http://developer.android.com/resources/tutorials/notepad/index.html ).
The advantages of this method would be to leave your OpenGL/game Activity less cluttered, and that you would be able to use tried-and-true Android UI elements instead of building your own from scratch.