Comments (8)
No, not at all! We're very appreciative of the feedback, questions and discussion. Helps us make it all better. :D
from analytics-swift.
I should also add that I moved the applicationDidBecomeActive(application:)
, openURL(_ url:)
and receivedRemoteNotification(userInfo:)
methods outside of the body of the update(settings:)
method because afaict they are meant to be called as part of the destination's conformance to iOSLifecycle
– but perhaps I'm missing something here.
from analytics-swift.
I'll have a look at this and see if I can get some more clarity here as to what's happening. Is your implementation relatively similar to the DestinationExamples demo app in the repo?
from analytics-swift.
Yeah, it's basically a copy and paste of the example. The only thing I really changed is moving the app lifecycle methods outside of the update(settings:)
function body as I thought that was most likely unintentional :)
from analytics-swift.
Would love to hear your thoughts here @tcldr .
Digging into this further, much of it stems from the fact that some destination SDKs are singletons while others are not. While we don't want to prevent some SDKs from being able to update when settings are changed on segment.com, but we need to protect against those who can't function this way, such as AppsFlyer here.
I think the choices seem to boil down to ...
- We only call update(settings:) once when we have settings. This would prevent some destinations from being able to update until the next time they're cold launched.
- We add something to the DestinationPlugin protocol such that we avoid calling update(settings:) if it's a singleInstance destination.
- We just deal with it on a per destination basis and leave DestinationPlugin's interface clean and the analytics code ignorant of this detail.
What are your thoughts?
ps. I saw what you were referring to re the functions inside applicationDidBecomeActive and will correct it when I have a PR for this ready.
from analytics-swift.
Hi @bsneed ,
Thanks for taking a look at this. Yes, I certainly see the difficulty. Of the options listed I would probably go with 3, but perhaps with an additional flag which leaves Plugin developers with no doubt that this is an initial launch vs a restart e.g. update(settings:isRestart:) or a dual API of applyInitial(settings:)
and update(settings:)
.
However, I'm not sure how this solves the first launch scenario.
This is the situation where a user opens the app the first time after downloading it, so Segment is yet to cache its settings. This is difficult because at this point these plugins are yet to receive their settings, but there are also a bunch of potentially critical events being emitted. These are the most important for me as they contain things like attribution, on-boarding data, deep-links, etc.
In the case of plugins that enrich events, this will create inconsistent data as some site's will generate events with enriched data and others without. As a plugin may, or may not be set-up during launch, Identify calls will be missed, applicationDidBecomeActive events will be missed, etc.
Also, it becomes very difficult to design a plugin as you have to juggle all the various states the plugin could be in. If you need something to happen on applicationDidBecomeActive, but the dependency hasn't been configured, you'll need to create a flag for it and check it during update(settings:).
Really, I think Segment should hold-off sending any events until it receives its initial settings payload and then replay them through the pipeline once the plugins have had their initial set-up. In fact, I'm not sure Plugins should be directly listening for system events at all, I think they should probably all flow through the pipeline – so they can be replayed if it's required. A plugin can then do what it needs to when it receives an event from Segment, rather than the system. This is the easiest way that I can see to maintain consistency.
What do you think?
from analytics-swift.
Hi @tcldr,
It very much works like you describe already. Those changes are relatively recent on master, so not sure if you have them yet. StartupQueue is doing the storage/replay of events until we're in a running state.
update(settings: ) is called whenever we receive settings... these cases would be:
- on first-launch-ever once the /settings endpoint has data.
- on launch if we have settings cached. we'll still hit the /settings endpoint, so it would get called a 2nd time.
- on return from background we'll hit the /settings endpoint again, so it would get called again.
The intent is to tell plugins when we've received settings. There's not really any state to manage other than in the case of a plugin using a singleton like Firebase or something, that you've already set that up, so don't do it again. Internally, we've decided to go with option 3 in the previous message above. I'll look and see if we can provide a param to give guidance on which of the above scenarios is happening.
from analytics-swift.
That’s great to hear! It would be a shame to miss those early identify/attribution events.
I know a lot of this is getting rapidly sorted out so I hope I’m not creating to much noise here.
from analytics-swift.
Related Issues (20)
- automation test #3
- Question: Difference between docs and Github for using segment with watchOS HOT 1
- Pass anonymousId in Segment identify API in swift version HOT 1
- Documentation for track, screen, and identify regarding properties isn't fully accurate + unexpected debug crash HOT 2
- Flush running on main thread and may take a long time HOT 12
- Argument passed to call that takes no arguments HOT 3
- NaN crash Encodable.toString(pretty:) HOT 12
- iOS Lifecycle Events post two events with the same name `Application Opened`
- Event files can contain corrupted JSON data HOT 1
- Storage calls seem to result in main thread deadlocks HOT 14
- Why does Segment have an encoding error for Foundation.Date objects? HOT 1
- Pluggable Networking Stacks HOT 4
- Temporary Files Get Stored In User's Documents Directory On Windows HOT 2
- Nit: Allow date formatting to be configured by client? HOT 4
- Crash in Analytics.configuration.getter HOT 18
- Add optional track method that returns success/fail result HOT 2
- Notification observer is not being called "io.segment.analytics.integration.did.start" HOT 1
- Crashing in `connectionStatus()` on app start
- Crash inside DestinationMetadataPlugin during Analytics.update call HOT 12
- JSON encoding: lots of Codable-conforming types that crash in JSON encoding HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from analytics-swift.