You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The app package requires the following boilerplate and a closure provided to app.Main.
funcmain() {
app.Main(func(a app.App) {
// ...
Are there any cases where we will support multiple app.App instances? If not, why don't we just export an App instance from the app package. It may have an accessor that blocks until the app instance is ready.
The lack of a globally accessible app instance leads third party packages polluting their APIs. A typical example is the x/exp/sensor package where the Enable function needs to accept a sender implementation in order to dispatch the events to the app event channel. Within the same app, there must be a single App instance and user should never be exposed to third party APIs that requires it as an argument.
Sorry, I am missing something. How does the change in the app package help exp/sensor package avoiding the sender argument?
Some apps may want to collect and aggregate sensor data using the sensor package but independently of the app package. They may choose to occasionally send the aggregated data to the app.Main's f but, through an independent channel. (for { select { case <- a.Events() , case <- sensorChannel ... } } )
I hope less packages to depend on the app package, so that more packages in mobile repo become available to Gobind apps.
Some apps may want to collect and aggregate sensor data using the sensor package but independently of the app package.
The rationale behind the API rewrite was to enable APIs that dispatches events through the app event channel. If we don't desire to couple any package with the app package, our rewrite attempt is fundamentally wrong. The previous APIs and implementations were completely app package agnostic and were less error prone.
If the intention is to decouple the app package, I'd rather revert all the changes to the sensor package and let the users decide whether they would like to pipe the events to the app event channel or not themselves.
Considering @hyangah's feedback about reducing the dependencies to the app package, I am closing this issue. The sensor redesign discussion is off-topic under this issue.
The app package requires the following boilerplate and a closure provided to app.Main.
Are there any cases where we will support multiple app.App instances? If not, why don't we just export an App instance from the app package. It may have an accessor that blocks until the app instance is ready.
The lack of a globally accessible app instance leads third party packages polluting their APIs. A typical example is the x/exp/sensor package where the Enable function needs to accept a sender implementation in order to dispatch the events to the app event channel. Within the same app, there must be a single App instance and user should never be exposed to third party APIs that requires it as an argument.
/cc @crawshaw @hyangah
The text was updated successfully, but these errors were encountered: