We can decide to build an app for HarmonyOS in the coming years, if the OS gains global popularity.
At the moment, since HarmonyOS Next does not exist yet, and since Wikipedia is blocked in China, there is very little reason to do this.

My (totally unbiased) preference would be option 2: use the id value from the existing campaign structure.
This may add a bit of complexity to analytics, since the id might not be exactly the same as wmf_source, but would be much simpler for us.

Rough outline for testing and integrating with the new endpoints:

Thanks for the ticket, but this is expected behavior -- when you tap the Bookmark icon, the article is automatically added to your default Saved list, and when you tap "Add to list", and select a different list, the article is moved (not copied) to that list.

@BPirkle OK! I made a branch of the app that communicates with all the new endpoints for reading list management, and everything works great so far (in the context of the new MW REST system).

In T365535#9820086, @daniel wrote:

Intersingly, the RBServiceError class already has the errorKey and messageTranslations fields. How are they being populated currently?

In T365535#9819260, @BPirkle wrote:

@Dbrant , question that I didn't think to ask during our synchronous meeting: are extraneous fields problematic for the app? In other words, if the error response json had the values from both the RESTBase error AND the MW REST error, would the app be happy?
I'm not saying we would (or wouldn't) do that, just confirming what the behavior would be.

👍 good catch!

There was indeed a very sneaky issue that affected playback of some specific types of audio files. Solution incoming.

Yes, it should start handling the links correctly once the post-creation work is done.
And the dtp language itself should be selectable within the app in the next update, when we run our script that refreshes the list of languages known to the app.

The gateway API issue was fixed, so we can now continue testing the Lift Wing model. Here is an APK for anyone else who would like to try it:
https://github.com/wikimedia/apps-android-wikipedia/actions/runs/9305222379/artifacts/1552968133

In T343123#9846155, @klausman wrote:

Hey Dmitry, Hnowlan has added a workaround to the APIGW configuration (see T365439#9846068 and https://gerrit.wikimedia.org/r/c/operations/deployment-charts/+/1037449), can you confirm this works for your usecase now?

This is intended behavior. A different language version of an article is a different article, and must be saved separately.

@HNordeenWMF This is easily done, but it actually conflicts with a minor bit of UX that we have currently, namely: when you select the checkbox to "add the transaction fee", we actually update the text field with the total amount to include the fee. But now, if the transaction fee is dependent on the amount, updating the text to include the fee becomes impossible.
Would it be acceptable to no longer update the amount that's in the text field to include the fee? (This would actually also bring it more in line with behavior on Web.)

Putting this in Blocked for now:
I found an issue at the gateway level (T365439) that makes it difficult for us to query the URLs of Lift Wing services without an ugly workaround in our network layer.

I'm checking out the Lift Wing API to generate article descriptions, and I see the URL path contains a colon : character. The problem is that our native network stack always urlencodes colons, but when I hit the same API path with an encoded colon (%3A) it returns 404.
Is this expected? Can we make the API accept a urlencoded path?

and https://gitlab.wikimedia.org/repos/data-engineering/metrics-platform/-/merge_requests/53

(is there a gitlab equivalent of GerritBot for linking tasks?)

@cjming Thanks for making this task!
If I may propose another acceptance criterion that would make the library even more robust:

• If stream config has not been received yet, then events should be enqueued, instead of dropped.

This could be done by having another (secondary) queue at the front of the submitMetricsEvent() function that queues up events in case the stream config hasn't been loaded, and then drain the queue upon receipt of stream config.
We could also refactor the current (single) queue to accept all events, regardless of the presence of stream config, and then upon emptying the queue perform the logic of filtering events that should/shouldn't be sent.

I believe I may have an answer to the question of missing events:
TLDR: a race condition in the Metrics Platform client library.

Cleaning up some very old and/or no-longer-relevant tasks.