public List<Person> getFilteredUsers(List<Person> personsToFilter) {  
    List<Person> result = new ArrayList<>();
    for(person : personsToFilter) {
        if(person.getAge() >= 15 && person.getJobTitle().equals("Developer")) {
            result.add(person);
        }
    }
    return result;
}

When migrating to Kotlin, it's understandable then that this "java-flavoured" idiom would stick for developers picking up Kotlin's syntax:

fun getFilteredUsers(personsToFilter: List<Person>): List<Person> {  
    val result = mutableListOf<Person>()
    for(person in personsToFilter) {
       if(person.age >= 15 && person.jobTitle == "Developer") {
           result += person
       }
    }
    return result
}

Java-flavoured Kotlin code is all too common, and reasonably so. It's part of adopting any new language to work in the style that you are most recently familiar with, and what you know comfortably.

A couple of guiding ideas can help to adopt a Kotlin style when moving from Java:

• Favor val over var
• Favor read-only over mutable

With these ideas in mind, you can ask the question: "can i drop the mutable list?". Fortunately, Kotlin has many niceties built into the language to help with exactly these sort of situations, without requiring adding mutable state:

fun getFilteredUsers(personsToFilter: List<Person>): List<Person> {  
    return personsToFilter.filter { it.age >= 15 && it.jobTitle == "Developer" }
}

Ah! Much better. The Kotlin filter operator accepts the left-hand collection, creating a new collection with any element that matches the condition you specify in the {}'s. Now you've accomplished the same work, without requiring declaring a temp. If you find yourself declaring a temp variable in Kotlin, chances are a function on iterable exists to handle exactly the problem you're facing.

Now, you might be thinking "yes, this is cool - but, what if this were a more complicated situation - like a map for example?" Fortunately Kotlin's collection api has many goodies baked in with these further complicated situations in mind. For example, what if getFilteredUsers should return a map of user's age associated with user instead? Let's see that in the Old Java style:

public Map<Integer, Person> getFilteredUsers(List<Person> personsToFilter) {  
    Map<Integer, Person> result = new HashMap<>();
    for (Person person : personsToFilter) {
        if(person.getAge() >= 15 && person.getJobTitle().equals("Developer")) {
            result.put(person.getAge(), person);
        }
    }
    return result;
}

Fortunately, Kotlin has you covered for these (and far more complicated) cases as well!

fun getFilteredUsers(personsToFilter: List<Person>): Map<Int, Person> {  
    return personsToFilter.filter { it.age >= 15 && it.jobTitle == "Developer" }
            .associateBy { it.age }
}

By the way, now that your statement is written as expression, you can flex an extra benefit of the Kotlin language and convert that function to a single-expression function:

fun getFilteredUsers(personsToFilter: List<Person>) =  
    personsToFilter.filter { it.age >= 15 && it.jobTitle == "Developer" }.associateBy { it.age }

Whenever you declare a temp variable in Kotlin, let it trigger the thought: can I use the collections API instead to solve this without a temp or mutable state? Chances are, the answer is "yes!"

class Qaz {  
    var bar = "hey"
}
class Foo(private var qaz: Qaz?) {  
    fun assignBarMkayyy() {
        if (qaz != null) {
            qaz.bar = "hey!"
        }
    }
}

• curl https://raw.githubusercontent.com/DefinitelyTyped/DefinitelyTyped/master/types/jquery/index.d.ts > jquery.d.ts
• install the typescript-to-kotlin converter: npm -g install ts2kt ( https://github.com/Kotlin/ts2kt )
• convert jquery.d.ts to jquery.kt by running ts2kt -d headers jquery.d.ts
• create a new kotlin project and target js for the runtime
• within the src directory in your project, create 2 packages: jslibs and jsheaders
• download jquery.js from https://jquery.com/download/ and place it in jslibs
• move the jquery.kt header file you generated (should be in the headers dir where you ran ts2kt) to jsheaders
• create a new html file within the Kotlin project. the project should have an index.html file at the top level that includes the following:

<!DOCTYPE html>  
<html lang="en">  
<head>  
    <meta charset="UTF-8">
    <title>kotlinjquerytest</title>
</head>  
<body>

<script type="text/javascript" src="out/production/{name of project}/lib/kotlin.jslibs"></script>  
<script type="text/javascript" src="out/production/{name_of_project}/jslibs/jquery-3.2.1.min.jslibs"></script>  
<script type="text/javascript" src="out/production/{name_of_project}/{name_of_project}.jslibs"></script>  
<div id="app" style="width:200px; height: 200px;border:1px solid red;"></div>  
</body>  
</html>  

make sure to change nameofproject to... the name of the project you chose

• create a kotlin file within source called Main.kt with the following:

fun jQuery(x: String) = jQuery(x, null as JQuery?)

fun main(args: Array<String>) {  
    jQuery {
        Main.doApp()
    }
}

object Main {  
    fun doApp() {
        val jQuery1 = jQuery("#app")
        jQuery1[0]?.innerHTML = "<p>hey!</p>"
    }
}

• double click the index.html file
• at the top right, select a browser icon to open the file
• congrats!

Download the example project at: http://github.com/mutexkid/kotlinjquerytest

abstract class Foobar {  
  abstract String foo();
}

Foobar = new Foobar() {  
    @Override
    String foo() {
      return "foo!";
    }
}

In Kotlin, the syntax proved a bit more tricky to track down - easily doable, just slightly elusive:

abstract class Foobar {  
    abstract fun foo(): String
}

class UsesFoo {  
    fun foo(foo:Foobar) {
        println(foo)
    }
}

fun main(args: Array<String>) {  
    UsesFoo().foo(object: Foobar() {
        override fun foo(): String {
            return "foo!"
        }
    })
}

Notice the "object:" portion of the above code?

title: Keeping Android Secrets Secure with Fingerprint Authentication and the Keystore

description: Getting cryptography right on Android is challenging. There are code examples without much explanation about what is really going on. In this talk you will learn the details you need to implement a subset of Android security: user authorization.
We will discuss how to implement robust user authorization using the new Fingerprint API and the Android Keystore,
and we will explore how to correctly use the Keystore to keep your application secrets secure.

Here are the slides from my DevNexus 2017 Presentation entitled "Keeping Android Secrets Secure with Fingerprint Authentication and the Keystore".

Github code here: android securebank example

For example, consider the following example:

class Socket  
class UrlScraper(val socket: Socket) {

    inner class ParseResult

    operator fun invoke(url: String): List<ParseResult> {
        //do cool stuff here with the url
        //eventually produces a list of ParseResult objects
        return listOf(ParseResult(), ParseResult())
    }
}

Once you specify the invoke operator, UrlScraper can perform it's work without any need for calling a method on it, since it does only one thing - scrapes a url! You can now simply pass the url to the instance like so:

fun main(args: Array<String>) {  
    val urlScraper = UrlScraper(Socket())
    urlScraper("www.google.com") //calls the invoke method you specified
}

I really like this trick, especially for classes that have just one public method - a perform method, for example - since it further simplifies how the API can be used.

RadioAdapter.java

public abstract class RadioAdapter<T> extends RecyclerView.Adapter<RadioAdapter.ViewHolder> {  
    public int mSelectedItem = -1;
    public List<T> mItems;
    private Context mContext;

    public RadioAdapter(Context context, List<T> items) {
        mContext = context;
        mItems = items;
    }

    @Override
    public void onBindViewHolder(RadioAdapter.ViewHolder viewHolder, final int i) {
        viewHolder.mRadio.setChecked(i == mSelectedItem);
    }

    @Override
    public int getItemCount() {
        return mItems.size();
    }

    @Override
    public ViewHolder onCreateViewHolder(ViewGroup viewGroup, int i) {
        LayoutInflater inflater = LayoutInflater.from(mContext);
        final View view = inflater.inflate(R.layout.view_item, viewGroup, false);
        return new ViewHolder(view);
    }

    class ViewHolder extends RecyclerView.ViewHolder {

        public RadioButton mRadio;
        public TextView mText;

        public ViewHolder(final View inflate) {
            super(inflate);
            mText = (TextView) inflate.findViewById(R.id.text);
            mRadio = (RadioButton) inflate.findViewById(R.id.radio);
            View.OnClickListener clickListener = new View.OnClickListener() {
                @Override
                public void onClick(View v) {
                    mSelectedItem = getAdapterPosition();
                    notifyDataSetChanged();
                }
            };
            itemView.setOnClickListener(clickListener);
            mRadio.setOnClickListener(clickListener);
        }
    }
}

A generic view for displaying a radiobutton and title:
view_item.xml

<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"  
              android:layout_width="match_parent"
              android:layout_height="match_parent"
              android:orientation="horizontal">

    <RadioButton
        android:id="@+id/radio"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        />

    <TextView
        android:id="@+id/text"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        />
</LinearLayout>  

To actually use this abstract class, subclass it and construct with your specific data. Also, implement onBindViewHolder to do the specific data set up for your backing model:

PersonAdapter.java

public class PersonAdapter extends RadioAdapter<Person> {  
    public PersonAdapter(Context context, List<Person> items){
        super(context, items);        
    }

    @Override
    public void onBindViewHolder(ViewHolder viewHolder, int i) {
        super.onBindViewHolder(viewHolder, i);
        viewHolder.mText.setText(mItems.get(i).mLocationName);
    }    
}

Just for sake of demonstration, the Person object in all its glory:
Person.java

class Person{  
    public String mName;
    public Person(String name){
        mName = name;
    }
}

Finally, let's set it up!
MainActivity.java

@Override
public View onCreate(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) {  
    setContentView(R.layout.activity_main);
    RecyclerView recyclerView = (RecyclerView)findViewById(R.id.recycler_view);
    List<Person> persons = Arrays.asList(new Person("Larry"), 
                  new Person("Moe"), 
                  new Person("Curly"));
    //basic yak shaving required
    recyclerView.setLayoutManager(new LinearLayoutManager(this));    
    recyclerView.setAdapter(new PersonAdapter(this, persons));
}

Here's what it looks like:

Download the source here at github

Update

For the Kotlin fans, i've added an updated version of the code example here:
https://github.com/mutexkid/kotlin-radio-group-example .

Test

Here's what it looks like:

The Swipe to Refresh pattern is a nice fit for adapter-backed views (RecyclerView and ListView, for example) that also need to support user-requested refreshes, like a list that displays a Twitter newsfeed that’s updated by a user, on demand.

Introduced alongside KitKat and enhanced with the Lollipop release of the v4 Android support library, a working implementation of the Swipe-to-refresh UI pattern is included, called SwipeRefreshLayout . All we have to do is set it up! For your reference, the project we'll build is available for download on github here.

Setting up Swipe To Refresh

We begin implementing the Swipe-to-Refresh pattern with a brand new Android Studio project and the most recent version of the Android Support Library (your SDK manager should show an Android Support Library version of at least 21.0).

The first thing we need to do is add the support library to our application’s build.gradle file.

compile 'com.android.support:support-v4:21.0.+'  

Gradle sync your project and open the layout file that was generated when we created our first Activity from the new project wizard, named res/layouts/activity_main.xml. We're going to add a ListView and a SwipeRefreshLayout widget to the layout file. The ListView will display content we want to update using the Swipe to Refresh pattern, and the SwipeRefreshLayout widget will provide the basic functionality.

 <android.support.v4.widget.SwipeRefreshLayout
        android:id="@+id/activity_main_swipe_refresh_layout"
        android:layout_width="match_parent"
        android:layout_height="wrap_content">

        <ListView
            android:id="@+id/activity_main_listview"
            android:layout_width="match_parent"
            android:layout_height="match_parent"
            >
        </ListView>

    </android.support.v4.widget.SwipeRefreshLayout>

Notice that ListView is nested within the SwipeRefreshLayout. Any time we swipe the ListView beyond the edge of the SwipeRefreshLayout, the SwipeRefreshLayout widget will display a loading icon and trigger an onRefresh event. This event is a hook for adding our own on-demand data refresh behavior for the list.

Wiring up the Adapter

Now that we've got our layout file ready, let's set up a simple data adapter. In real life, our adapter would likely be backed by a web service, remote API or database, but to keep things simple we’ll fake a web API response. Include the following xml snippet in your res/strings.xml file:

<string-array name="cat_names">  
    <item>George</item>
    <item>Zubin</item>
    <item>Carlos</item>
    <item>Frank</item>
    <item>Charles</item>
    <item>Simon</item>
    <item>Fezra</item>
    <item>Henry</item>
    <item>Schuster</item>
</string-array>  

and set up an adapter to fake out new responses from the “cat names web API ” for our experiment.

class MainActivity extends Activity {

  ListView mListView;
  SwipeRefreshLayout mSwipeRefreshLayout;
  Adapter mAdapter;

  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    setContentView(R.layout.acivity_main);
    SwipeRefreshLayout mSwipeRefreshLayout = (SwipeRefreshLayout) findViewById(R.id.activity_main_swipe_refresh_layout);
    mListView = findViewById(R.id.activity_main_list_view);
 mListView.setAdapter(new ArrayAdapter<String>(){
    String[] fakeTweets = getResources().getStringArray(R.array.fake_tweets);
    mAdapter = new ArrayAdapter<String>(this, android.R.layout.simple_list_item_1, fakeTweets)
    listView.setAdapter(mAdapter);
  });
  }
}

Defining our Data Refresh

Now that our adapter is set up, we can wire up the refresh triggered by swiping down. We'll get an animated loading indicator already "for free"; we just need to define what happens to our ListView. We will do that by defining the SwipeRefreshLayout widget's expected OnRefreshListener interface. We'll also simulate getting new data back from the CatNames webservice (we'll build a method called getNewCatNames() that will build an array of randomly shuffled fake responses from the cat names API).

@Override
  public void onCreate(Bundle savedInstanceState) {
  …
    listView.setAdapter();
    mSwipeRefreshLayout.setOnRefreshListener(new SwipeRefreshLayout.OnRefreshListener() {
      @Override
      public void onRefresh() {
            refreshContent();
          ...
  }

  // fake a network operation's delayed response 
  // this is just for demonstration, not real code!
  private void refreshContent(){ 
    new Handler().postDelayed(new Runnable() {
          @Override
          public void run() {
    mAdapter = new ArrayAdapter<String>(MainActivity.this, android.R.layout.simple_list_item_1, getNewTweets());
    mListView.setAdapter(mAdapter);
    mSwipeRefreshLayout.setRefreshing(false);
    });
  }

  // get new cat names. 
  // Normally this would be a call to a webservice using async task,
  // or a database operation

 private List<String> getNewCatNames() {
        List<String> newCatNames = new ArrayList<String>();
        for (int i = 0; i < mCatNames.size(); i++) {
            int randomCatNameIndex = new Random().nextInt(mCatNames.size() - 1);
            newCatNames.add(mCatNames.get(randomCatNameIndex));
        }
        return newCatNames;
    }

Notice the last line in refreshContent() in the previous listing: setRefreshing(false); This notifies the SwipeRefreshLayout widget instance that the work we wanted to do in onRefresh completed, and to stop displaying the loader animation.

Now, try running your app. Try swiping the ListView down and verify that the SwipeRefreshLayout loading icon displays, is dismissed, and that new tweets are loaded into the ListView. Congratulations, you've implemented the Swipe-to-Refresh pattern in your app!

Customization

You can also customize SwipeRefreshLayout’s appearance. To define your own custom color scheme to use with SwipeRefreshLayout's animated loading icon, use the appropriately named setColorSchemeResources() method. This takes a varargs of color resource ids.

First, define colors you want to appear in the SwipeRefreshLayout's animated loader:

<resources>  
    <color name="orange">#FF9900</color>
    <color name="green">#009900</color>
    <color name="blue">#000099</color>
</resources>  

Then call setColorSchemeResources(R.color.orange, R.color.green, R.color.blue); in the onCreate portion of your activity, after the SwipeRefreshLayout is loaded.
Deploy your program and notice the customized colors the swipe animation now uses:

SwipeRefreshLayout will rotate through the colors we provided as the loader continues to be displayed.

As you can see from this simple example, Swipe-to-Refresh is a great pattern for simplifying the problem of user-requested data updates in your app. For more info about available API options for SwipeRefreshLayout, check out the official Android documentation page.

First, why not test against the live services themselves? After all, doesn't this ensure nothing broke on the server-side we're dependent upon? While this is certainly true - and it may be that we have a test group of integration tests which do hit the live REST API, we don't want this to be part of our main test suite. A few reasons we will want to "mock" (if you're puzzled by what i mean by "mock" check out http://en.wikipedia.org/wiki/Mock_object) these interactions instead:

• We may have a certain number of requests we're limited to for the api we're using. Every time our tests run, it will weigh against that limit.
• Tests that have to hit the remote network to pass or fail will invariably slow our suite down
• The service may be down temporarily. We don't want our test suite to fail because the server was rebooted!

Enter WireMock

An easy to use solution for avoiding live requests to actual REST services is to instead mock the responses from the server. I've found a library called called WireMock that easily facilitates this task. WireMock is designed to allow us to record requests to a webserver, and then programmatically play back those recordings when requests match a particular url pattern. We can define what urls we want WireMock to match in our tests like so:

stubFor(get(urlMatching("/api/.*"))  
        .willReturn(aResponse()
        .withStatus(200)
        .withBodyFile("atlanta-conditions.json")));

It lets us completely avoid building one-off test "Adapter"" objects for our service layer just to support the tests - in other words by using WireMock, we can use the live service classes, but get canned responses that don't hit a live webservice, with a minimum of glue code to support this test behavior!

Getting Started

With our new Android Studio project, we'll need to define our library dependencies in our project's gradle file. Here's the configuration i'm using - which relies on robolectric as a test runner setup for android. If you don't know how to go about setting this up in Android Studio, i have a boilerplate project for getting that setup right Here On Github

Gradle Setup

dependencies {  
    compile 'com.squareup.retrofit:retrofit:1.7.1'
    compile 'com.squareup:dagger:0.9.1'
    provided 'com.squareup:dagger-compiler:0.9.1'
    testCompile 'com.github.tomakehurst:wiremock:1.51:standalone'
    testCompile 'org.robolectric:robolectric:2.3'
    testCompile 'org.easytesting:fest:1.0.16'
    testCompile 'junit:junit:4.+'
    testCompile 'com.squareup:fest-android:1.0.8'
}

notice testCompile 'com.github.tomakehurst:wiremock:1.51:standalone' - i wasn't able to get wiremock to "play nice" (clashing dependencies) with robolectric without the standalone classifier, so make sure you include it in your gradle dependencies list, as you see above.

Our Service Layer

Let's imagine we've got Service Interface and Manager classes that makes a request to Weather Underground to give us the weather data for a particular city. The code example below uses Retrofit to define the webservice endpoints and interface, but if you don't know how retrofit works yet, don't worry too much about it - the focus here is the test setup itself.

WeatherServiceInterface.java:

public interface WeatherServiceInterface {  
    //defines the http method we want to use using retrofit's handy syntax
    //in this case, we want to 
    //hit api.wunderground.com/api/APIKEY/conditions/q/CA/Atlanta
    @GET("/conditions/q/CA/{location}.json")
    public ConditionsServiceResponse getConditions(@Path("location") String location);
}

WeatherServiceManager.java:

public class WeatherServiceManager {  
    private String mWeatherServiceEndpoint;
    private final WeatherServiceInterface mWeatherServiceInterface;

    public WeatherServiceManager(String weatherServiceEndpoint) {
        mWeatherServiceEndpoint = weatherServiceEndpoint;
        mWeatherServiceInterface = buildRestAdapter()
                .create(WeatherServiceInterface.class);
    }
    //uses the getConditions(String location) interface, with "Atlanta" for the location path attribute
    public List<WeatherCondition> getConditionsForAtlanta() {
        return mWeatherServiceInterface.getConditions("Atlanta")
                .getConditionsResponse()
                .getWeatherConditions();
    }
    //a retrofit rest adapter - read more about this at:
    //http://square.github.io/retrofit/javadoc/retrofit/RestAdapter.Builder.html
    private RestAdapter buildRestAdapter() {
        return new RestAdapter.Builder()
                .setEndpoint(mWeatherServiceEndpoint)
                .build();
    }
}

ConditionsServiceResponse.java

maps the json response from Weather Underground (using a library called GSON which Retrofit handily supports out of the box) that comes back from the server for that particular request - in this case the weather for Atlanta.

public class ConditionsResponse {  
        @SerializedName("results")
        public List<WeatherCondition> mWeatherConditions;
}

Finally, in use, here's what it looks like:

String serviceEndpoint = "http://api.wunderground.com/api/" + BuildConfig.WEATHERVIEW_API_KEY + "/";  
List<WeatherConditions> conditions = new WeatherServiceManager(serviceEndpoint).getConditionsForAtlanta();  

Writing the Test

Ok, now that we've explained the service and how it's put together we're ready to start explaining how the mocking for the webservice test is put together. Here's our test setup:

@RunWith(RobolectricTestRunner.class)
class WeatherServiceManagerTest{

    public WeatherServiceManager mWeatherServiceManager;

    @Rule
    public WireMockRule wireMockRule = new WireMockRule(1111);

     @Before
    public void setup() {
        String serviceEndpoint = "http://localhost:1111/api/" + BuildConfig.WEATHERVIEW_API_KEY + "/";
        mWeatherServiceManager = new WeatherServiceManager(serviceEndpoint);
    }    
}

A couple key things about this setup code. The first is our WireMockRule definition.
This will tell the WireMock library to spin up a server instance, which runs locally, on port 1111.
We also pass in a serviceEndpoint resolving to localhost instead of the live api endpoint.

Next, we'll add a test that asserts the number of results we expected would come back, actually came back.

@RunWith(RobolectricTestRunner.class)
class WeatherServiceManagerTest{  
    ...
    @Test
    public void testGetCurrentWeatherReturnsExpected() {
        stubFor(get(urlMatching("/api/.*"))
                    .atPriority(5)
                    .willReturn(aResponse()
                            .withStatus(200)
                            .withBodyFile("atlanta-conditions.json")));
            List<WeatherCondition> conditionsForAtlanta = mWeatherServiceManager.getConditionsForAtlanta();
            assertThat(conditionsForAtlanta.size()).isEqualTo(1);
        }
    ...
}

What this setup says is that any time i make a request matching "/api/*", return a response with 200 as its status, containing the content within the file "atlanta-conditions.json" as it's response body!
By default, wiremock will pull that file from : test/resources/__files/ - so add a new file called atlanta-conditions.json. I copied a response from the live webservice API earlier into that file:

{
  "response": {
  "version":"0.1",
  "termsofService":"http://www.wunderground.com/weather/api/d/terms.html",
  "features": {
  "conditions": 1
  }
        , "results": [
        {
        "name": "Atlanta",
        "city": "Atlanta",
        "state": "GA",
        "country": "US",
        "country_iso3166":"US",
        "country_name":"USA",
        "zmw": "30301.1.99999",
        "l": "/q/zmw:30301.1.99999"
        }

        ]
    }
}

With the addition of this file, we can then run our test - which should pass. So - what have we done? We've mocked the response from the webserver, decoupling our test from dependence on a live webserver, and provided a canned response that speeds up our test suite because it's local data, doesn't incur a hit against the api limit, and is immune to the service going down.

Example Code: Weatherview

I hope this article helped to outline how mocking a REST webservice can be accomplished easily by using WireMock! I wrote a quick example project of how you can use WireMock to test your services that i've put Right Here on github. Check it out (and let me know if you have questions or ideas about mocking with webservices)!