Summary:
Even with batching, updates can get split in half due to fact that each litho view has its own independant throttle. Eventually they will drift and and a traversal will get scheduled past the current frame for some of the views. It results in artifacts in the visualiser and will make time travelling wonky
The
Reviewed By: lblasa
Differential Revision: D42606932
fbshipit-source-id: c4cdf729302a380928b4d8720a59d5f7f6ff645a
Summary:
This is needed in preperation for the next diff where we will introduce an observer per litho view. Without batching we end up with really poor performance for a few reasons:
1. There are some operations on the desktop plugin that are o(nodes) so even sending small batches
2. Flipper isnt really a high performance message bus, it seems to prefer fewer larger messages
3. Queuing time on the client builds up as you spend more time waiting on the socket
In a future diff will address:
The name of subtree update event. It should probably be called something like FrameUpdate since they are always full frames
The performance monitoring, will more to timing methods and summing the result rather than the current appraoch of time markers
Reviewed By: lblasa
Differential Revision: D42453229
fbshipit-source-id: eda9830b4420e82874717cc69b241e1689f20029
Summary: We have gotton concurrent modification crashes from this
Reviewed By: lblasa
Differential Revision: D42343224
fbshipit-source-id: 9cf4046da63d40cbe6632c3ae24d95abd21081ba
Summary:
This plugin is rarely used and would need to be re-worked to work in a world where ComponentTree is not the only way of rendering a Litho hierarchy.
Deleting for now for simplicity
Reviewed By: adityasharat, passy
Differential Revision: D42573698
fbshipit-source-id: 0d9cd713b668e6fc79cd5cddcdcb9f24ed98f927
Summary:
I created a separate folder under src called facedbook, which
1. isnt synced to github
2. isnt build by gradle
I also needed to exclude the file with the duplicate symbol from buck. I seemed to have to move both the src/facebook and src/main under one buck file to get the exclude to work
Reviewed By: lblasa
Differential Revision: D41612114
fbshipit-source-id: a8386e1b1eabdeca2a800d98d8732b2ca694836b
Summary:
This is temporary solution to get to parity with the old plugin. In future would like to make this more flexible on the desktop side
Additionally getData was renamed to getAttributes for consistency
Reviewed By: lblasa
Differential Revision: D41845248
fbshipit-source-id: 50e94a7712f5d42938229134e212cef5d379475d
Summary: This is obsolete and maintaining it as the protocol changes no longer makes sense
Reviewed By: lblasa
Differential Revision: D41845247
fbshipit-source-id: c4ead597ca66223ccfa091ac79a6a80784a3c8e4
Summary: we had special handling previously for nested scrollview and we previously used the indirect approach of asking for the local visible rect. New approach is to get the scroll x from the parent and apply it, will work for all scrolling view and it is a lot clearer what the intention is.
Reviewed By: lblasa
Differential Revision: D41772106
fbshipit-source-id: 04b5e68ecabd70548e788ed18423a360ce6c3fa7
Summary: On messenger they use fragments heavily and for navigation. The hide some views via the fragment but we were using that so we saw a lot of overlapping boxes. Ive added a check for if the fragment isVisible as well as exported some more fragment state
Reviewed By: lblasa
Differential Revision: D41800223
fbshipit-source-id: fde33c7542f5fa98d8b98e0722d4292f2d1b67d0
Summary:
The previous approach was to append any 'extra/floating' root view to the end of the childrens for the application descriptor. But the active child was always the last view so if there was a 'floating' decor view with no activity it would always be the active child, even if you opened a real activity from it. This was possible to do in FB4a and you could get into a situation where you couldn't see the top most activity.
New approach is to only iterate the root views from the resolver since it contains everything and map to activity if possible.
Reviewed By: lblasa
Differential Revision: D41731951
fbshipit-source-id: 9ef3fcfdaa41e9b07606ca6781cf22482b54e072
Summary:
The root view resolver will always find all root views but there was a bug in the listrootviews method. The code was very complex and most of the code seemed to be unneeded. Its now working. The listrootviews method now just returns teh contents of the observable array.
The reason we needed this is that Certain activities dont seem to tracked by the listener we add to `registerActivityLifecycleCallbacks` Its as if there is a floating decor with no activity. One example in FB4a is clicking on a notification in the notifications panel
Reviewed By: lblasa
Differential Revision: D41522791
fbshipit-source-id: b49b0104ddf758f097e1fd3f9ac6588de2d3646e
Summary:
Although conceptually it made sense, it creates an issue with registration.
### Let me explain
Effectively, as an engineer, what constitutes static and dynamic metadata and how can I ensure that is treated as such?
It may be trivial to answer those questions but there was a fundamental assumption for static metadata that no longer holds true. Static metadata was registered when descriptors were first referenced, which most of the times happens when added to the descriptors registry.
This used worked fine until we introduced the concept of deferred attributes.
Deferred attributes, even though static, may register its metadata only when requested to.
The issue is even more fundamental as not all the objects that declare static metadata will be loaded into memory by the time the plugin is connected and sends this.
### Solution
To simplify, as the concept was never really used, there's only metadata.
There's only pending metadata which is metadata that is yet to be sent to Flipper Desktop.
Reviewed By: LukeDefeo
Differential Revision: D41614186
fbshipit-source-id: 85d62eeff81ff22ae6e969d7b5aed8628b336258
Summary: Global Id is stable as the component is rerendered. It is not stable if the whole component tree updates so we might want to deal with this in the future
Reviewed By: lblasa
Differential Revision: D41581346
fbshipit-source-id: 0c2834ba452ddcfc3e0a7392672825fc040901d9
Summary:
Attributes Inspector didn't have support for inspectable arrays.
This change addresses an issue with the inspectable itself and adds basic support to it in the visualiser.
Reviewed By: LukeDefeo
Differential Revision: D41522879
fbshipit-source-id: f9cad42470541039c8157477b0fe9bc58f18f1ba
Summary:
There was an issue whereas snapshots were not properly rendered on retina devices.
After running a few tests, the issue seems to be solved by changing the snapshot format from jpeg to png.
Reviewed By: antonk52
Differential Revision: D41520939
fbshipit-source-id: 1563fe89162e41f71418357a7e58caaf46581f04
Summary:
Before this change, color inspector used a color picker that showed: color, rgba, hex.
The problem is that engineers have to click on it to see these values.
This change leaves the picker as is, but presents both hex and rgba inlined within the inspector thus avoiding extra interactions.
Reviewed By: antonk52
Differential Revision: D41495740
fbshipit-source-id: c8af01e3060d2e6725295418293b1e30679c1b1f
Summary: Due to litho component instances being immutable we are able to process them later if we hold on to the instance. We have added a Maybe deferred type which sort of resembles a Monad. It wraps a value which may or may not be calculated later.
Reviewed By: lblasa
Differential Revision: D41474251
fbshipit-source-id: 2ba6e688518dba55cf4aa5ba53f390a92cf0921f
Summary:
Enumeration used to be a type containing a single property value of type string.
The InspectableEnum is a type that had an Enumeration value and possible values.
As we removed possible values from the enum value, this structure no longer serves its purpose.
Reviewed By: antonk52
Differential Revision: D41400874
fbshipit-source-id: e5c2d1e15ee9b3074ddd69f75ee9b8150d44379f
Summary:
Litho margins/padding/borders have the following attributes:
- left, top, right, bottom
- horizontal, vertical
- all
- start, end
This change processes these attributes and creates a SpaceBox inspectable which enables the margin visualiser in Flipper Desktop.
Reviewed By: LukeDefeo
Differential Revision: D41375299
fbshipit-source-id: be8bac1819f2b17c2fd1b1b86678aa0559278609
Summary:
Before this change, possible values for an enumeration were embedded within the attribute value itself.
After this change, possible values are located within the attribute metadata.
Reviewed By: LukeDefeo
Differential Revision: D41337003
fbshipit-source-id: cef5654a679e9b961e82993abb201b518fcbcd00
Summary:
There were 2 situations where the UI hadn't changed but we were sending a nodes with a different Id accross traversals which confuses things on the desktop
1. By removing the litho observer we are repeatidly scanning the entire hierachy on scroll or when a video plays. The debug component that represents litho views are not stable, they are generated each time even if the underlying component is the same
2. Offset child is generated by us each time and the old id refered to the generated offset child not the underlying object
This diff addresses these 2 cases by allowing a descriptor to choose the ID.
The nodeId convience method was used in a lot of places. For the places where the id ended up in the protocol we have migrated to the descriptors getID. In some other places it is only used internally or for logging. In this case I have renamed the method and changed the return type from Id to int so it cant be accidently used in the protocol
Reviewed By: lblasa
Differential Revision: D41307239
fbshipit-source-id: 655b230180a6d02d66888e86b2293eead3385455
Summary: In a previous diff the Bounds was made mandatory and the fragment bounds was set to be the same as the underlying view. this caused the offset to be doubled since the underlying view would also apply that offset. Since fragments dont contribute to layout and are purely for lifecycle we can set it to 0 and handle it on the desktop
Reviewed By: lblasa
Differential Revision: D41304500
fbshipit-source-id: 39591b3ef0c746bd7a4ec8d61fed623cc7c94944
Summary:
There seem to be a number of issues with registering to all changes properly for litho observer.
Removing it and allowing the decor view to do a full traversal fixes a number of problems. The performance with hardware rendering seems to be fine. This should be stopgap untill we tackle time travel properly
Reviewed By: lblasa
Differential Revision: D41304501
fbshipit-source-id: 5b7cdbd0dac04ba0dbf8dd5e449c99f0db4d0863
Summary: This makes life on the desktop easier as 99% of the time bounds were there but we were dealing with non sensical non null branches.
Reviewed By: lblasa
Differential Revision: D41218325
fbshipit-source-id: e490d3775720c1c55dcb8f4a2a85520294f5e2a9
Summary:
This diff adds support for layout and component props from Litho.
Notes:
- Each component could register a descriptor for itself.
Reviewed By: LukeDefeo
Differential Revision: D40680095
fbshipit-source-id: 57c78a199db58e05dd6dac4ed32ff6a869a73b0a
Summary:
Our descriptors currently have a method to return the name as it will be displayed on the elements hierarchy.
However, it doesn't provide enough context if the name is to be used to discover the type in our code base.
This change adds a qualified name method that can provide a more complete name which can indeed be used by the Open In IDE functionality, for example.
Reviewed By: passy
Differential Revision: D40936785
fbshipit-source-id: 790ae02b9ebf37501765c52a24307fcaaaf9c14d
Summary:
Before this change, attributes and attribute metadata were intermingled and sent as one unit via subtree update event.
This represented a few issues:
- Repetitiveness. For each declared and dynamic attribute, metadata was included on each value unit.
- Metadata can vary in size and thus can have a negative impact on payload size.
- The attribute name which is part of metadata is a string which always overhead on processing.
- Metadata instantiation is not cheap thus this also incurs in processing overhead i.e. even instantiating a single string can have an impact.
The proposal is to separate metadata of attributes from the actual node reported attributes. This solves the problems mentioned above.
Reviewed By: LukeDefeo
Differential Revision: D40674156
fbshipit-source-id: 0788551849fbce53065f819ba503e7e4afc03cc0
Summary:
There are some situatuins where a litho view can move without a mount occuring in that view. One situation is a litho view in a recycler view. If a neighbouring view is deleted or changes its width/height this will shift the whole recycler view. Since each view in the recycler view is typically a separate comonent tree. The children of the recycler view are not aware of their siblings changes through mount. And these situations do not count as a scroll which was the previous method of detecting change.
This is a work around to listen to on draw which seems to be fired in all situations.
Reviewed By: lblasa
Differential Revision: D40430777
fbshipit-source-id: a9c8196f31a6bdfd4a2fed398cfcaed190972959
Summary:
Initial implementation of Litho extensions using mount extension. After mount is called on the main thread and we traverse the hierachy. In future we can use mount extensions to construct a sparse tree rather than sending everything every time.
Scroll is handled with a native UI scroll listener for each litho view. This may break if the litho view is not a direct child of the scroll view.
Reviewed By: mihaelao
Differential Revision: D40021840
fbshipit-source-id: b09086a7a16660225885620609009dddf5b90d3b
Summary: For view pager we just want to draw the content in the center
Reviewed By: lblasa
Differential Revision: D40478266
fbshipit-source-id: 4fac7e897a0569fed59ef5810ba15300ebe87b5d
Summary:
Android does not set the top/left of the child of view pager. I attempted to solve this by grabbing the offset from the scrollview and passing it down via offset child. The issue is offsetchild has a lot of problems with the partial layout traversal. If the child of the scroll view is an observer root then the layout traversal with short circuit and setup a new observer for the child but we lose the offset child in the process.
This solution is a little dirty but it is functional for now
Reviewed By: lblasa
Differential Revision: D40430778
fbshipit-source-id: 7ad53b2a4818b55515e7662272548e2ce17e6b44
Summary: Getting the boxes to line up is quite hard to do right and has undetermined value
Reviewed By: mihaelao
Differential Revision: D40430776
fbshipit-source-id: 6093c4874f39ecf0c673407da2bd03ef06ca017e
Summary:
Getting the active child was only ever returning the actual active View.
This is correct. However, if the View is backed by a Fragment, then the child is reported as Fragment instead of the actual View.
This was an issue as effectively, the reported children (fragments) were never going to match the active child (view).
Additionally in this change, report back the name of the node even if not active.
Reviewed By: LukeDefeo
Differential Revision: D40632526
fbshipit-source-id: 3560b193b370f19ceabe66980fe23f55ec887274
Summary:
Replace draft inspectors with read-only components.
This is a first step into having a richer UI. At the moment, these are read-only components but will likely be extended in the future as to allow editing of values.
Reviewed By: LukeDefeo
Differential Revision: D40345016
fbshipit-source-id: a6aef5861474b4aa8353c00ef257ab17b4cff00e
Summary:
This change adds support for more inspectables and also introduces more complex types to be used as a value.
This become specially useful for more complex yet primitive types like coordinate, size, bounds, etc.
Reviewed By: LukeDefeo
Differential Revision: D40307885
fbshipit-source-id: 125e832f06d6b31f56eb5405182d1c0d61388930
Summary: In general we want a child to know its position without having be overriden by it parent via offset child. Therefore we need to consider translation and the result of getLocalVisibleRect. Despite its name it seems to be an offset from its normal bounds after scrolling in certain types of scroll views.
Reviewed By: lblasa
Differential Revision: D40021836
fbshipit-source-id: 4ae9a4b202d7ba201cdb8b6bc8f13e94baf2b37e
Summary: This was causing all observers to continuously traverse all children since most observers traverse on subscribe
Reviewed By: lblasa
Differential Revision: D40021835
fbshipit-source-id: 6a6fba02523848be37f5e939c7a240ff2958daca
