daybook_feedback 0.3.0

In-app feedback for Flutter: shake, screenshot, a button or a two-finger long press opens a report of the moment, a process step by step, or a recording, marked up and noted. Only for people approved [...]

daybook_feedback

In-app feedback for Flutter, from Daybook. Somebody shakes the phone, takes a screenshot, taps a small button or holds two fingers on the screen, and gets a composer with a picture of what they were looking at. They tap the thing that is wrong to pin it, say what happened, and send. It arrives in Daybook with the screen they were on, how they got there, their device and the app version.

It does nothing for anybody you have not approved. That is the point of the setup below.

Setup

1. In Daybook, open the project's Widget setup, create a key and choose Flutter.

2. Add the package:

   dependencies:
     daybook_feedback: ^0.3.0
   

3. Start it, put it in your MaterialApp, and say who is signed in:

   Future<void> main() async {
     WidgetsFlutterBinding.ensureInitialized();
     await DaybookFeedback.init(ingestKey: 'pmi_...');
     runApp(const MyApp());
   }
   
   // In your MaterialApp, so feedback is drawn in your theme and follows it into dark mode:
   MaterialApp(
     builder: DaybookFeedback.builder,
     theme: myTheme,
     darkTheme: myDarkTheme,
     // ...
   );
   
   // Wherever you know who is signed in:
   await DaybookFeedback.identify(
     FeedbackIdentity(externalId: user.id, email: user.email, name: user.name),
   );
   
   // And on sign-out:
   DaybookFeedback.reset();
   

4. Optionally, add DaybookFeedback.navigatorObserver to your MaterialApp.navigatorObservers, so reports say which screen they came from and how the person got there.

If you already have a builder, call ours inside it: builder: (context, child) => DaybookFeedback.builder(context, MyWrapper(child: child)). If it cannot go in the MaterialApp at all, runApp(DaybookFeedback.wrap(app, theme: light, darkTheme: dark)) works too; with no themes it follows the phone's light or dark setting in its own colours.

Who gets it

Nobody, until you say so. The first time a person you identified starts the app, they appear in the project's Reporters queue as a request, with their device and app version. Until someone approves them:

• there is no button, no gesture listener, no shake sensor and no screenshot listener;
• DaybookFeedback.open() returns false;
• nothing can be filed with the key.

This is enforced by Daybook's server, not by the SDK: a Flutter key refuses anonymous use and anybody not approved by a person, whatever the project's reporter policy. Approve them, and the next app start turns on exactly the triggers the key allows. Block them, and it all goes again.

Triggers

Set per key in Daybook, and picked up on the next app start. Any combination, but at least one:

Trigger	Notes
Shake	Several hard jolts close together; putting the phone down does not count.
Screenshot	A system screenshot opens the composer. iOS, and Android 14 and later. Turn it off if your app already does something on screenshot, such as sharing.
Floating button	A small button, bottom-right; drag it out of the way for as long as a report takes.
Two-finger long press	Two fingers held still. Collides with almost nothing.

A trigger that is off is never registered, so it cannot collide with your app. Whatever is on, you can also open the composer from your own code:

DaybookFeedback.open(); // false when this person is not approved

Reporting

Feedback opens with a choice of what to send:

• This moment — the screen as it was when they opened feedback, to pin and mark up. A system screenshot goes straight here.
• Step by step — for a process, and for QA. The composer steps aside and a small bar offers Capture and Done; the person uses the app and captures each step. Back in the composer each step has its picture, its own markup, and a note of what they did there. Up to 10 steps, sent as a screenshot each, and shown in Daybook's triage in order with their notes.
• Record a video — up to a minute of the app in use.

The capture and recording bars can be dragged up and down, out of the way of your app's own bars. On any picture:

• Mark up. Tap the screenshot to open it full-screen: pin what is wrong (numbered), draw round it, or drag a box. Undo and Clear. The markup is drawn into the screenshot that is sent.
• Point at it. The composer steps aside and the person taps the real thing in the app. It gets a ring and a number, and the tap never reaches your app. Several in one go, then Done.
• Record. Start, use the app as normal while a small stop control shows the time, stop. Up to a minute, as an MP4 of the app with taps shown, attached to the report.

The keyboard closes when you tap outside a field or scroll, and Send stays above it.

What's new and What to test

Write them on the project's Daybook release, in Daybook or over MCP, with the release's version equal to your app's version (2.4.0). Approved people running that version see an entry at the top of the composer, and a dot on the button when either text changed since they last looked — What to test shows before the release is published, which is when testers need it.

What it takes, and what it does not

• The screenshot is the app drawing its own frame: no photo-library or screen-recording permission.
• So is a recording: the app's own frames, encoded on the phone (AVFoundation on iOS, MediaCodec on Android). No ReplayKit or MediaProjection, nothing to allow. What Flutter does not draw is not in it — the keyboard, the status bar, system dialogs — and a password field is in it as its dots. It is sized to the project's attachment limit (8 MB by default), and refused before sending if over.
• Android 14+'s screenshot callback uses DETECT_SCREEN_CAPTURE, a normal permission granted at install, never a prompt. On older Android the screenshot trigger simply does not fire.
• A pin records the text of what was tapped and the nearest ValueKey<String> above it — give the widgets you care about a key, and reports will name them.
• Offline, a report waits (without its screenshot or recording) and goes on the next start.

Running the example

cd example
flutter run --dart-define=DAYBOOK_KEY=pmi_... --dart-define=DAYBOOK_EMAIL=[e-mail]

Approve yourself in Reporters, restart, and shake.