Creating my first own iOS app

As teased in the last blog post I was testing quite a few music streaming services.

The problem

One problem I had, was to share songs that I liked with my kids. Yes, it happens from time to time that I like a song that my kids also like. More often than not, they don’t share my opinion on a particular song, but I keep trying 😅
The family completely refuses to switch to anything but Spotify, so I had to find a way to share songs with them that I found on other services.

The solution

There is that cool web service called Song.link that allows you to turn a music streaming service link into a link to a page that contains links to all the other services that have the same song.
Sadly they don’t have an app and only a guide for how to create a shortcut on iOS to use their APIs.
I found an open source Android app that provides a way to use the Song.link API to create these links. They did not offer a way to share the link to the overview page but was meant to directly turn the link of streaming service A into a link to streaming service B.
My first reaction was to fork this project and add the missing feature (including creating an upstream PR).

But I was not 100% happy with this app, so the expected thing happened that happens if you leave a software developer with a problem alone and give him a free version of GitHub Copilot: I started to write my own Flutter app.
This provided the perfect opportunity to create a quite small Flutter app from scratch putting GitHub Copilot to the test and to try out some new Flutter packages.

And back to Google Pixel

After a few months with my Samsung Galaxy S24 Ultra I found a good offer and jumped to the Pixel 9 Pro.
I hope that this “oh this other phone looks nice, too” spiral that affected me a few years ago is not coming back, but I have a few good reasons for this switch 😅
Let me explain how I excused this switch to myself:

Size

Phones nowadays are big.
Much bigger than in the past. What is considered a “normal” phone was a “Max” 7 years ago.
Today’s “Max” phones (like the S24 Ultra) are huuuuge. The pockets of my trousers barely cover the whole phone and god forbid if you need to bend forward to close your shoes.
The only reason for me selecting the Ultra was the camera system. Sadly Samsung still only cramps the best camera they have to offer into the “Max” phone.

Big camera, “small” phone

Then - shortly after I bought the S24 Ultra - Google decided to release the Pixel 9 (what a surprise 😄).
This time they decided to give the “normal” Pixel 9 Pro the same camera capabilities as their “Max” variant.
I was jealous but resisted to immediately jump over to the Pixel.

Raving reviews

Then the reviews for the Pixel 9 Pro appeared.
Great camera, great battery life (for its size), OK performance.
The price for the Pixel 9 Pro (more expensive than the S24 Ultra at that time) was the only thing holding me back.

MediaMarkt offer

Then MediaMarkt had an offer: Pixel 9 Pro 256 GB for €949. Additionally, you get access to the Google trade-in program offering additional €150 on top of what they are willing to pay for an old Pixel phone.
So I looked into my drawer and decided that the Pixel 7 has to go 😀
The current value of the S24 Ultra (with some margin), the additional trade-in bonus, the value of the Pixel 7 and the MediaMarkt offer allowed me to switch without loosing money (I even made a slight plus but lost the Pixel 7).

A few updates

I’m still alive

It’s been a while since my last post.
The reason is really simple: there was nothing happening that I felt was worthy to share through a dedicated blog post, so I decided to not publish.
I’m still alive and still planning to share stuff on this blog.

dart-apitool updates

There were a couple of small updates for dart-apitool that were mainly driven by remarks or issues from its users.
A couple of changes:

Force flutter command

It is now possible to force dart-apitool to use the flutter command even if dart would work as well (if the package doesn’t have a Flutter dependency)
The new option to enable this behavior is --force-use-flutter

Default for --check-sdk-version changed

We realized that there is no situation in which changing the SDK constraints of a package leads to breaking consumer code.
Pub will make sure that any incompatible packages are excluded from the dependency tree resolution algorithm.
This means that a package that increases its minimum required SDK might not be usable by a consumer still using a lower SDK, but this consumer just continues to use the package that it used before.
Therefore, we changed the default for this option to off. At the same time we made sure that changing the SDK type is breaking regardless of the value for --check-sdk-version.

Add “missing exports” information to the extract command

Monitor progression

Ultra wide monitor

For years was using a 34” UWQHD monitor from LC-Power, LC-M34-UWQHD-100-C. It was a cheap monitor, but it worked, and it was very wide.

While really getting used to that horizontal space I also was not really happy with the overall quality (picture and build) so one day in 2021 I decided that I need to upgrade my monitor.

At that time I had my 13” MacBook Pro and while the resolution of the monitor was OK it was not really ideal for macOS. I had to use the 100% size mode which is a bit too tiny for my taste. But the next natively supported resolution was just way too big.
There were some tools out there that tricked macOS into rendering a too big picture and then scaling it down to the resolution of the monitor, but those tools need to create a separate virtual screen buffer consumed quite a big portion of my RAM, so I stayed with that 100% scaling.
I used a CalDigit docking station to only plug one cable into my MacBook and have all the periphery connected which I really got used to and didn’t want to miss in any new setup.

Then I discovered the Dell lineup of monitors and saw an Ultra Wide monitor exactly the size of the LC-Power (34”, same resolution, DELL U3421WE) but with much better picture and build quality.

The monitor also said that it has a docking station built in meaning I could get rid of that CalDigit as well, so I ordered one to test.

Once it arrived, and I set it up I was really happy with the picture quality and the overall build quality. The main issue was that I had to decide - in the on-screen menu - if I want to have a higher resolution / refresh rate or higher USB-C speed 🙁
The second - much more critical - issue was that the built-in network adapter seemed to not be compatible with our network system (AmplifiHD at that time, but that’s another story) meaning the moment I plugged the network cable into the monitor the whole network stopped working a few minutes after. This has caused quite a few complaints from family members until I found the cause of this issue 😅.

via GIPHY

Given that I was really happy with the picture quality and because there were no real alternatives (higher DPI) I decided to keep it and live with using the CalDigit Docking station for now.

dart_apitool updates

Recently dart_apitool got 2 significant updates. Thanks to all the contributors that made that possible.

1. More robust preparation step

dart_apitool makes local copies of the packages it analyzes

When dart_apitool analyzes packages it has to do some preparation steps in order to make sure the analysis run doesn’t have any issues:

1. it has to remove any analysis_options.yaml because this file can limit the scope of the analyzer.
   This is OK if you want to e.g. exclude files from linting but dart_apitool needs to see all of your files to create a complete model of your public API.
2. it has to remove an example project as it needs to run pub get to get the dependencies prepared and up-to-date for a successful analysis run.
   Some packages have examples bundled with them that sometimes reach into packages via relative paths that live outside the package directory. Those paths are valid inside the package’s repository but are not valid outside of it. A dart_package bundles those examples which means they also live inside the downloaded package and might have invalid relative path dependencies.
   As dart_apitool is not interested in those examples it can just remove them from the package directory and run pub get to get the dependencies.

To not interfer with a local copy of the package (in the pub cache or on disk) dart_apitool makes a temporary copy of the package before manipulating it.

why this is complex and created an issue

This works really well. In the past there has been a special issue if a package was referenced on disk and contains relative path depdendencies. To solve that issue dart_apitool had a functionality to analyzse those path dependencies to determine the directory structure it needs to copy to the temporary directory making the relative path dependencies still work.

In the meantime dart (or better: pub) has a new feature: pubspec_overrides.yaml.
This is a separate file that can be used to override dependencies in a pubspec.yaml. As dart_apitool only looked into the pubspec.yaml it didn’t see those overrides and therefore didn’t know about the relative path dependencies that might be defined in there.
A potential solution to that would have been to also parse the pubspec_overrides.yaml file and take the dependencies defined in there into account.

Minimalistic Text will be unavailable in the Google Play Store

This is a short notice to inform you that Minimalistic Text will be unavailable in the Google Play Store from September 1st, 2023.
The reason for this is that Google will increase the target API level restrictions for already existing apps. Till now those restrictions only applied to new apps or app updates but beginning of September they will also apply to already existing apps.
In practice this means that apps will only be visible by devices that still use the Android version that matches the target SDK version of the app.
For Minimalistic Text this means that it will only be visible by devices that still use Android 9 or older even though it technically would work on newer Android versions.
As the amount of changes that I would have to do in order to comply with the newer API level requirements and the fact that the core rendering part of Minimalistic Text uses Android APIs that change behavior when switching the target API level, I decided to not update the app anymore.

To still provide a way for users to download the app I will provide the APK file on my website.

I’m sorry for the inconvenience this causes.

Dart_apitool got an update!

The recent weeks I was working a bit on dart_apitool.
The major topics were:

Missing export detection

The way Dart allows to define the public API of a package can lead to situations in which the consumer of the API is able to receive an instance of a certain Type but can’t refer to that type directly (e.g. to define a variable or a parameter of that Type).

Let’s imagine a very simple dart package:

- lib
    - some_package.dart
    - src 
        - some_interface.dart
        - some_interface_impl.dart
        - used_type.dart

some_package.dart

export 'src/some_interface.dart'
export 'src/some_interface_impl.dart'

some_interface.dart

#import 'used_type.dart'

abstract class SomeInterface {
    UsedType doSomethingAndReturnInstance();
}

Struggles with the Dart type system

How it began: dart_apitool bug fix

It all started with a bug fix in dart_apitool.
The bug was that dart_apitool detected a breaking change on any parameter type change. Most of the time this is correct but consider this change:

/// version 1
void someMethod(String someParameter);

/// version 2a
void someMethod(String? someParameter);

/// version 2b
void someMethod(Object someParameter);

Here the type of the parameter gets changed but in a non-breaking way.
Any already existing call to someMethod will work with version 2a and version 2b.
The reason for this is that widening the type makes the old type part of the supported type space for that parameter.
Of course this is only valid for types passed in (which is the case for this bug as it describes method parameters).

So the goal was clear: dart_apitool has to check if the old type is assignable to the new type to decide if that change is a breaking change or not.

dart_apitool goes bmw-tech

Today I have some exciting news to share!

Dart_apitool has been transferred to bmw-tech. The repository as well as the package on pub.dev are now under control of the BMW open source organization.

“Why?” You may ask

There are two major reasons for that move:

1. The need arose at BMW

Dart_apitool has been born out of a need in the “My BMW” development organization. The need for a tool that automatically can check correct semantic versioning of packages to avoid creating a mess when modularizing the app.
Puzzled by the realization that no such tool existed I took this as a challenge and made the development of dart_apitool my evening pet project.

2. BMW is the only user that I’m aware of

Besides not getting much traction in the Flutter community dart_apitool is used internally at BMW and already got some contributions from BMW colleagues.

I’m not sure why there is a lack of community traction. I can imagine those reasons:

dart_apitool improvements

There has been some new development in dart_apitool.

I got some feedback from our internal “My BMW” app teams and from the Flutter community so dart_apitool has received some extensions, improvements and fixes the last months: