Blog Archive

Last modified by Thomas Mortagne on 2020/01/28

Blog - posts for June 2019

Jun 28 2019

Bug Fixing Day 215

This Thursday we had our Bug Fixing Day #215. We've managed to close 11 bugs (8 real fixes)  with 3 participants. We are still at -177 bugs behind the 500 days period. ...

Jun 26 2019

Reasons to choose Kotlin

Hello there! My name is Divyansh Jain. I am a student of Mahatma Jyoti Rao Phoole University. I have been selected as the Android developer for the XWiki organization and I am working on their XWiki Android Authenticator application in GSOC19.

XWiki android Authenticator aims to integrate a wiki instance in Android accounts, mainly including the synchronization of contacts and the XWiki authenticator. By synchronizing contacts of your company on your phone, it becomes easier to communicate and collaborate with each other.

Ever since the start of my work on the XWiki Android Authenticator app, I have been constantly learning new things. In the first week, I migrated most of the XWiki Android Application code from Java to Kotlin. And on this page, I would like to share my understanding of Kotlin that I have gained so far.
 

Getting started with Kotlin

Kotlin is officially supported by Google for mobile development on Android. It was released in Android Studio 3.0 on October 2017. At first, I was a bit afraid to switch to Kotlin since I feared that the code might crash and not run properly, but as I read the documentation, I started understanding the nuances of the language which made the switch from Java to Kotlin an easier process. I started realizing the advantages of Kotlin over Java. Some of them being:

Java Interoperability

I started with migrating the whole XWiki Android Authenticator app code from Java to Kotlin. I was replacing one Java file at a time, and while migrating I saw that Kotlin worked with Java smoothly. Though it required some direct imports, there were no errors in running the app on the device.

Changed variable declaration

In Java, we declare string for instance, String str = "Hello";.

In Kotlin, we declare string for instance, val str = "Hello" or val str: String = "Hello". Here val declares a read-only property or local variable whereas var declares a mutable property or local variable.

The final keyword is default in class

In Kotlin final is a default. E.g.

             
class Button {
   fun click() = print("Click")
}

class displayToast : Button() {  // Error
   override fun click() = print("Toast Displayed") // Error
}

In the above example, class displayToast can’t inherit Button class because it is final. Moreover, it can’t override click(), because it is final in Button.

open class Button {
   open fun click() = print("Click")
   fun doubleClick() = print("Double Click")
}

class displayToast () : Button {           // Inheritance is now possible
   override fun click() = print("Toast Displayed") // Now it works
   override fun displayToast () = print("Toast Displayed") // Error
}

In order to inherit and override, we put “open” keyword that allows inheritance and overriding.

Fun keyword for defining functions

Now in Kotlin, there is a new way to define functions. E.g.

fun displayToast() { } //with no arguments inside functions

fun addDigitis (a: int, b: int) : String { }  //with arguments inside function

It is same as the Java parameterized method or empty method.

The when expression

The "switch-case" is replaced with the much more readable and flexible "when" expression: E.g.

int x = 3
when (x) {
   1 -> print("x is 1")
   2 -> print("x is 2")
   3, 4 -> print("x is 3 or 4")
   in 5..10 -> print("x is 5, 6, 7, 8, 9, or 10")
   else -> print("x is out of range")
}

It works without the argument too.

Static keywords

For declaring static methods & variables, you can put them above the class name, then you can use them by importing directly in other classes.

Null Safety

One of the biggest flaws in Java is the way it handles “null,” leading to the dreaded NulPointerException (NPE). Kotlin resolves this by distinguishing between non-null types and nullable types. Types are non-null by default, and can be made nullable by adding a safe call ‘?’. E.g.

var a: String = "abc"
a = null                // compile error

var b: String? = "xyz"
b = null                // no problem

Conclusion

So after seeing, reading and migrating the code from Java to Kotlin, in my honest opinion, I do not see any reason to not choose Kotlin over Java. For instance, we need to write less code as compared to Java, we don't have to face the dreaded ‘NPE’ error anymore, interoperability with existing Java files, smart casts while declaring variables and many more. We've given the fair amount of our time to Java, but it's time to let it go and welcome our new friend Kotlin.

Happy Reading.

Android UI Unit Testing with Espresso

Hello there! My name is Divyansh Jain. I am a student of Mahatma Jyoti Rao Phoole University. I have been selected as the Android developer for the XWiki organization and I am currently working on their XWiki Android Authenticator application in GSOC19. In the last week, I wrote a blog post titled "Reasons to choose Kotlin". This week, I will discuss Android UI Unit Testing with Espresso.

Android UI Unit Testing with Espresso

