I have a messaging system over which I'm sending a set of different flatbuffer tables. The receiver end needs to be able to pick these off the wire and decode/typecast them to the appropriate type.
I can easily send a single type of message and read it at the other end but how do I detect multiple different types of messages from different schema files? Is there a magic number on the message that lets me identify the structure?
You can make the root table contain a union which contains the various message types. Or, if you prefer, you can declare a file_identifier for each kind of FlatBuffer, and identify them that way.
Details: https://google.github.io/flatbuffers/md__schemas.html
Related
https://facebook.github.io/relay/graphql/objectidentification.htm is very clear around what Node is and how it behaves, but it doesn't specify which objects must implement it, or what the consequences are if your object doesn't implement it. Is there a set of features that don't work? Are such objects completely ignored? Not all objects in the existing spec (e.g. pageInfo) implement it, so it's clearly not universally required, but pageInfo is somewhat of a special case.
Another way of thinking about the Node interface is that objects that implement it are refetchable. Refetchability effectively means that an object has an ID that I can use to identify the object and retrieve it; by convention, these IDs will usually be opaque, but will contain type information and an identifier within that type (eg. a Base-64 encoding of a string like "Account:1234").
Relay will leverage refetchability in two ways:
Under a process known as "diffing", if you already have some data for an object identified by ID QWNjb3VudDoxMjM0 (say, the name and address fields), and you then navigate to a view where we show some additional fields (location, createdAt) then Relay can make a minimal query that "refetches" the node but only requests the missing fields.
Relatedly, Relay will diff connections and will make use of the Node interface to fill in missing data on those (example: through some combination of navigation you might have full information for some items in a view, but need to fill in location for some items within the range, or you might modify an item in a connection via a mutation). So, in basic pagination, Relay will often end up making a first + after query to extend a connection, but if you inspect its network traffic in a real app you will also see that it makes node queries for items within connections.
So yes, you're right that pageInfo doesn't implement Node, and it wouldn't really make sense for it to do so.
I understand that in usergrid UI I can create an Individual collection , but it does not allow me to create a collection under a collection. Is there a way of doing that . Otherwise we will be forced to write business logic in the proxy layer which we don't want to do.
With Regards
-S
There is no concept of subcollection, but you can use connections. So you can do something like this:
POST cats/fluffy/hasa/toys/ball
The above would mean that that an entity of type "cat" is connected to an entity of type "toy" that is called "ball" by a connection verb "hasa".
You can also store sub-objects in an individual entity (e.g. full JSON is supported). If you want to describe your use-case a bit more, I can maybe recommend other ways to structure your data.
I'm writing an app that tests some RPCs sent over a tcp transport to some connected hardware. There are approximately 35 different RPCs with varying inputs.
The user selects one of the messages they want to send and a view controller is pushed that asks for input specific to that RPC. The inputs for the RPCs can change based on what the user has done previously during the session. Some common UI objects used would be text, sliders, and pickers.
My question is about code organization. Right now I can think of two broad strategies for implementing this application.
The first is to use storyboards and create a custom view controller for every one of the messages. This is probably the easiest and most understandable, but messiest implementation.
The second is to create a custom view controller that responds to messages to layout input fields and build RPCs. This requires a model backing each of the different types of RPCs and some long case statements to differentiate between the different types.
Does Objective-C have a common design pattern for handling this type of situation?
One nice way of handling this is to use a tableview. Write a cell for each of your possible input types (these might do their layouts in code or be backed by NIBs). Register all the cell types with the table view, and return the ones you need based on the current RPC from -tableView:cellForRowAtIndexPath:.
I'd probably just generate a list of strings that describe the inputs when the view is first loaded with a new RPC, and reference that to figure out which cell is needed for a given indexPath.
Example: I want to use the interface of nsILocalFile in Javascript, how to find the corresponding Contract ID("#mozilla.org/file/local;1")? Is there a map in the source code?
You don't. This isn't a one-to-one relationship between contracts and interfaces but a many-to-many one:
A single component as accessible by a contract can implement multiple interfaces.
A single interface can have multiple components implementing it and therefore multiple contracts.
But, often it is a one-to-one relationship in practice. E.g. if I wanted to find out about what components implement nsILocalFile, I'd search it in the sources, for instance:
MXR: http://mxr.mozilla.org/mozilla-central/ident?i=nsILocalFile&tree=mozilla-central
A glance over the result list already tells me: line 1255 -- let file = Cc["#mozilla.org/file/local;1"].createInstance(Ci.nsILocalFile);
Else I'd have to look at the files the different results link, starting with the .js ones.
Other times, the contract ids are even specified in the idl itself, e.g. in nsITimer.idl (at the bottom).
The most commonly used interfaces usually are also present on MDN incl. contracts, e.g. nsILocalFile.
I am working on a large project at work that requires me to create OData's for a large variety of Remote Function Calls. I was able to work out how to model and create OData's for simple RFCs; however, I am struggling with more complex RFCs that use multiple tables as well as simple exporting and importing parameters.
I want to output these tables as well as the importing and exporting parameters via GetEntity and GetEntitySet with just one call. I have done extensive searching online to find solutions but the best solution seems to be redefining the RFC's or calling the OData multiple times which is not ideal.
Is there any way to combine multiple tables with several entries in the output? When I say output, I am referring to the resulting XML from GetEntity/GetEntitySet.
For example, take the below fake RFC definition that takes a PERNR, and outputs a list of direct reports and a structure of employee details.
IMPORTING
PERNR
EXPORTING
S_EMPLOYEE_DETAILS
TABLES
T_DIRECT_REPORTS
Is there a way to combine the table, structure, and importing parameters into one output?
The first thing to understand is that the OData protocol is not intended to solely work like classical function calls. It is based however on entity/relationship kind of model.
So in your case id sugest to create an entity type named 'Employee' with the appropiate properties of your structure S_EMPLOYEE_DETAILS. With this you can e.g. implement the method GET_EMPLOYEE_ENTITY to retrieve a single instance of an employee via PERNR.
The next thing to do would be to get the direct reports of this employee. Since this is a relation 1:N from Employee to Employee in your case you can create a navigation property called 'DirectReports' with appropiate cardinality. Then in your GET_EMPLOYEE_ENTITYSET you can return the instances of table T_DIRECT_REPORTS (note that navigation property is not empty and you have to read the keys of the parent!).
Once you got this working you can move on to the 'best-practise' and implement the method GET_EXPANDED_ENTITY with filling the expand clauses, which is in my opinion the preferred way as you dont need to implement two seperate methods and is consiered faster as well (if many expands happen).
Both methods of implementation can be called via
GET EmployeeSet('12345678')?$expand=DirectReports