I'm starting to learn Java and i came across an excersize where i need to fade away one image and display by fading in another image.
My solution to this excersize is to have one imageView and fading out the first image, then switching the image source to the second image and fading the imageView in so it should display the new image. Doing that so it will display all the images i want by fading out then in with a new image.
this is my code for the program:
public void fade(View view){
ImageView simpsonImageView = findViewById(R.id.simpsonsImageView);
simpsonImageView.animate().alpha(0f).setDuration(3000);
simpsonImageView.setImageResource(R.drawable.bart);
simpsonImageView.animate().alpha(1f).setDuration(3000);
simpsonImageView.animate().alpha(0f).setDuration(3000);
simpsonImageView.setImageResource(R.drawable.lisa);
simpsonImageView.animate().alpha(1f).setDuration(3000);
}
Now i have seen in the tutorial i'm learning from that the tutor used different imageView for each image. I wanted to know which solution is correct or at least acceptable amoung these two. Or it dosent really matter and that both solutions are fine.
There is one thing which you can only achieve when using two ImageViews: you can crossfade the two images so that the screen is never entirely empty.
In the context of your exercise however, you only want to exchange images sequentially.
From a performance point of view, one ImageView may be better than two because it will obviously take less memory and CPU time but I doubt that this will have a noticeable impact on modern devices.
So as long as you don't animate lots of pictures simultaneously (think of football teams instead of the Simpsons), both solutions are fine.
Please note that with your code as-is there will be no animation visible at all and the ImageView will appear to only show the second picture. This is because animate() triggers an animation but it does not wait until the animation is finished. So you need to work with an AnimationListener or use Handler.postDelayed() to swap pictures and start the next animation only as soon as the previous one is finished.
Related
I'm developing and Android application, but I have some doubts about the
feasibility of my project.
I have to implement a custom layout composed from a ImageView that show an image, in particular a VectorDrawable.
Overlapping the ImageView there is a SurfaceView that :
Capture every coordinates of the touches;
Draw a Bitmap (in a certain position) everytime I touch the screen.
The purpose is to show a background image and use it as a reference, each time the user touches the screen a marker on SurfaceView must be inserted, this technique allows to simulate the insertion of a marker on an image.
The question is:
There are other better method to do this?
I have implemented yet, the idea works, but I have some limitation about the SurfaView (for example I can't insert it in a ScrollView).
And at last:
Taking into consideration the reasoning made up to now, assuming to have a ImageView that show a VectorDrawable, is it possible create a function that magnify and lessen the image (VectorDrawable)?
p.s. I apologize for having put two questions but the whole is closely related, I thought it was foolish to open two threads
Task 1: Your task is doable using a SurfaceView but I'm assuming that after you draw your image you would want it to stay if that is the case you may have to keep track of each image separately. If your task is just drawing an image you can also override a View which can do the same task but will also provide transparency and basic layout implementations. Difference between View and SurfaceView is performance, SurfaceView is pretty low level with a double buffer and gives you more control. Also if the number of images are small you can override a FrameLayout and spawn ImageView. Its not very efficient but it will be easier to implement.
Task 2: You can scale an ImageView easily by using setScaleX and setScaleY. But this may pixelate the image. Loading a large Bitmap then drawing it on a custom view would be a better way.
EDIT:
After doing a method trace, whenever I switch with the purple square, the graph rises a lot. When I switch with a blue or green circle, it stays low:
Here are the methods of the swap with the purple square:
I have an app which swaps two buttons. There is one red button, when it gets clicked, it picks a random button from the other three, and swaps.
I tried doing this one way by just swapping images. In the onClickListener, I only listened for clicks with buttons with the red button.
Get random image
Make it blank
Look for red button
Give red button background that random image had (swap)
Give random image (which is blank now) red background
If this is confusing...leave it. But:
Whenever I switch images from a larger image to a smaller image, the process takes a much longer time. It is much faster when swapping between two smaller images. How do I fix this. Is there a certain image size which is optimal for android?
Here is the layout code:
https://gist.github.com/anonymous/813883bce89606d2a82e
As you can see in the image, it takes a much (MUCH!) shorter time swapping background images with the blue circle than the purple square. Why...?
Why is the way (where I just change the images and check for a button with a red image) slower based on the image sizes? What image size should I use?
Thanks so much for your time
My first guess would be that you have some big PNGs that take a long time to load.
But, we have nice tools to help us actually find out -- so we don't have to guess!
Do a method trace (available in the CPU tab in Android Studio, or the DDMS view in Eclipse+ADT) while doing the switch, and you should see what is taking time.
I dont have the exact answer for your question but just 2 recommendations:
1) Make sure you scale the image first before drawing.
2) Using RelativeLayout causes your ViewGroup to measure your children twice instead of one. So Make sure that you dont do any that trigger re-layout on click events
3) I would suggest that you put these View in a GridView or GridLayout and then when you need to swap your views, just swap the positions of your view in an data (Array, for example), and call notifyDataSetChanged();
Hope this help
Apparently, the image size can affect the speed. So, what I did was re size my image. I did this in photo shop, but you can do it in paint or you can do it in an image-re sizer website. Just search that up in google, and enter the dimentions 56 x 56. For some reason, those dimensions work best.
Here is one image resizer tool:
http://www.picresize.com/
On this website, just select your image from your computer, and then the next screen will say to resize it:
To do it in paint:
Although the bounty is over, I have just posted this to help people know how to do it. I STILL DON"T KNOW WHY THE IMAGE SIZE MATTERS I would really appreciate it if someone explained why I must fix the image size, although I know how.
Thanks,
NullPointerException
I'm developing an app that displays a step-by-step process for my company. Each step consist of one image and each activity shows eight to twelve images. I'm now running into the java.lang.outofmemory. It's also listing an android.view.InflateException:Binary xml error. I've resized the images to 360dpi and that only allowed a few more pics before reaching the error again. I also tried increasing the heap size, which did not change the result. Is there another way I should do this? Thanks a lot.
You can scale down the Image, thus reducing their memory footprint. Also, you could look into certain libraries like picasso and UIL and see if they can help you.
No magic here, i guess the imageview are rendering in full argb mode, so 8 bit * 4 * number of pixels. That's a lot!
How does your activity displays images ?
If they are in a list, make sure to use recycling.
http://developer.android.com/training/improving-layouts/smooth-scrolling.html
You are interested in the ViewHolder
If you are using a ViewPager and swipes left/right, make sure to destroy your fragments while you are swiping, so that you can have in memory only 3 images (1 displayed, and 2 next to it).
If it's none of those, maybe you will have to refactor your layout :(
Last but not least, make sure to resize your bitmap to your exact screen size, as suggested before, Picasso provides a convenient mean to do it with .fit(). It will wait for the imageview to be measured, then resize the downloaded bitmap and fit it in the imageview. You don't even have to worry about networking on main thread, how wonderful !
Picasso.with(getActivity())
.load(imageUrl)
.fit()
.into(imageView);
This is where coding approach matters. How you've implemented it might help us pin point the memory leaks.
But a general practice ( maybe not good one)
Load all Bitmaps in a constant class. ( just once)
Refer infinitely.
So, I'm trying to make the background to one of my apps look "futuristic." I thought of an idea to make the screen look almost transparent yet have views over it. So, it would look something like this:
(source: rackspacecloud.com)
I'm thinking that I can use the camera to capture the background of the phone (without taking a picture, just having the real time view in the background) and then, if possible, place a semi-transparent slightly blurred ImageView over that. Finally, on top of that I can place the other views including the ImageButtons.
So, my question is how would I go about doing this? I have searched but haven't found anything relevant. It must be possible; its just how to do it? I don't expect you to give me all the code as an answer, just if you have any ideas that can help or links or code that can point me in the right direction, it would be greatly appreciated! Thanks!
It shouldn't be too hard to get started. There are samples located here that show you how to open the camera and draw the preview onto a SurfaceView. Since you want to overlay your other Views on top of the camera preview, just make sure that the SurfaceView that you are using for the camera preview is contained inside a FrameLayout (docs located here). The FrameLayout lets you insert child views and they are z-indexed using the order they are inserted. Therefore, if you insert your SurfaceView and then insert a Button of some kind it will be z-ordered in front of the SurfaceView and you can set its alpha value so that it can be more or less transparent. All that said, you will have to do some trial and error for how you want to position your views that are being rendered in front of the camera preview because a FrameLayout used on different screen sizes might position the Views differently. Also, I'd stay away from layering too many Views on top of one another because the compositor will have to figure out how to render all of it into a single window which could impact performance.
This is my first post and i have (i think) a uncommon request...
I'm programming on the last Eclipse Mac, for every android SDK, and i'm using more XML for layout than runtime... So i search a solution in XML if possible.
Here is the situation: i work with an image background wich simulate item like buttons, image, text... etc. On this image, i put buttons, image, and text (buttonview textview etc...) and place it precisely on their places on the image. This solution is very powerful to have good design BUT, if i change the resolution of the screen, and/or its size, each item won't be at its place, and will be translated (horiz and/or vertic) for some "dp"... (and yes i use dp, not mm or px or whatever)
I'm really embarrased because i think thanks to "dp" it keep proportionnality but.. not !
My question is how can i fix my items at their places on the image background, for different screen size/resolution !!
Thanks in advance everyone,
My Best From Lyon,France
First realise that if you want to make it pixel perfect for all screen sizes your out of luck.
Second accept that you can't make it perfect for all screen sizes.
Third you can get far with creating different layout for different screen sizes. You can read a lot about supporting multiple screen sizes here. One important thing to take from here is that you can make layout for the different screen sizes or different density sizes.