Return to site

Coderbunker white paper: technical aspect of recent mobile work

Intro

The intent of this article is provide technical details about recent solution was developed for our client. The engineering value in this article is overview of existing&team implemented solutions for client issues, their pros&cons and implementation challenges.

The article is addressed to engineers and technical managers.

Testing tools

At the early begining of mobile applications majority of engineers didn’t use testing tools. Short development simplicity (4 man month), focus on time to market and general simplicity were factors with impact on this decision.  
Nowadays there mobile application becomes major focus for business to interact with end uses. Life cycle of mobile application development becomes longer and value of automation tests become heavier. This section covers overview and general analysis of existing testing tools.

Automated tests recorder

Since autumn 2016 Android studio provides automation test recorder. This tool creates tests when you emulate user behavior. You just simply run this tool, it runs apk on the emulator and you click the use case you would like to test. Based on your behavior tool automatically generate Espresso code to test this use case.

It can be challenging to get a whole tests working properly. Currently this tool is not so smart to have working test out of the box, issues have been discovered so far:

  • doesn’t handle properly concurrency cases

  • doesn’t handle properly animation cases

  • doesn’t handle properly RecyclerView elements

Despite on it doesn’t give you what it promised, this tool brings engineering value by generating basic template which you extend, refactor and utilize for proper automatic tests.

Robotium

Robotium is a test framework created to make it easy to write powerful and robust automatic black-box test cases for Android applications. Here the list of features which emphasize it among others:

  • Robust and popular framework

  • Paid Robotium recorder with Android studio integration (analog of automated tests recorder)

Espresso

Espresso is UI test framework for Android. It runs on emulator or real device and allows you to emulate user behavior. Here the list of features make sense to emphasize:

  • Google focus. Which should give us the best integration with google software, long development life cycle and quality of software

  • Automated test recorder provide tests in espresso

  • Tight integration with Android, better synchronization of background work.

  • Clear and minimalistic API, more detailed debug information

  • Many engineers consider it as a replacement to Robotium

Robolectric

Robolectric is a unit test framework that de-fangs the Android SDK jar so you can test-drive the development of your Android app. Tests run inside the JVM on your workstation in seconds as Robolectric rewrites Android SDK classes to make them possible to run on JVM.

  • Allows run UI tests on JVM - without device, beneficial for CI to avoid time to run emulator

  • Reflect Android API which means not all API is available and sometimes it’s painfull to look for workarounds

  • Operates well with asynchronous tasks

  • Has issue with UI test

Junit

Junit is a frameworks for unit tests. It is de-facto standart for Java and Android development and uses in many others testings frameworks.

In memory search engine

Our client was looking for the fast access to the documents. Current implementation was a simply a file browser which takes time for user to get access to the right file. The best option was minimize amount of clicks to content which ideally should look like search engine.

How it works. Our aim is to give end users ability to search documents by keywords assigned to each document. How this association between keyword and document is defined? Considering several requirements (out of scope of this article) this association is defined by the folder dependency to each other: automate script exports data from the relational database and generate files hierarchy. This files are distributed to mobile client via p2p.  Each folder and file names are keywords available for the input.

After start algorithm takes a root folder and go through all file structure to define indexes and corresponded search results. It can be shown in 3 steps: generating vocabulary of words (indexes), assigning search result for each index and implement search functionality by multiple indexes.

Vocabulary generation. Algorithm gets all file paths, extract tokens and put them into hash set as keys.

Generating search results. Algorithm gets keywords generated on the previous step and compare each of them with each file path. When match keyword and path segment found, file path to binary file is added to the search result. In case search engine has a requirement to support search by keywords itself, when inclusion in file path found, each path segment from the right side is file search result by itself.

Search by keyword. After indexation app has a HashSet where keys are our keywords and values are collections of file paths. In case when user looks for one keyword, application simply returns a collection assigned to this keyword. In case when user looks for several keywords, application get several collections and returns intersection of this collections. That’s it.

Limitations. This search engine keeps all data in the runtime memory. As amount of this memory has a limit, app can support only fixed amount of indexes and corresponded search results. It fits our client needs as we have one model of Android tablet and can predict size of the model and even with doubled amount search engine has enough memory.

Another limitation is lack of distinguish of multiple words in Chinese file names. In Chinese there is no space separator between words and code should apply NLP techniques to support it. For business aims there is no need to support it as search by beginning of the word is enough and we don’t have to put more resource in this task.

 

Advantages. Instead of do search through file system users receive quick access to any document by entering business terms they are familiar with. Compare with previous UX implementation current one doesn’t have tight dependency on the structure of the model. It gives ability to update model at any time and don’t need to update the client side.

P2P solutions

Internet connection issues and quality with passing information are well known for China region. They are often caused by not proper configuration of network topology, cheap / low quality routers and exceeded bandwidth in the peak load. In such conditions web request from mobile clients are often challenging.

Our team decided to go with p2p solution for transfer binary data as this technology automatically resend drop packets and eventually guaranteed delivery. We explored several projects available on the market and ended up with this comparison table

Resilio (formerly Bittorrent Sync)

  • Reliable File Transfer Over Unreliable Networks
  • Sync skips the cloud and finds the shortest path between devices when transferring data. No Cloud. No uploading to third party servers. Just fast, simple file syncing.
  • https://www.resilio.com

     Pros

  • Easy to use and commercially supported

  • On the market for many years already as Bittorrent Sync

    Cons

  • Closed source

  • Android client lagging (still Bittorrent Sync)

  • No corporate deployment support in Android app

