Mobile app makers review

A friend came to me recently with the idea of creating a mobile app that would support the learning platform that he already has. We discussed what features he wanted and what his budget was. The budget was tight, as is normal for any small and medium enterprise and I realized that developing the app from scratch was not an option. Mobile app makers to the rescue!

I knew that there should be some mobile app generators on the market, but I had no idea what features they offered and at what cost. Actually, I only knew that they “had” to exist. I was thinking that I’ll find a few online platforms tackling this problem. To my surprise, I discovered that there were more than mature 20 platforms, all offering similar features. I soon found out that the industry, of mobile app makers, is quite mature: there are reviews and comparisons and top10’s.

Soon after I started reading I understood that all those articles will not help me with my problem: determine how much it would cost to run such an app. The reason is that the platforms are vastly diverse in terms of their offering: different prices for similar, but not always the same set of app features. The services included in the contract and the actual terms would also vary greatly. I had to make my own research and comparison, based on the needs of the friend.

In this post, I’m sharing the results of the research that I’ve done. Disclaimer: 1) I only used this article as a source for mobile app makers, so I might have missed a few. 2) My focus during the research was on the feature set that my friend needed, so if a feature isn’t there, it might still be available. 3) I only spent 10-15 minutes with each app builder platform, so I might have missed details that need more digging (or contacting customer support).

This comparison sheet is not detailed nor complete enough to allow me to select a “winner”. Instead, I will use it during the discussions with my friend to make a shortlist of 2-3 mobile app makers that I will investigate further.

If the table below is too hard to read, you can access the comparison sheet directly.

Unit testing algorithms

In the last weeks, I’ve been improving my computer science knowledge by solving programming problems. Since these problems have multiple solutions, I find myself writing duplicated unit tests. And refactoring these tests is cumbersome (if find&replace doesn’t work).

To make the point clear, I’m going to pick a problem with many possible implementations: sorting an integer array. To solve it, we can do heap sort, insertion sort, merge sort, quick sort, selection sort and so on. In the end, we will have a set of five tests for each test case. If in the future, I’ll come up with a new test case, I’ll have to write five tests to check each implementation. This is far from optimal.

After doing a bit of digging I found a convenient solution to removing the duplication: JUnit5’s @ParameterizedTest and @ValueSource. I had to do a bit of refactoring: I created a new interface that declares the sort method and I made sure that all *sort classes implement the interface properly (you did create one class per implementation, right?). After that, it was just a matter of wiring up the tests.

Cool! 🙂 Before, the unit tests were all over the place and not all implementations had all the corner cases tested. Soon enough, I found that the QuickSort implementation throws StackOverflowError when the input array contains duplicate values. You can find the source code here.

Xiaomi MiBand3 and privacy… not much

7/11/2019 Update: I just received a concrete answer from Xiaomi’s Privacy Office: “MiFit is a product of Huami. Xiaomi Singapore Pte Ltd is not the MiFit data controller and is not responsible for processing the personal data of MiFit ‘s data subject. Please refer below Huami’s contact information is privacy@huami.com.”. So, I’ve made a SAR to Huami.

MiBand is a wearable activity tracker produced by Xiaomi. The 3rd generation has a reasonable feature set and it is 2-3 times cheaper than its competitors. It’s a great entry-level band if you want to begin tracking your fitness levels.

I bought a Xiaomi MiBand3 because I was hoping to make sense of my erratic sleeping patterns. I was also eager to discover how much movement I was getting through the day. Additionally, I was hoping to connect with some faraway friends via the MiFit phone app.

“But what about privacy?” a nagging voice in my head kept asking. The data that a fitness tracker generates feels personal and Xiaomi is a Chinese company. I don’t want the Chinese government to have information about me. It’s bad enough that Chinese citizens have no privacy. To make an informed purchase, I searched for articles about “Xiaomi privacy”. I found two articles (1 and 2) reviewing the InfoSec aspects of a couple of fitness trackers. Yet, nothing that answered my question about Xiaomi. In the end, I decided to buy the band, but I felt uneasy every time the MiFit app “synchronized” with the band. Uneasy, but not concerned enough to look deeper into the matter.

Susana Sanz, from BalkonTactics, renewed my interest in privacy and InfoSec. After our talk, my unease changed into serious concern about the data generated by my shiny, new fitness tracker. The ethical/moral/philosophical aspect of privacy did not interest me, that’s something that others have talked in more detail (Glenn Greenwald and Edward Snowden come to mind).

I was interested to know what exactly does Xiaomi know about me. Making a Subject Access Request (SAR), a right recognized by the GDPR, is one way to go about it. For the sake of learning how SAR work, I submitted one to privacy@xiaomi.com. But this process would take a long time and I don’t like to wait. While waiting for an official response, why not use a “hacky”, DIY approach to get an answer?

Nowadays, almost all phone apps communicate with a server on the internet. It is possible to intercept that communication, while it’s happening (see the technical method section at the bottom of the post). Thirty minutes later, my concern was confirmed: Xiaomi collects all the data that MiBand generates. To be more specific, all the data that is shown in the MiFit app (e.g. sleep data, training data, heart rate, etc.) gets uploaded to the Xiaomi servers. There is no way to disable the upload in the configuration of the application. The band keeps a backlog of all the recorded data and everything gets uploaded to Xiaomi when you use the mobile app. If you don’t use the MiFit app, you’ll end up with a band that only knows how to count your steps and how to measure your heart rate.

The only good news here is that, at this moment, the geo-location data is not collected passively (outside training sessions). But there is no guarantee that it will stay like this in the future.

