Posts

As I wrote in my previous post, I have a strong preference towards automated acceptance testing on a service-level. So, when I recently faced a need of creating a Go API related to file management that uses GCS as a storage, I started looking for some way to test it this way. Unfortunately, Google doesn’t provide any simulator for GCS similar and there is also no the-one-to-rule-them-all tool such as Localstack, which I’ve been successfully using for years working with AWS services. I found fsouza/fake-gcs-server good enough and quite popular, so I started with that. Although, there are some samples in the project itself and a couple of blog posts how to start using it, I had to solve a couple of issues, which I think can be interesting, if you’re working with this tool in your Go application.

This text will be rather reflective than instructional, which can be surprising compared to other articles on this blog. However after almost 7 years without any new text, this shouldn’t be any shock, even if you - somehow - managed to follow me here ;-)

In my previous post I showed how to introduce search as type behavior into Xamarin.Forms app with standard Forms Behaviors.

Let’s see how to do it in other, more declarative and configurable manner, using Reactive Extensions (Rx) instead of Task and CancellationTokenSource.

Search as type functionality is quite often seen on the web as well as in mobile apps. Let’s see how to make it work in Xamarin.Forms.

Detecting on-screen keyboard toggles and proper handling of such changes can be quite tricky. Android tries to deal with those events on its own but its behavior is often far from perfect. iOS, on the other hand, leaves all the work to an app developer. Both approaches have its advantages and disadvantages but sooner or later each mobile app dev will have to face this problem.

Today’s mobile apps are rarely created as text-only. Most of them needs at least in-app icons for toolbars. In many cases you can find graphics for mobile platforms as ready to use resources on the Internet, i.e. Material Design icons. Sometimes they are prepared by graphic designers specially for your apps.

It’s very common to have multiple versions of the app during development - i.e. stable beta and store/production or alpha that contains the latest changes. Managing application configuration for multiple versions might be confusing when it’s not carefully designed and setup with the build process.

In last post I described how to cope, in some extent, with different pace of delivering mobile app versus it’s supporting backend. The article also provided a simple hint for speeding up the mobile app development by introducing mocks instead of the external network services.

Modern mobile apps are rarely developed as offline-only. They typically communicate with backend services that feed them with data, keeps in sync with their web equivalents or allows for various external integrations. The backend part is most often developed by different teams in their own pace. The mobile part can be often developed faster thus it waits for the full integration.

XAML compilation is (or at least should be) one of the default optimisation steps in Xamarin.Forms app development. It really speeds up the app especially on Android. Sometimes however it can cause some nasty errors like this one: