vela_links 0.2.5

Deep links, deferred deep links, short links, QR codes, link tracking and in-app event analytics (sessions, screens, sign-ups, purchases) for Flutter.

0.2.5

Small fixes and a corrected note in the README.

• resetUser() now starts the new identity at once. Before, an event tracked in the instant while the old saved values were being removed could still go out under the old install id.
• flushEvents() now really sends now: it ignores the wait that follows a failed send and waits for a send that is already running.
• README: the note about adding the SDK to an app that is already installed was wrong. It said to pass autoTrack: false and turn it on in a later release, but turning it on later sends first_open for every existing install anyway. The SDK cannot tell an existing install from a new one, so everyone who updates to the first release with the SDK (or from an older SDK version, including 0.1.x) sends first_open and session_start once, and the new-installs figure rises for that release. The note now says so, and that matchDeferred: false only skips the first-launch link check.
• README: on iOS the clipboard is emptied after the install token is used, even if something else was copied in the meantime.

0.2.4

Fixes found in a full review. Recommended for everyone who uses in-app events.

• Sign-in and sign-out: an event that could not be sent right away is now kept with the person it was tracked for, and goes out for that person later. Before, it could be sent under the next person who signed in. A batch holds one person's events only, and a batch that is sent again is identical to the first try. Sign-in, sign-out and a forced send now wait for a send already in progress.
• Consent after start-up: the link that brought the install is now remembered even while tracking is off (it is never sent then), so a person who agrees later is still credited to it.
• first_open: it is now sent once per install whenever tracking is on, also when consent is given on a later launch or the app was closed before it was saved. An install is no longer mistaken for an update because the first-launch check had already run, and a repeat after a crash counts once. (A person who updates from a build without the SDK, or from an older SDK version such as 0.1.x, sends first_open once.)
• Sessions: a dialog, the notification shade or a permission prompt no longer starts a new session_start after a long visit; only coming back from the background does. The last-active time is kept fresh while the app is in use.
• Start-up: events, once-only events and setUserId called while the SDK is still loading are no longer lost or recorded twice. A platform problem with link listening can no longer stop init. dispose no longer leaves a send scheduled.
• Once-only events count as done when they are sent, so one that was discarded (tracking turned off, or the queue was full) can be tracked again. A purchase amount above 1,000,000,000 is dropped, as the service would refuse it.
• README: setup now covers the INTERNET permission, minimum versions, the dashboard fields that make web links open the app, the effect of turning off Flutter's deep-link handling, appId for debug and flavour builds, backup exclusion that works, consent on every launch, and what happens for people who update from a build without the SDK (they send first_open and session_start once).

0.2.3

Fix: a brand-new install that turned tracking on only after a consent screen (init(trackEvents: false), then setTrackingEnabled(true)) did not report first_open, because the first-launch check had already marked itself done. Whether an install is new is now decided when the SDK starts.

0.2.2

Documentation only. The README is shorter and easier to follow: a quick start first, then platform setup, a short reference and one privacy section. The Android and iOS setup is complete (custom URI scheme included), the start-up snippet now sits inside main(), and the repeated notes were merged. No code changes.

0.2.1

Fixes found in a full review of 0.2.0. Recommended for everyone who uses in-app events.

• Events were refused for some apps: an app version containing a space (for example 2.3 RC1) made the service refuse every batch, and the SDK then threw those events away. The version is now cleaned, and a refused key (401/403) or timeout keeps the events to retry.
• Sign-in, sign-out and switching accounts now first send the events that were waiting under the previous identity, instead of attaching them to the next person or discarding them. setUserId accepts only ids the service accepts (visible ASCII, no spaces).
• Consent flows: setTrackingEnabled(true) now starts the automatic events, and a choice made before startup finishes is kept.
• Updating from 0.1.x no longer reports first_open for installs that already existed.
• A purchase is kept when its orderId has unsupported characters (the id is left off). Once-only events are once per person (per user id). When the offline queue is full, screen views are dropped before sign-ups and purchases.
• The same link handed over twice at launch is counted once. Storage errors can no longer surface as unhandled errors in your app.
• Documentation: the privacy section now lists everything the SDK stores and sends, plus consent, account-switching, backup and unverified-revenue notes.

0.2.0

In-app analytics.

• New: track, trackPurchase and trackScreen, plus VelaLinksObserver for automatic screen tracking. The SDK also reports first_open and session_start by itself. The dashboard's Behaviour tab turns these into active users, retention, funnels, revenue and campaign results.
• Events are sent in small batches in the background, kept and retried when offline (up to a week), and never throw into your app.
• Privacy controls: setTrackingEnabled, resetUser, and init(trackEvents: false) / autoTrack: false.
• Events carry the link that brought the install, so purchases and sign-ups are credited to the right campaign.
• A batch that is retried keeps its id, so the service never stores it twice. Dialogs and bottom sheets are not counted as screens.
• New: setUserId (one person across phones and reinstalls, including activity before sign-in), track(..., once: true), trackPurchase( orderId:). Every event carries its own id so a resend is never stored twice, and an identical event within a second counts once.
• VelaLinks.maybeInstance for code that may run before the SDK starts.

0.1.3

• Package description and README no longer mention other products.

0.1.2

Security and quality release. Recommended for everyone.

• Android: only the Vela Links token is read from the Play install referrer, and only that token is sent. Other referrer text (for example advertising campaign data from other companies) no longer leaves the device, and no request is made at all when there is no token.
• iOS: the first-launch check makes at most 3 tries, so the clipboard is not read (and the paste notice not shown) on every launch if the service is unreachable. Only text shaped like a Vela Links token is ever used.
• Redirects from the service are refused, so the SDK key can never be sent on to another address. The public link lookup sends no key.
• Unexpected answers from the service now raise VelaLinksException (or count as "not found") instead of a raw type error.
• Error messages from the service are length-limited.
• Stricter analysis settings and full API documentation; the example now shows creating a link and checking a link's route.
• Every failure, including TLS and certificate errors, is now a VelaLinksException; background reporting can no longer raise an error in your app. Responses are capped at 1 MB even when sent in chunks.
• init calls are queued, so two at once cannot leave a half-closed instance; a bad baseUrl on a second call leaves the running SDK alone; the SDK closes the HTTP client it created; a late dispose can no longer be followed by a new listener.
• A base url with a user name, query or # is refused.
• Links must have the exact Vela Links shape (/l/<slug>/<code>, or scheme://l/<slug>/<code>). New optional slug to ignore other apps' links.
• iOS: the clipboard token is cleared without reading the clipboard again. A link already handed to a listener is no longer kept as "pending".
• LinkAddress is now exported.
• Wording: the app-id check only applies once your app's package name or bundle id is saved in the dashboard.

0.1.1

• Works with app_links 6 and 7 and package_info_plus 8 to 10, so it does not clash with the versions your app already uses.
• Clearer package description, topics and README (deep links, app links, share links, QR codes, link tracking).

0.1.0

First public release.

• Receive deep links (Universal Links, App Links, custom scheme) with VelaLinks.instance.onLink.
• Deferred deep links: the first launch after install is matched to the link that led to it.
• Create short links from the app with createLink.
• Reports link opens and QR scans so they show in the dashboard.
• Every call has a time limit and fails with VelaLinksException; the SDK never throws into app start-up.
• Sends the app's package name / bundle id so a copied SDK key does not work in another app.