AWS HoneyCode is a new low-code development tool by Amazon, currently in Beta. Amazon offers a lot of great services as part of AWS, so we wanted to try this new thing out.

In the past months as the world spiraled into a global health crisis, we had to deal with the new reality – just like everybody else. As the health situation in Croatia started to improve, we needed a way to organize so that people could safely work from the office.

We set up a system where we limit the office capacity so we can uphold the social distancing rules.

Some people preferred working from home, while others were eager to return to the office where the free coffee flows in vast rivers and where there is a dedicated workspace and a great work atmosphere. Those people had to write their names in the spreadsheet to reserve their spot in the office.

Users could log in, see their reservations, and add new reservations – assuming there is available room. The system wouldn’t allow more than one reservation per person per day, and it also took care of enforcing the capacity rules for each floor.

The admins would see all the reservations in the system, along with the stats on floor capacity for each day.

Indeed, all of this was possible in HoneyCode. It took about 6 hours to build this app from scratch, never having seen the software before.

HoneyCode provides a web app where you can create Workbooks, and each Workbook can have multiple tables, automation, and apps. You can also have multiple teams – this is probably used to separate who can see which apps, but we haven’t tried that part out.

Defining the data source for the app is very simple. Simply create a series of tables in the Workspace, which can then be referenced from other tables and from the UI – either directly or by using functions.

You can also set up reminders and alerts for when the data changes.

The UI is built by adding screens and objects to them. Each screen can appear in the top-level navigation if you add it explicitly, otherwise, the only way to get to it is with an action by clicking a button or table row.

You get a mobile and web interface without doing any work to support the different form factors – that part just works.

The basics work well enough, once you connect the data to a field you even get a live preview with just a couple of seconds lag between changing something in the UI object properties and seeing the preview.

To display data in the UI elements, link it to some data source which could be a table, a function that references a table, a local variable, or a combination of those.

To use the apps created via HoneyCode, everyone needs to have a HoneyCode account and be invited to the team. I’ve played around with implementing my own authentication by building a users table, and login/register screens, but that’s not really possible because there’s no way to send an email or hash a password.

Having that possibility would also be a problem for their pricing which is per user.

There is no nice way of locking parts of the app for some users. In order to distinguish an admin from a user, a new table with a list of app admins must be added. Then you can check if $SYS_USER (global variable with currently logged in user) is on that list and based on that, hide some UI elements.

For users to use the app, they need to be invited to HoneyCode and log into the web interface or inside the HoneyCode mobile app. There doesn’t seem to be a way to export the app and publish it to a standalone web server or app store. This makes it a bit cumbersome for users.

There is no way to add images to screens, and the UI options are spartan. It’s good for displaying tables and forms, and you can size and color the text, but not much else. Forget about images, graphs, and similar.

Adding a new record and getting back to the list doesn’t display the new record. It’s there after relaunching the app, though.

There is no way to mark a form field as required and no way of defining some validations on the field itself. The workaround is to write a convoluted visibility rule so that the submit button is hidden if the form is not filled in correctly.

This is the visibility rule for the done button when adding a reservation:

It will hide the done button if any of the fields are blank, if the user already has a reservation for that date or if the location is full for that date.

The basics for working with the data are not bad, it works like excel and that’s good because it fits and it’s familiar.

Programming the UI with these excel-like rules is quite tiresome (just look at the code sample above). There’s no good way to do input field validation, just a hacky workaround.
It’s also not cheap for a larger number of users. For 250 people, it would cost around $5k/month.

In its current state, I wouldn’t recommend this tool for any project – not even the simple ones. It’s just way too easy for the requirements to outgrow what you can currently do with HoneyCode. Hopefully, this changes in the future as Amazon adds more functionalities.

APIs (application programming interfaces) make mobile apps and browser apps work. A great API serves as the building block for all the other components of a successful mobile app. Whether app developers are creating their own API or piggybacking off a larger system, a successful API will lead to a better working, more timely mobile app.

While creating a consistent and timely API is not the flashiest or the most visible part of a new mobile app, it is arguably one of the most important aspects of any well-developed app.

Here are a few aspects of a strong API strategy that leads to productive mobile development:

APIs should be planned strategically for the long-term stability.

Before the API development can start, as much as possible of the requirements needs to be known and the developers themselves need to have a strong understanding of the problem they are solving. That usually means that developers need to dive deep into the problem domain and get very specific answers about everything that’s unclear.

Once the development team has a good understanding of the problem, it’s time to design the system. Most APIs need a way to store data and for most use cases, relational databases are a great way to store data.

The way data is stored can have a big impact on the performance and functionality of the API so it’s very important to invest an appropriate amount of time into defining the database entities and relationships between them.

This is a great investment of time because it ensures you build the system on a solid foundation.

If API design is not done properly before development starts, massive changes might be required later on in the project and the costs are considerably larger at that point. Any change on the API may cause changes on all of the clients using it.

Good API design follows standard conventions which are appropriate for the problem the API solves. By following standards, the API is more intuitive to mobile developers and therefore creates a certain ease of use.

By following standards in API development, app developers can use existing knowledge and tools – making app development less costly. Having logical naming and consistency throughout the API goes a long way to minimize development costs for users of the API.

A typical modern API is a RESTful API which uses JSON as the data transfer format. For some use cases, standards like gRPC, Thrift and GraphQL are more appropriate.

As much as is possible, the API should behave predictably and work without (unpleasant) surprises.

That includes using a consistent format of error responses and the appropriate HTTP status codes.

API tests are as important as app testing, in that API tests ensure that applications, systems, databases, and networks can communicate with each other and exchange information. Testing should both prove the API is working as expected (i.e., without bugs) and according to its specifications.

As much as is possible, testing of the API should be automated by using a continuous integration setup.

Testing should focus on use cases which are as close as possible to those that are or will be happening in production.

In order to make integration of mobile apps with the API easier, there should always be one or more test environments. Test environments are API deployments to separate endpoints which allow for various testing which can’t and shouldn’t be done in production. In fact, testing in production should be avoided altogether if at all possible.

If the production API is already live, a good way to get representative test data into the test environments is simply copying the data over from production periodically. When doing this it’s very important to remove all personal information like names, email addresses, bank account numbers since the test environments don’t imply the same level of data security and same access rules.

By ensuring the test environments work in the exact same way as the production environment, integration with production for the mobile teams should be much easier. Switching to using the production APIs should be as simple as changing the host name from test.example.com to example.com.

For the API to work consistently (and to troubleshoot any later problems), API developers should document everything. The documentation should be clear, correct, and easy to understand. The documentation should also be updated as the API changes so it doesn’t contain outdated and incorrect information.

While API documentation is very important, it’s often regarded as tedious and boring work by developers so it’s important to make the documentation process as easy and automated as possible. The API documentation should be automatically deployed with the API, without any manual intervention needed.
We can take this a step further and eliminate a lot of the manual work by generating documentation with examples from API test cases using tools like our own dox.

Business requirements change over time, the supporting software also needs to change to keep solving the right problems. When the API changes, we want the API clients to keep working.

Since non-breaking changes, like just adding new functionality to an API, are usually not a problem — let’s focus on the breaking changes.
How do we handle those?

The naive solution would be to immediately update all the API clients, but that isn’t as simple with mobile apps. iOS apps need to undergo a review process by Apple which can take days, sometimes even weeks. Even after the mobile app updates end up in the respective app stores, many users won’t update soon (or ever) to a newer version of the app.

The main tool for solving this problem is API versioning. The most straightforward way to use API versioning is to copy all the functionality of the API and start serving the new version of the API on different endpoints, including the breaking changes. Usually the new endpoints are just prefixed with a different version, so the API would support calls to both /api/v1/login and /api/v2/login — with the old endpoint retaining the old behavior.

While API versioning is a powerful tool, sometimes it isn’t enough. Maintaining multiple versions of an API can be time consuming, and thus costly. Sometimes, for various reasons, API versioning may not even be possible. It’s wise to design a mechanism which can force clients to update to a newer version. For mobile apps we use Prince of Versions to specify a minimum client version per platform.

While this mechanism should rarely be used, when you truly need it — it’s invaluable. You can use it not only for breaking API changes, but for any situation when you may need to force the client to update.

To handle breaking changes on the API you can either deploy a new version of the API which increases the maintenance burden or force all the clients to update which is intrusive to users of mobile apps.

Choose wisely.

To minimize the risk for mobile projects, when building APIs you should:

APIs are the foundation upon which modern mobile and web apps are built. They’re not easy to plan and build, and the decisions you make whilst building them will come back to reward (or haunt) you for years to come.

So choose wisely and enjoy the challenge.

In our Android development team, we use the Navy Seals Android Development Process. It includes getting automatic feedback from static analysis tools and running tests using a Continuous Integration server. While Jenkins is a solid tool, it has its quirks. So when Circle CI announced Android support, we decided to give it a spin.

We used Jenkins CI for a while in combination with Github and Bitbucket repositories. Jenkins was installed on a local machine in the company and each time someone pushed to a repository, a web-hook triggered a build. Then Jenkins fetched the current code, built it, ran static analysis and our tests. If there was any problem at all, it notified us via the appropriate Slack channel.