Syncthing

  • Syncthing is an application that lets you synchronize your files across multiple devices. This means the creation, modification or deletion of files on one machine will automatically be replicated to your other devices. We believe your data is your data alone and you deserve to choose where it is stored. Therefore Syncthing does not upload your data to the cloud but exchanges your data across your machines as soon as they are online at the same time.

  • https://syncthing.net/

  • https://github.com/syncthing/syncthing-android

    Pros:

  • Master setting to ensure data on server directory never changes

  • LAN file-synchronization

  • Has Android integration

    Cons:

  • Current Android client has various negative feedbacks regarding stability of the app

  • Client inside use various hacks to run unix commands

  • Client needs ID of (server/another peer) and vice-versa before synchronization

hive2hive

  • Hive2Hive is an open-source library, written in Java, for secure, distributed, P2P-based file synchronization and sharing. It is built on top of TomP2P, an advanced, high-performance DHT for multi-key-value pairs. The Hive2Hive project is licensed under the MIT License and any contribution is welcome.

  • http://hive2hive.com/

    Pros

  • Designed to be secure from the ground up

    Cons

  • Security comes at the cost of many additional hoops to jump through

FreedomJS

  • freedom.js is a framework for building peer-to-peer (P2P) web apps. Easily create social applications that work in modern web browsers, Chrome packaged apps, Firefox extensions, node.js, and native mobile apps. freedom.js apps are just JavaScript, so they can be distributed as packages on an app store or hosted on static web servers.

  • http://www.freedomjs.org

    Pros

  • Could be interesting to explore a Javascript solution since we use React-Native

  • Could integrate very closely to our solution

    Cons

  • No concept of folder synchronization

  • Significant development required

What is meant by master-slave? We don't want the end user peers to be able to change the share (read-only share) and if any changes are made on the client, the p2p client should force push the delta from the main seed to ensure that both client and seed are in sync.

Continues Integration

Intro

The intent of CI is make sure you can build your project at any time in one button and automise a whole process. Usually CI not only compile the build. It also run tests, static analysis tools, generate reports and even publish build to the distribution place. Syntax and code errors in repo which can be spotted by static analyzers.

For Android project traditionally developers choose Jenkins. However there there are plenty amount of negative feedback that Jenkins in long term is fragile and difficult to maintain. This and bad user experience force engineers look for alternatives.

Codeship becomes a popular alternative, however it doesn’t let you run Android builds, but CircleCI is another one modern solution.

Why engineers prefer CircleCI

  • nice interface which makes it comfortable to se

  • easy configure and maintain -- all configuration exist in one file into the repository

  • it has pre-installed and regularly updated software which you can extend by installing additional software

  • CircleCI automatically takes care about each branch by running all set of your tasks on each branch

  • it has integration with popular tools

Emulator issues

In Android development there are two emulators used by engineers - x86 and Genymotion. The fast emulator x86 and the fastest emulator Genymotion can not be run inside CircleCI.

  • Genymotion requires direct access to the hardware and at least for now can not be run inside VM: “Why doesn't Genymotion start from a virtual machine? Genymotion cannot be run from a virtual machine. Indeed, Genymotion needs a direct access to the hardware in order to provide OpenGL acceleration. Running Genymotion from a virtual machine prevents it to directly access the hardware components. Therefore, Genymotion is incompatible when installed from VMWare, Parallels, Hyper-V or VirtualPC.”
  • x86 emulator requires KVM on Linux, and CircleCI team can’t provide it.

Only ARM emulator is available on CircleCI. However even with I faced with several issues:

  • hangs out, emulator just can not start with maximum threshold

  • application execution throws OOM

  • general toxic environment for tests

Possible solutions for that are:

  • increase the min and max heap sizes in config.yml which can help with not started emulator _JAVA_OPTIONS: "-Xms512m -Xmx2048m"

  • create emulator with higher memory capacity
    android create avd -n avd_name -t "android-22" -s 1200x1920 --abi default/armeabi-v7a -c 2048M

  • mitigate issue with performance by running app into the private cloud behind the firewall which help us to increase the power (RAM) of the CI server.

  • integrate with 3rd party cloud farms for test application on device farms and VMs, Firebase and saucelabs

  • There is a beta version of genymotion in the cloud which potentially can help with integration to CircleCi without need to install it on separate machine. https://www.genymotion.com/cloud/

  • Another interesting option is use Nexus 10 device and configure different screen sizes via the command adb shell wm size 1280x800

Automatic tests issues

Running tests on Android emulator have plenty amount of issues.

  • animations can't be handled by tests properly which causes them to fail.
  • crash & ANR dialogs causes your UI tests to fail.

  • the keyguard, WiFi radio, and CPU might sleep unexpectedly while tests are running.

During my research I discovered several solution to overcome it, but offer the clever alternative and the most comprehensive one which cover all this cases.

Robolectric

Robolectric runs tests on virtual machine. It has limitation on tests functionality but it is the fastest way to run tests and avoid issues with emulator I mentioned above.
http://stackoverflow.com/questions/18271474/robolectric-vs-android-test-framework

Test butler

Guys from LinkedIn implemented their own library which publish in open source. This lib is the the most comprehensive solution to overcome all issues Android developers faced with during automation testing. All abilities of this library you can see by this link

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly