why do you use snake instead of camel case?

How does this work with folly::dynamic? Don't we need to check whether it is a collection and if the field is present in the first place?

camel case

new line missing

We can always iterate in foreach manner over folly::dynamic provided it is an Object or an Array. In the first case the iteration is similar to iteration over dictionary (key-value) pairs and similar to iteration over vector in the latter. I understand there are several places in this code where I assume that a certain key is present or the value under certain key is an Object or an Array. On one hand it would be justifiable to add sanity checks in those places and throw some error/log and return if the condition is not fulfilled. On the other this code is meant to mirror functionality implemented in message-ops-utils.js where assumptions about a presence of a certain key or character ot the value are not additionally verified. Therefore I assumed it might be an overkill to introduce such sanity checks in C++ version of the code. However it is not an issue to provide such checks. @ashoat, @palys-swm what do you think? Can I assume that if presence of a key or value character in notification is not verified in JS then it does not need to be verified in C++?

On the other this code is meant to mirror functionality implemented in message-ops-utils.js where assumptions about a presence of a certain key or character ot the value are not additionally verified.

In our JS codebase, I think these assumptions are generally enforced statically by the Flow typechecker. But I don't think data returned from the server is verified at runtime, so the assumptions made by the typechecker could be wrong.

I think it's probably okay to make these assumptions since we do the same in JS, but I guess it would be better to do some sort of runtime checks when the data is received from the server. I guess that's probably outside the scope of this diff?

I honestly don't feel too strongly, open to other perspectives.

I wouldn't say it is out of the scope of this diff. Instead of optimistically accessing keys we could use if statements or ternary operators to check for presence of given key or whether value we expect under the given key is indeed and Object or an Array so that it can be iterated over. The only difficulty I see in performing runtime checks is how should we react when those checks fail? Probably we should throw an error or log error message and return, but how do we make sure that corrupted notification is re-send in a correct form, or is at least downloaded in its correct form upon app launch?

It may be good to create a helper function for this. It would assign a value if it is present or throw/do sth else when it is not present.

I am about to make some of those functions private since they may throw exception that will be handled in public methods of this class. Another reason to have this functionality contained within a class is that we are going to use them in Java on Android in CommNotificationsHandler.java

Would be nice if there was a way to just tell CMake to recursively include a directory and all of its subdirectories. @karol-bisztyga found something like this, but not for include_directories I think. @jimpo, any ideas?

Ping on this @marcinwasowicz @karol-bisztyga @geekbrother @jimpo any way to recursively include a directory in CMake?

Something like

file(GLOB_RECURSE SOURCE_CODE "./src/*.cpp")

works for finding files but here we need to find directories here.
In services, we explicitly add every subdirectory. I'm not sure if there's a solution to do this recursively. Maybe there is but I'm not aware of it.