If I create a top level timeline card I can create a single level of nested cards by giving them the same bundleId as the parent.
Can I create a second level of nesting?
Top level timelineItem
- 1st level child timelineItem
- 1st level child timelineItem
- 2nd level child timelineItem
- 2nd level child timelineItem
Nope. That's not a feature supported by the Mirror API right now.
If you're interested in doing this, I recommend you file an enhancement request on the API issue tracker.
Related
How to separate data fetching and presentation layer when there are nested deep levels.
For example, I need to build a tree-like comments system like HackerNews or Reddit.com, which is collapsable.
I want to fetch the data in a container then use it in the presentation layer. I use a recursive Comment component design. Since the comments contain children comments I need to fetch data in nested child component too. So aside from fetching data in parent I add a callback in each Comment component just to set the states for each Comment just for iterating the children comments.
I find myself muddling up states very quickly when I add the collapsable functionality because I need to calculate and store the children count for every comment.
Any quick solution for that?
In RPL (Routing protocol for low power and lossy networks) .If there is one node want to send data-packet to its parent and candidate parents. how we can select multi preferred parents instead of one preferred parent. how can i do this ?
kindly feed back plz..
In Component based game engine, I have trouble when it come to relation between game objects / components.
Where to store the relation , and how to delete them?
To keep it simple, here is an example.
A Gradius-clone game consists of 2 types of game object:-
Rocket = Main Body Component + Turret Component
Floating turret = Turret Component (alone)
The component detail are :-
Main Body Component = one physical body + one graphical body
Turret Component = one physical body + one graphical body
Turret Component is designed to have a relation (physical constraint or ownership) with to Main Body Component.
There is a requirement that the relation must be removed BEFORE both component.
For example, the relation in this case also contains physical constraint implemented by external Physic Library, e.g. Bullet Physics.
These are quite an example-specific description, provided just in case ....
Steps to delete Rocket have to be in this order :-
delete constraint
delete Main Body Component and Turret Component (any order is ok)
The relation should also be removed when a Main Body Component is deleted, leaving Turret Component alone, so let it become Floating turret.
Where should the relation be stored? (All seem ok, but related to next question.)
inside a new component in a new dedicated game object (new entity)
inside a new component in the same entity as Rocket
inside a new manager system that keep a list of this specific kind of relation
How should relation be deleted? (Both seem to be bad ideas.)
create a flag to check for a impending deletion of Main Body Component or Rocket, then call a new dedicated system to delete relation just before delete others component, it must be called before other manager systems every time step.
let's other existing manager call a new dedicated system when it want to delete Main Body Component or Rocket
I expected answers for general cases where there are a lot of types of relation. (between Game Objects or Components)
Edit 1: The proposed solution about making ownership and adding code in Rocket's destructor directly is quite against Component Based design.
It will make the three components (include constraint) very couple.
Furthermore, components should not have non-trivial function.
I believe the destructor is one of them, that should be avoided.
(I once has bloating destructor of some objects, it destroy all good modularity.)
In your example of the Rocket game object, the relation is an ownership and should be kept in the Rocket. If your game engine architecture allows it, the relation can be deleted by a destructor function in the game objects called by the manager system prior their deletion.
EDIT:
If you don't want the objects or components to have any knowledge of their ownership or relations, I think the best choice would be to keep a list ( as you suggested) of the relation with a reference to the owner of the relation. That way you can check the list first, to see if your game object (Rocket) can be deleted or if it has any relation/s to delete first.
If two timeline items are inserted with the same sourceItemId the mirror api creates a second timeline item and does not automatically update the first. Is it correct that I must store the mirror api timeline id after insert and map that to the sourceItemId on creation and then use update or patch to modify the item later? How are others maintaining consistency between the mirror data and app data?
The sourceItemId is fully in your control and there might be use-cases where you want multiple timeline items with the same sourceItemId(for example for multiple comments referring to the same article) therefore the Mirror API doesn't check this parameter.
Mapping timeline ids to your sourceItemId in your datastore is probably the best and most efficient solution.
Alternatively you can use the timeline.list method, which allows searching for all items with a specified sourceItemId, and update the existing timeline item when found, or create a new one otherwise. https://developers.google.com/glass/v1/reference/timeline/list
With the currently rather limited API quota you will want to avoid the second solution though.
I have an application that was coded with JSPs and now we are in the process to migrate to the pages to Facelets.
One of our PhaseListeners is manipulating the component tree, because it needs to find out some components in the tree and extract some of its values. But with Facelets, UIViewRoot does not return any children.
How can I get the same type of functionality with Facelets?
Thanks in advance,
Paulo
Retrieving UIViewRoot with this line should work:
FacesContext.getCurrentInstance().getViewRoot
My guess is that you are trying to manipulate the component tree in the first phase of JSF lifecycle. (link)
The first phase consists of retrieving the view, that is, the component tree, for the requested page. Therefore you can just explore the component tree after this phase has completed.
Use
phaseEvent.getPhaseId()
to see which phase you are working in.