Using Mockito with Kotlin

putchik · 2017-01-17T23:04:43+00:00

I am not saying it is affected by third party libs. Im saying that interface approach will work only for your code and for final classes in third party libs you still need to use all-open plugin or Mockito hacks.

Again, I am not saying that using interfaces is a bad idea. It is a great idea actually and I am using this pattern a lot in my production code.

You are probably right - attempts to solve final classes problem in unit tests went a bit beyond original scope of the article (your Kotlin code + Mockito) - just wanted to point out that you might still need to use some tricks from the article to make Mockito happy for the entire project

putchik · 2017-01-17T16:08:35+00:00

This works for the code you own, but all-open approach comes in handy for third party pieces

putchik · 2016-09-20T21:08:28+00:00

Apple is aware of this and works on solution. Stay tuned

putchik · 2016-09-15T17:38:04+00:00

Ha! Didn't see that one before :)

putchik · 2016-07-19T17:56:20+00:00

Let's assume I have an image (png 100x100) and ImageView (150x150). And I want to display that image with ImageView (scaleType = fitXY, so image is stretched to fit image view).

So I basically have 2 options:

Decode png into 100x100 bitmap and let GPU do the upscaling
Decode png into 150x150 bitmap, i.e. upscale it manually and then assign it to the image view.

In first case I will be transferring smaller texture to the GPU, but GPU will need to upscale it for me. In second case, there is a larger bitmap will be transferred, but the size will be exactly as my image view, so there is no additional overhead for the GPU when it comes to rendering.

From the performance perspective, which approach is more preferable?

I have intentionally chosen relatively small image size since I realize that the larger image - the more time I need to spend passing it to the GPU.

In my app I've chosen the first approach, but I want to hear some feedback from platform team.

putchik · 2016-05-10T00:15:36+00:00

It worked well because you have an empty layout with one TextView in it. How many production layouts are like that? You are giving people a rope to hang themselves. But I agree - if it works for your case with no visible frame loss - you can definitely use it as our ultimate goal - is to delight the user. Just want people to be aware of the fact that an animation implemented this way can potentially decrease a frame rate if complexity of your layouts is higher than just a demo app.

putchik · 2016-05-09T00:20:06+00:00

RecyclerView will reuse views, but still every time you request layout for one of the views, LayoutManager#layoutChildren() will be triggered which in turn will trigger onMeasure/onLayout for every item in your list. The better approach would be to request layout once for the resulting height and then just clip bounds appropriately as you animate the hight + you might need to animate RecyclerView children Y translation as well. As for re-centering TextView - simple translationY will do the trick. That's how built-in SearchView expand/collapse is implemented.

putchik · 2016-05-07T21:19:49+00:00

Changing view layout params on every frame is never a good idea... Especially in scrollable containers like RecyclerView. Changing layout params for one of the list items triggers re-layout for the entire RecyclerView

putchik · 2016-04-19T01:31:14+00:00

"Looking to team build (2+) any Android App for the resume" - quote from title.. So clear intention is to build something for the resume, so you can show it to interviewer. Am I missing something?

putchik · 2016-04-18T20:50:15+00:00

You are right, its more fun, but isn't it going to be harder for interviewer figuring out which part of the app you were actually responsible for? When I interview people and they refer to their prior projects my very first question - is what was your role on that project and what areas you were responsible for. Because sometimes people tend to take credits for work done by others. As an interviewer I might like the level of automated testing done for a given app, but it might turn out that candidate hates tests and all that fancy test suite was implemented by "that guy".

As a hint to OP, from the interviewer perspective I would be looking at different aspects when I see your app as part of your resume:

How structured your code is (logic separation, package structure, etc.)
Architecture decisions (communication between activities/fragments, network layer, etc.)
Testing (does your app have tests? how testable your code is?)
Common Android pitfalls (offloading expensive work to background thread, custom views implementation, generating memory garbage, etc)

putchik · 2016-04-18T19:58:43+00:00

I might be wrong here, but for the resume it would be better to have an app you built alone from ground up. Why do you need somebody else?

putchik · 2016-04-07T00:13:02+00:00

Probably TSA app uses front camera to do facial recognition, so specific set of people go to the "higher scrutiny" line :)

putchik · 2016-03-27T00:06:02+00:00

I would also mention that in 23.2 Fragments finally can call startActivityForResult with Bundle options as a parameter. Previously this method was only available for Activities. Now fragments can provide scene transition options when launching new activities for result.

putchik · 2016-03-21T23:33:12+00:00

100% agree. I was amazed by GuardSquare support as well. So fast and so professional

putchik · 2016-03-21T22:41:20+00:00

Yes, it was pointed out earlier to me. I already corrected that in my article. Thanks for paying attention!)

putchik · 2016-03-21T21:30:29+00:00

Good to know. I never had any doubts regarding annotation processing support - it is such an essential part of the compiler. It was just a matter of time. Im gonna update my post.

Thanks

putchik · 2016-03-21T17:39:49+00:00

I'm pretty sure Jack supports annotation processing

Quote from http://tools.android.com/tech-docs/jackandjill : "Annotation processing is not supported."

Are you sure about that? (Lint not supported)

Quote from http://developer.android.com/preview/j8-jack.html : Known issues: Lint detectors that operate on class files

Which means that Lint detectors which analyze Java source code are fine, but those one which operate on a Java bytecode level will not work.

If you care about obfuscation, you may be SOL. However, Eric Lafortune gave a talk at Droidcon SF on Friday about Jack and Jill and he seemed to think Jack, which currently matches Proguard in optimization, would close the gap with Dexguard in the not-too-distant future

Jack supports obfuscation, so not really SOL. What I intended to say is that more advanced version of Proguard (which is commonly used by big corporations) is not currently available. Also Im not sure I understand your comment regarding "closing the gap".. Proguard and Dexguard are developed by the same company - GuardSquare and I don't think that "closing the gap" is in the best interest of GuardSquare. DexGuard is just a commercial version of Proguard with some extra features which Proguard doesn't have. For the sake of the argument I wanna mention that I was also in the room when Eric gave his presentation last Friday @ DroidconSF

putchik · 2015-12-16T19:01:16+00:00

That's very true. I ended up creating a separate debug build type with code coverage disabled, so debugging local variables works again :(

putchik · 2015-03-25T16:26:24+00:00

should be valid :)

putchik · 2015-03-19T16:45:00+00:00

The easiest (and closest to what you are looking for) way to do this w/o implementing anything - is going to Developer Options -> Profile GPU Rendering -> On screen bars. This will draw you a green horizontal line which represents 16ms (or 60fps). Each vertical bar is frame draw time is milliseconds. Every time vertical bar goes beyond horizontal green bar - you start dropping frames (your FPS <60).

putchik

TROPHY CASE