This is a lot to take in. In the end, I’m left with a feeling of disappointment that Xiaomi has unrestricted access to sensitive information about my lifestyle:

  • what would happen if someone infiltrates their systems? I’m sure that there are ways in which this data could be exploited to my disadvantage.
  • what’s up with this shady user agreement? Not clear to me what Xiaomi and its partners do with the data. I understand that the moment it gets uploaded I “waive any and all ownership, legal and moral rights” to my data. But how does Xiaomi use it? Who are the third parties or Xiaomi affiliates that have access to it? Is it sold or monetized in any way? Lots of questions and no clear answers.

If you’ve been on the internet long enough, you’re familiar with the phrase “If you’re not paying for the product, you are the product”. Fun fact, in 2016, the average worth of a Facebook user was $3.73 per quarter. I’m not ok with that, but let’s leave it there for now. Thinking logically, the phrase should not stand once I start paying for the product. Right? Well, it seems that this is not the case with Xiaomi MiBand.

I’m dissatisfied that, despite paying for the MiBand, I “waive any and all” rights over the data that I generate. In this new light, what seemed to be a good deal (best cheapest fitness tracker on the market) became a lousy deal when reading the fine print and doing a bit of research.

In the end, there are two big questions left in my mind about this way of collecting personal data:

  • is this a general practice of the fitness band industry or is Xiaomi an exception?
  • are other Xiaomi products collecting data in the same way?

If you own a fitness tracker or another Xiaomi product, can you do a bit of digging around and let me know? Or get in touch with me and we can do the research together. 😉


The technical method of finding out what MiBand3 data gets uploaded to Xiaomi’s servers was simple. Had I known it would be so simple, I wouldn’t have postponed it so much.

The hardware setup: I had to install mitmproxy on my laptop.

  • connect both my phone (with the Xiaomi MiFit app) and my laptop to the same WiFi network
  • install and run mitmproxy on my laptop
  • install the mitmproxy root certificate on my phone
  • on my phone, set the proxy server for the Wifi to point to my laptop
  • open the Xiaomi MiFit app and look at the requests going into the proxy running on my laptop

Out of all the requests made by the Xiaomi MiFit app, only one sends a lot of data:

POST https://api-mifit-de.huami.com/v1/data/band_data.json?r=50AB6198-7007-47BF-86AC-53F606CDD4F6&t=1565977799279

In the payload of this request is a key called data_json that contains all the recent band data (as the name of the endpoint suggests). I took a look at the data in the JSON object and saw all the data points that are shown on all the graphs (in the app), including all the geo-coordinates of my running sessions. To my surprise, the MiFit app didn’t seem to send to Xiaomi information about my current location. Yet, this is not a guarantee that this information will remain on my phone in the future.

From a technical perspective, I enjoyed doing this little research. Using mitmproxy was straightforward and I recommend it if you want to see what communication goes on between the apps on your phone and the internet.

Database integration tests

Did you ever struggle while trying to write integration tests without mocking the third party? I know I did.

I’ve known about Martin Fowler since I was a junior developer. He is one of my favorite technology thought-leaders and I enjoy reading the thought-provoking articles that he publishes on his blog. In this post, I want to expand on his article about the test pyramid, in which he explains the difference between unit tests, integration tests and, UI tests. I’ll expand on the part about integration tests.

I want to show you an easy way to run integration tests against a database. With this goal in mind, I’ve created this java demo project. It illustrates the concept and is useful as a starting point for more complicated applications.

In the past, I would delay writing the integration tests. I dislike the idea of not having any integration tests. Fixing errors at runtime is not something that I want to do in Java. Meanwhile, I didn’t want to invest time on setting up a separate test infrastructure. And tests running against a mocked database, are not testing anything. The options seemed limited:

  • mocking the database interaction layer
  • connecting to an in-memory database
  • connecting to a local/remote test database

Regardless of the option I picked, I always had the feeling that the solution could be more elegant. My hesitation would turn into frustration as the application grew and the tests would become harder to maintain. Recently, I discovered a better option: connecting the tests to a database running in a Docker container.

In my last project, Vlad and Max showed me that using docker containers simplifies running integration tests against a database. No mocking, no complicated infrastructure, no tinkering with configuration files. As long as you can run Docker on the build machine, you can run the tests.

This is the elegant solution that I was looking for:

  • install and configure Docker on the build servers and the developer machines that will run the tests
  • use docker-maven-plugin to build a docker image of the database and start/stop a container based on the image
  • populate the database with the necessary data (use ‘/docker-entrypoint-initdb.d/’ or a database migration tool like flyway)
  • finally, use maven-failsafe-plugin to run the integration tests

I like this approach because the integration tests are portable and easy to debug. If the tests run on my laptop, they will run also on the build machine. If the tests fail on the build machine, the problem will also appear on my laptop.

I also like that the tests are repeatable: the plugin builds the Docker image from scratch before the tests start and removes it after the tests finish.

Finally, I like that this approach is transferable to other types of integration tests. It’s easy to replace the database container with a dockerized REST API (in a move towards contract testing) or with a message queue container.

The demo project is more than a typical “hello world” application. The integration test starts a docker MySQL container and makes a simple SQL query. You will notice that the docker-maven-plugin configuration is more complicated than necessary, given such a simple test. The reason: the code samples that I found online seemed trivial. I wanted to have a “bootstrap” project that I could reuse in real-life projects without the hassle of gluing everything from scratch.

This approach to writing integration tests has opened my eyes to the possibilities that exist today in the QA automation domain. The tools built on top of Docker seem varied enough to accommodate all test types. The number of plausible excuses for not having a proper CI pipeline is getting too low…