Unit testing is a way to test individual units/components of the app. It helps to break down the app into individual units/components so that we can focus on that individual unit only. As test runs, we compare the test results with expected behavior which helps us to identify even a single flaw too.

UI Testing

The basic concept of the UI testing is the same as Unit Testing, but here we run UI components like login, signup, etc. on Emulator or test device. This allows us to replicate the user UI interaction while testing. So when we run, say login test on an emulator, we replicate the user entering its credentials and see whether his credentials are correct or not. Here, two major things are used:

Espresso

Here interaction is done by Espresso. Espresso helps us to simulate the user interaction with UI. It can typeText, clear text, click on the button, scroll to a list, swipe left, swipe right, etc. In summary, it can perform all user interactions that the user does on the UI which is very simple to use. For example:

  • Let’s say that you want to enter the username in the edittext on the screen, then execute:

      onView(withId(R.id.accountName).perform(typeText("TestUser")) 

    Here onView(withId(R.id.accountName) is compulsory as it checks for the view (R.id.accountName) on the current view also known as the 'viewMatcher'. So if the view exists, then it performs the 'viewAction'. Here viewAction -  "perform(typeText("TestUser"))" writes the text “TestUser” in the field.

  • You can also put check() which verifies the content of the given view. Say you want to check the text written on the button or check if textView content has changed or not, in that case, we run:

    onView(withId(R.id.tvExample)).check(matches(withText("Hello")))

    Here onView function is the same as in the above example. And next check method is a viewInteraction which matches the current view i.e tvExample with the text “Hello”. So if the text is matched, then the test will pass, otherwise, it will not.

  • It can also check for the data loading into the Adapter. Espresso provides onData() method. By using onData(), we force our desired element into the view hierarchy. Say in your adapter, there’s an item “Coffee” of string type.

    onData(allOf(`is`(instanceOf(String::class.java))
          ,`is`("Coffee"))).perform(click())

    Earlier we were using onView() to find the view, but it cannot find the view that has not been loaded yet, so here we use onData() to match the string “Coffee” into the list.

Idling Resource

As the Android Developers Documentation states: “An idling resource represents an asynchronous operation whose results affect subsequent operations in a UI test.”  By using Idling Resource, we can notify Espresso to wait for the completion of Asynchronous operation and then execute the rest of the code. Let’s assume that there are cases where you are loading the data in the RecyclerView/ListView. What happens now? Yes, it will not wait for the completion of the Asynchronous operation; it will end the test case immediately. You may find some simple solutions like putting SystemClock.sleep(period) or Thread.sleep(period) but these are not good practices as you cannot determine the amount of time it will take for your Asynchronous operation to complete. Load the data and display it.

That’s where Idling resource comes to rescue. It notifies the Espresso that an Asynchronous operation is made and that you have to wait for it. Then as soon as the operation is completed, it loads the data and displays it.

Conclusion

I really enjoyed working on UI testing. Espresso made all the work very easy. viewMatcher (onView(objectID)) easily finds the object in the current view, and to simulate user inputs, viewActions is equipped with all kinds of viewActions (perform(actionName)). While working, I did stumble upon an error (androidx.test.espresso.PerformException) which states "Error performing "viewAction" on view 'Animations or transitions are enabled on the target device." To resolve this, go to system setting -> Developer Option -> set all three animations to "No animation". That will do the trick. I did enjoy working with it, I am sure, you will too. Feel free to ask for any doubts.

Happy Reading.

Jun 25 2019

XWiki 11.5 Released

The XWiki development team is proud to announce the availability of XWiki 11.5. This release continues the work on improving concurrent editing of pages and introduces new page and attachment pickers for macros. The code macro gets a new layout to display line numbers. Inline editing support for wiki macros has also been greatly improved. ...

Jun 21 2019

Bug Fixing Day 214

This Thursday we had our Bug Fixing Day #214. We've managed to close 6 bugs (3 real fixes)  with 2 participants. We are still at -166 bugs behind the 500 days period. ...

Jun 18 2019

XWiki 11.5 RC1 Released

The XWiki development team is proud to announce the availability of XWiki 11.5 RC1. This release continue the work on improving concurrent editing of documents, introduce new page and attachment pickers for macros. The code macro get a new layout to display line numbers. Inline editing support for wiki macro also been greatly improved. ...

Jun 14 2019

Bug Fixing Day 213

This Thursday we had our Bug Fixing Day #213. No bugs were fixed. We are still at -159 bugs behind the 500 days period. ...

Jun 08 2019

Bug Fixing Day 212

This Thursday we had our Bug Fixing Day #212. We've managed to close 5 bugs (all real fixes)  with 1 participant. We are still at -162 bugs behind the 500 days period. ...

Tags:
Created by Admin on 2008/12/22
    

Get Connected