Is it possible to lookup elements by key with the object API just like it's possible in the non-object API with the "LookUpByKey" method?
I can't find any method that seems to do that.
Am I supposed to implement a binary search by myself on the vector?
Is the vector assumed to be already sorted?
I think you need to use mini-reflection or full reflection for this task.
You can read more about reflection in the docs or see an example where it's used in their testing code.
Here's a nice tutorial by jorenjoestar from someone using reflection that I found helpful myself.
Also the vectors are not assumed to be sorted but you can pre-sort a vector and set the flatbuffer contents to that sorted vector.
Related
I did my first experiment with recoil, building an editable table. Each cell has an atom which stores its row, column, and text value.
The way I built this was by
initializing each cell's atom into a dictionary (just a plain object), with keys in a format of [column]x[row]
I then iterate over these keys in the Table component, and pass only the key to each Cell component
The Cell component uses useRecoilState and find its specific Atom by accessing the main dictionary using the key it got passed as a prop.
Now, it seems to me that this use case (creating thousands of related atoms with the same shape) is what atomFamily is meant to make easier, but I don't understand how to use it in this way, where you initialize each atom with a specific value.
And, besides that, I don't understand what is the advantage of using atomFamily over storing a collection of atoms. I understand there is memoization involved, but I don't understand what is getting memoized other than, if I am reading correctly, the ability to recall a specific atom by calling the function again with the same id, which would get you pretty much the same behavior I'm getting with a dictionary.
There is very little difference: if you want to manually memoize and manage your own collection of atoms, then you certainly can. atomFamily is essentially just sugar for that: it handles the memoization for you, so all that you have to do is use a unique key to access each atom. Verbatim from the documentation for atomFamily:
An atom represents a piece of state with Recoil. An atom is created and registered per <RecoilRoot> by your app. But, what if your state isn’t global? What if your state is associated with a particular instance of a control, or with a particular element? For example, maybe your app is a UI prototyping tool where the user can dynamically add elements and each element has state, such as its position. Ideally, each element would get its own atom of state. You could implement this yourself via a memoization pattern. But, Recoil provides this pattern for you with the atomFamily() utility. An Atom Family represents a collection of atoms. When you call atomFamily() it will return a function which provides the RecoilState atom based on the parameters you pass in.
As far as examples for how to use atomFamily: beyond the documentation linked above, there are lots of existing questions and answers on Stack Overflow which already cover exactly that. Here are a couple which I have answered previously:
Dynamic atom keys in Recoil
Looking for a pattern to normalize state in Recoil without losing the benefit of Suspense
I have been using Bytebuddy to monitor application behaviours, and I would like to check whether an array field of one of application classes is updated before executing a particular method. I have read Bytebuddy documentation and stack overflow questions and have found some useful documentation of how to intercept field accesses using MemberSubstitution.
However, because the field I'm interested in is an array, onWrite and onRead events in MemberSubstitution seem irrelevant.
Is it possible to track updates on an array field using Bytebuddy?
No, unfortunately no. Arrays are read onto the stack. Then only afterwards elements are accessed by index. This can be preceded by arbitrary instructions and is not interceptable individually.
I'm currently struggling with the experimental KXS-properties serialization backend, mainly because of two reasons:
I can't find any documentation for it (I think there is none)
KXS-properties only includes a serializer / deserializer, but no encoder / decoder
The endpoint provided by the framework is essentially Map<String, Any>, but the map is flat and the keys already have the usual dot-separated properties syntax. So the step that I have to take is to encode the map to a single string that is printable to a .properties file AND decode a single string from a .properties file into the map. I'm generally following the Properties Format Spec from https://docs.oracle.com/javase/10/docs/api/java/util/Properties.html#load(java.io.Reader), it's not as easy as one might think.
The problem is that I can't use java.util.Properties right away because KXS is multiplatform and it would kinda kill the purpose of it when I'd restrict it to JVM because I use java.util.Properties. If I were to use it, the solution would be pretty simple, like this: https://gist.github.com/RaphaelTarita/748e02c06574b20c25ab96c87235096d
So I'm trying to implement my own encoder / decoder, following the rough structure of kotlinx.serialization.json.Json.kt. Although it's pretty tedious, it went well so far, but now I've stumbled upon a new problem:
As far as I know (I am not sure because there is no documentation), the map only contains primitives (or primitive-equivalents, as Kotlin does not really have primitives). I suspect this because when you write your own KSerializers for the KXS frontend, you can specify to encode to any primitive by invoking the encodeXXX() functions of the Encoder interface. Now the problem is: When I try to decode to the map that should contain primitives, how do I even know which primitives are expected by the model class?
I've once written my own serializer / deserializer in Java to learn about the topic, but in that implementation, the backend was a lot more tightly coupled to the frontend, so that I could query the expected primitive type from the model class in the backend. But in my situation, I don't have access to the model class and I have no clue how to retrieve the expected types.
As you can see, I've tried multiple approaches, but none of them worked right away. If you can help me to get any of these to work, that would be very much appreciated
Thank you!
The way it works in kotlinx.serialization is that there are serializers that describe classes and structures etc. as well as code that writes/read properties as well as the struct. It is then the job of the format to map those operations to/from a data format.
The intended purpose of kotlinx.serialization.Properties is to support serializing a Kotlin class to/from a java.util.Properties like structure. It is fairly simple in setup in that every nested property is serialized by prepending the property name to the name (the dotted properties syntax).
Unfortunately it is indeed the case that this deserializing from this format requires knowing the types expected. It doesn't just read from string. However, it is possible to determine the structure. You can use the descriptor property of the serializer to introspect the expectations.
From my perspective this format is a bit more simple than it should be. It is a good example of a custom format though. A key distinction between formats is whether they are intended to just provide a storage format, or whether the output is intended (be able to) to represent a well designed api. The latter ones need to be more complex.
According to Apple documentation it is possible to pass CFDictionaryRef auxiliaryInfo when creating/beginning a transparency layer, but I cannot find any documentation or examples on what key-value pairs might be appropriate for this or how it might be used. Can anyone shed light on this or should it always be null?
The auxiliaryInfo dictionary is intended for future use to be used for layer options, however currently it is not being used in the Quartz 2D API. So for now it should always be NULL for this function.
This is really a three-part question, but I've answered the first question myself:
I'm working on the iPhone, with many objects (up to 200) on the screen. Each object needs to look if it's overlapping other objects, and act accordingly. My original naive implementation was for each object to run through the list of each other object to check their bounding boxes (using CGRectInsersectsRect).
So my question (and answer) is what's a better method? My new implementation is to sort the array every frame using an insertion sort (since the data will be mostly sorted already) on the y-position of each object, then check only the nearest object on either side of the one searching, to see if it's in range vertically, then check horizontally.
First question: Is insertion sort the method I want to use for an array of objects that tend to move around randomly but only to a small extent so they mostly stay in order based on the last frame? Also: what sort algorithm does the NSArray use when I call
- sortedArrayUsingSelector:
I would sort of assume that it uses a quick sort, since it's the most useful in the general case. Does anybody know if I'm wrong? Does anybody know if I can change the sort method or if I will have to write my own sorting function?
Second question: is there a function for retrieving items from a sorted array using a binary search, rather than the naive approach that I assume is used by
- indexOfObject:
or would I have to write my own?
NSArray uses many different data structures internally depending on how many objects are in the array. See a Peter Ammon blog entry for more information. But basically this means you can't expect a certain kind of sort to happen. Sometimes it is worth it to write your own array implementation using C arrays so you can control the sorts yourself.
There are definitely much faster ways to implement collision detection. Look into Bounding Volume Hierarchies like KD Trees or similar.
As far as I know indexOfObject: is the only way, but it's potentially not as dumb as you think. Everything is hashable for NSDictionary so they can use some of those smarts in NSArray.