I've been fiddling around with RenderBlur on an image for my login screen, i've gotten everything to work with a runnable() and a delay to blur the image immediately, however i'm trying to make it a slow blur while the username and password fields come into view.
I've had a bit of a look around (could be looking in the wrong places) but I haven't found anything related to what i'm after. I've attempted to use a while loop and have a blurradius value increment with a delay afterwards and send to the blurBitmap class method, but it either still blurs it immediately (meaning I probably messed something up somewhere and will most likely keep trying with this method until a better solution is found).. or it crashes.
Does anyone know if, in the first place this is possible with RenderScript? And if so, what should I be searching for.
Thanks for any help you can provide.
Resources: https://futurestud.io/blog/how-to-use-the-renderscript-support-library-with-gradle-based-android-projects
You can do this with RenderScript, though how you are doing it now doesn't sound like a good idea. Look into using a custom Animator which you can then run a RS blur against the image. Using Animator will be more flexible in the long run and automatically ties in with the view system rather than requiring you to handle View or Activity state explicitly.
The approach #JasonWihardja outlined will also work, but again I would suggest doing this in an Animator or similar mechanism.
Blurring an image repeatedly might cause some performance issues with your app.
Here's what you could do:
Arrange 2 images (1 for the clear image and the other for the
maximum blur version) so that the blur image is placed exactly on
top of the clear image. The easiest way would be placing 2 ImageViews in a FrameLayout
To achieve the "slow" blur effect, initially set the blur image's alpha to 0.
Then, using one of the view, issue a postDelayed event to slowly increase the blur image's alpha to 255.
Related
I'm tackling the task of an overlaying drawable over a view that animates the drawing of a checkmark as in the following video https://vid.me/MsQj
I don't have a preferred method for doing this but it's just not coming out the way I wanted it to, I tried:
Two views, each with on side of the checkmark to be revealed with an animation, however I'm stuck at the "revealed with an animation" since I can't use the circular reveal on -21
Frame by frame animation, this is the easiest but I'd hate to have 60 images for this stupid animation if it can be done programmatically
Drawing on a custom view canvas
My question would be, is there anything that can make this easier on me, or do I have to tackle it head first and just get on with it
You could create a custom View class which contains two lines defined by ShapeDrawables, one for each leg of the tick. Expose the lengths of these two lines as properties of the class, and then use Property Animation to animate the lengths of the lines.
Property Animation is flexible enough to handle pretty complex timing and sequencing of various properties. In this particular case you would probably want to use an AnimatorSet to sequence the two line animations so the second starts once the first has finished.
I ended up developing a custom View thanks to #SoundConception suggestion and finding out about ObjectAnimator which are very powerful in Android. In essence what goes on is we set a width for the first and second line that make the checkmark and using the animator change the value of those properties from 0 to the desired one.
On the setter for the property, we invalidate the View to redraw it with the new value and with a little tweaking I made a nice View that while its currently only working for my specific layout (ie it needs some more work on the offset calculation) it's able to draw an animated checkmark with some stuff that is customizable.
Precisely, you can set the line width, the color, the length and the animation time. And touching the java file, you can change the interpolator and all the rest of the stuff.
Hopefully the code, while not really commented serves as a basis for someone trying something similar.
For example the following code would generate something like this video, although not really because I was testing opacity and thinner lines, but you get my drift.
<coop.devtopia.CheckmarkView
android:layout_width="250dp"
android:layout_height="250dp"
android:layout_centerInParent="true"
android:id="#+id/view"
app:first_leg_length="50"
app:second_leg_length="100"
app:total_duration="1500"
app:stroke_width="20"
app:stroke_color="#22000000"/>
Repository
Update 4/2/15
I've played with this a little further and added dynamic offset calculation (fancy way of saying centering) to the tick, meaning we can generate big checkmarks, small checkmarks, skinny or thick, reversed or straight and they will be centered in the view. Can't guarantee the same for checkmarks bigger than the container, they will likely be cropped.
Here are a few of the checkmarks generated for this demonstration, of course the animate as if drawn and the effect can be very pleasing and resource friendly. This turn out to be a pretty interesting subject after all.
What is the best way to set background for some view? For example 2 variants of backround:
background with gradient, rounded corners and border
background with just one color and rounded corners
So which of variants would be better, nine-patch or drawable xml resource?
My guess is, NinePatch would be slightly faster in most cases. Here's what I found.
GradientDrawable (the one used for rects in xml) uses this code to call through to Canvas which in turn uses native call leading to SkCanvas, SkDraw and eventually SkScan and SkBlitter.
On the other hand, NinePatch's draw() has almost zero Java code before the native call to NinePatch.cpp which shortly calls NinePatchImpl.cpp -- NinePatch_draw() --- and that's where the magic is. The code there iterates over the marked regions and after a number of subsequent calls draws stuff using roughly the same logic in SkDraw (only drawRect() instead of drawPath()) but in the end it's the same SkScan and SkBlitter that do the work.
All that code is pretty hard to wrap my head around instantly, but what did catch my eye is that GradientDrawable makes two calls to the whole native stack if it has both background and stroke (look here), while in any scenario a NinePatch only makes one.
So, without actually measuring times for both approaches I get a feeling in most cases NinePatch wins the race: if we [awfully] roughly assume that native call stacks for drawRect() and drawPath() use pretty much the same logic and [another awful simplification] the parameter sets that get passed around there and are created by NinePatch and GradientDrawable don't affect complexity of the methods that much, then NinePatch turns out to be roughly 2 times faster than GradientDrawable with filling and outline. Well, provided you use a regular, 9-section 9-Patch (i.e. don't shred you 9-Patch by an awful lot of markers, making the iteration over the pieces overly effort-expensive).
Anyone who'll stumble upon this and knows more on the subject (and/or better at estimating complexity of native code), please, correct me if I'm wrong.
PS yeah, I know this is not much of a straight answer
Without going into too much detail, I want to be able to 'slide' elements in a ListView similar to the 'slide to archive' feature in GMail. I'm fine with the onTouchListener and all that, my question is regarding the slide animation.
The first two things that come to mind are..
view.setPadding(slideOffset, 0, 0, 0);
and..
view.setX(slideOffset);
The former is very buttery, even on the emulator.
The latter is a bit janky on my Galaxy Nexus.
My questions:
* Regardless of what I've tried, what's the correct way to do this?
Why is setX less smooth than setPadding?
Does one approach conform to Android best practices more than the other?
Are tweened translation animations an option? If so, can you provide a brief example to point me in the right direction please?
Edit:
To be clear, I am attaching an image of the effect I am trying to emulate.
I'm pretty sure the setX() is slower because it affects its parents. When changing the X of a view, it calls the onLayout/onMeasure of the parent every time you update the value. That's because the X value of the child may cause other items on the parent to move, therefor the parent needs to redraw itself.
You can test this easily by extending the ViewGroup and writing to the log on those methods. Then, you can use both approaches, padding vs. setX, and see what happens.
Are you trying to animate the item? Or do you want the user to move it like on Gmail? You can use the ObjectAnimator to handle the "X" value of your item. Combined with a "hardware layer" for your item, it will create a smoother experience. You can find more details about how to do that here: http://developer.android.com/guide/topics/graphics/hardware-accel.html
Yeah, if you're targeting higher APIs, ViewPropertyAnimator is probably a great solution. If you have to support lower APIs, my thought process for implementation would be (and I haven't implemented this myself personally, but this should be good for performance) to:
In your touch handler, once you've determined that the user is "sliding", set the View's visibility to INVISIBLE, and store the drawing cache into a separate bitmap (Bitmap bmp = myView.getDrawingCache();)
Draw that bitmap in the same place as the view, and use the Canvas translate methods to shift the position according to the x-position of the user's touch point.
After the user lets go, translate back (preferably smoothly with an animation), recycle the bitmap, and set the view back to VISIBLE.
Check out the 3 devBytes posted on AndroidDev:
https://www.youtube.com/watch?v=8MIfSxgsHIs&list=PLWz5rJ2EKKc_XOgcRukSoKKjewFJZrKV0&index=12
https://www.youtube.com/watch?v=NewCSg2JKLk&list=PLWz5rJ2EKKc_XOgcRukSoKKjewFJZrKV0&index=11
https://www.youtube.com/watch?v=NewCSg2JKLk&list=PLWz5rJ2EKKc_XOgcRukSoKKjewFJZrKV0&index=11
https://www.youtube.com/watch?v=YCHNAi9kJI4&list=PLWz5rJ2EKKc_XOgcRukSoKKjewFJZrKV0&index=4
https://www.youtube.com/watch?v=PeuVuoa13S8&list=PLWz5rJ2EKKc_XOgcRukSoKKjewFJZrKV0&index=3
Basically, I am making a rectangle that represents charge on your weapon. I want a green rectangle to advance over a red one after a certain amount of time. My issue is the timing. I have no clue how to do any timing anything in android.I'm fairly new so don't use too many things I might not understand. All of this is within a view. I researched threading and handlers, but just got confused.
Check out View Animations if you want to support pre 3.0 without using a library. OR Property Animations if targetting 3.0+ is ok.
I have more experience with the View Animations and I can tell you that the Scale animation is the one you'd be looking for. Make your X scale to 100% its size perhaps would get the job done.
I need to make a slider index like this:
(In this case it's indicating that the current index is 3).
Since it doesn't seem to be a finished solution, I have to make a custom one.
2 Possibilites come to my mind:
Create a custom component and draw/update the circles using onDraw. Only "geometric" drawing. But it has limitation in effects. Maybe I want a shiny circle or something, then that will not work. On the other size resize is easy.
Use bitmaps. But I don't know if this is maybe expensive... (If I have 30 or more). And from some count I have to scale down, and this could not look good anymore.
Or maybe something else?
Can anyone advice me what's the way to go to do this...
Thanks.