View Hierarchy #33
View Hierarchy #33
Conversation
|
Add RFC ID to the README, See example https://github.com/getsentry/rfcs/pull/22/files |
text/0033-view-hierarch.md
Outdated
| [ | ||
| { |
There was a problem hiding this comment.
I'd make proper indentation here.
Maybe the JSON should have a property to define which screen is the left/right or main one.
There was a problem hiding this comment.
Depending on the environment we may have the window position in coordinates, but left/right I would say its not relevant.
There was a problem hiding this comment.
That's just an example, if the x, y, z solves the issue, all good.
We might need a state field tho, for example, on Android, its possible to be
half_open.
There was a problem hiding this comment.
Im proposing the minimum required properties. Each platform may add more if needed.
Co-authored-by: Manoel Aranda Neto <5731772+marandaneto@users.noreply.github.com>
Co-authored-by: Abhijeet Prasad <aprasad@sentry.io>
|
What about code (de)obfuscation? |
Good point, on Android at least, native widgets such as EditText, etc are not obfuscated, Activities also not, but custom widgets and Fragments are, those will be obfuscated, @brustolin is worth mentioning this on the RFC. |
We use rrweb's json format, and their player library. for our hackweek we attempted to translate the iOS view hierarchy into rrweb JSON. you could try something similar for this -- I'm sure instead of a player you could just have it render HTML as well. |
|
@JoshFerge @philipphofmann The plan now is to have a textual tree representation of the View hierarchy. I assume that the RRWeb json format is more complex than what we are proposing and therefore would delay the release of this feature. |
|
@jjbayer do you believe we have enough information regarding what we need from ingestion? |
text/0033-view-hierarchy.md
Outdated
|
|
||
| # Proposal | ||
|
|
||
| Capture the view hierarchy in our mobile SDKs and convert it to a common JSON representation. Add it as an [attachment](https://develop.sentry.dev/sdk/envelopes/#attachment) to the envelope. The `attachment_type` is set to `"event.viewhierarchy"` and the `content_type` is set to the `"application/json"` mime-type. |
There was a problem hiding this comment.
@jan-auer since we're not forward compatible in regards to attachment types, meaning that outdated external Relays will fail to parse the envelope when there's a new attachment type, should we just use AttachmentType::Attachment here instead?
I noticed that for screenshots, there is no special attachment type either.
And this is a problem. Front-end needs to check for attachment file name which IMO is not good. |
Discussed this with @jan-auer and agreed that we should introduce a new attachment type. We will add forward compatibility to the attachment type in Relay. Because external Relays could still be outdated when we launch this feature, we should warn users who enable view hierarchies that they have to update their Relays first (if they have any). |
Make sense. Thanks!! |
Co-authored-by: Abhijeet Prasad <aprasad@sentry.io>
|
Thanks @AbhiPrasad! |
As we did in #1246 for `ItemType`, add an `Unknown(String)` variant to `AttachmentType`. When `accept_unknown_items` is set to false, items with this attachment type will be dropped. This will allow outdated external Relays to forward new attachment types instead of dropping the entire envelope. This defect was discovered in getsentry/rfcs#33, which introduces a new attachment type.
Summary
Allow SDKs to send View hierarchy of the application UI.
Motivation
Being able to see what the user was looking at is a good way to found potential problems in a mobile application.
This RFC proposes a way to send information from the UI state of an application, known as "view hierarchy".
Rendered RFC