That sounds pretty straightforward, right? Unfortunately, there’s a big difference between how things should work and how they actually work.

Jenkins is a mature piece of software and has a large number of available plugins to make your life easier. However, the UI looks really ugly and a large percentage of plugins do not work as advertised.

This problem is not specific only to Jenkins, but to any self-hosted CI solution. Somebody needs to ensure that the machine is secure because it contains a lot of code that is core to our business. This includes securing access to the machine and regularly updating to patch the latest OpenSSL vulnerabilities.

Security issues are not the only issues you might encounter. In our case, builds started failing across all projects at one point. The disk was full because of all the archived build artifacts and the builds kept failing until somebody found the time to clean up the disk. We ended up buying a larger hard drive to accommodate more projects.

These are not unsolvable or even difficult issues, but they take time to solve – time that we could otherwise spend improving our apps.

In our Jenkins setup, you install all the tools you need to build the app locally on the machine. They are used in the build script when your build is run (think build tools, Android SDK, support libraries, etc.). And when you update your code so that it needs a new version of a tool, you also have to remember to log onto the Jenkins machine and manually install the new version. If you don’t – your build fails.

About ten months ago, Circle CI announced support for Android and iOS projects. Pretty soon, we started trying it out since we weren’t satisfied with our setup. We discovered that it had some great advantages over our old Jenkins setup.

Each time a build is triggered, a new virtual container is spun up. The project GitHub repository is cloned and the circle.yml configuration file in the root of the project is read and used in the rest of the process.

The configuration file is used to:

Unlike Jenkins, which has a rudimentary and cumbersome UI, Circle has obviously put a lot of work into their Web UI because it’s a breeze to set up and use.
Circle CI lists all your GitHub repositories so you can set up CI for your project in just a few clicks. It also automatically adds the deploy key to the repository.

Mail, Slack, Hipchat, IRC.. you name it. There’s also an option to notify you only if the build status changes.

The first container is free, an additional container (two parallel builds in total) is $50 per month. You can compare that to Travis CI, where the lowest tier is $129 per month. For a smaller project, you could probably get away with one container.

All the configuration needed for Circle to run your build is in circle.yml inside your project. When you need to update your build tools, you do it right inside of your project. When you push your code, you do it knowing that the new build tools will be installed before your build is run. Also, if you want to retry any older build, you don’t have to worry about not having the older build tools installed.

When you create a pull request, GitHub displays the Circle CI build status. You can also tell GitHub to disallow merging the pull request if the build was not successful.

Circle CI does not support KVM emulation. This means you can’t use x86 emulators like Genymotion and you’re stuck with arm emulators which take forever to boot. It also needs a small amount of time to spin up a new container – but that’s negligible next to the emulator boot time!

Although we initially experimented with running Android instrumentation tests on the emulator, we are now using Robolectric unit tests and are quite happy with them.

Our typical build on a project with 130 tests takes 14 minutes, but if you’re using the Android emulator, it will take more than 20 minutes.

Circle CI has great GitHub integration. I especially like that it indicates if the tests passed or not for each pull request, so I don’t even need to look at the code if the tests fail. However, there is absolutely no Bitbucket support. As far as I know from speaking to their tech support – there are no plans to implement it in the near future.

We’re still hoping Circle CI might add Bitbucket support one day. For the time being, we’ve relocated some of our Bitbucket repositories to GitHub.

When you use a hosted CI solution, you need to be aware that your code will be downloaded to a server that you do not control. If a security breach should happen on that server, your code may be compromised. If your company has strict security policies, you may not be able to use Circle CI.

There are several commercial CI solutions that support Android, like Travis and Ship.io. However, we’ve found Circle CI to best fit our needs. Travis Android support is still in beta and we haven’t found a simple way to store build artifacts with it. At the time when we were looking for a Jenkins replacement, Ship.io was still in public beta and we liked the Circle CI pricing model better.

I’m sure time did not stand still for Travis and Ship.io, so it might be a good idea to take another look at them. There are also some hosted Jenkins solutions out there if that fits your use case.

Update: Ship.io is shutting down.

The problems we had with Jenkins:

Circle CI solves all these problems for us.

The bottom line is that while any kind of CI solution which helps you code is better than nothing, some are better than others. We found that Circle CI is a better fit than Jenkins for our development process, but something else may work better for a different company.

Thanks to my colleagues Ivan Kocijan and Željko Plesac for reading drafts of this post and giving great feedback!

If you are interested in how our Rails team approaches Continuous Integration and delivery, you can read about it in this article.

Are you using Continuous Integration in your projects? What kind of tools do you use? Let us know in the comments!