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
add activitySelectionMetadata and set functions (#45)
* add activitySelectionMetadata and set functions
* going back to npm for example
* Solid first iteration on set functionality
* Lots of updates to support multiple blocks with separate shields
* switch to monorepo structure
* working directory for pr publish
* fix absolute paths
* fix pkg-pr-new publish path
* try npx
* try using wildcard
* break out tests
* try not using setup-node
* always use latest pkg-pr-new
* try removing gitignore from apps/example
* remove husky from packages/react-native-device-activity
* Add set tests
* add set tests
* makre sure xcode picks up swiftlint config
* coderabbit nitpicks
* remove unnessecary comments
* coderabbit nitpicks
* Stabilizing
* add more tests
* fix empty webDomainCategories check
* Going back to familyActivitySelectionId for some things
* better naming and add resetBlocks everywhere
* add resetblocks to device-activity action types
* change name to whitelistCurrentApp
* add shieldactions for unblocking selections
* typo + docs
* remove unnessecary tries
* typo
* add refreshManagedSettingsStore and clearAllManagedSettingsStoreSettings
* fix: isSubset was comparing with wrong set
* add onlyFamilySelectionIdsContainingMonitoredActivityNames for getPossibleFamilyActivitySelectionIds
* add whitelistPossibleFamilyActivitySelection and whitelistAllPossibleFamilyActivitySelections to shield action
* add sortByGranularity to getPossibleFamilyActivitySelectionIds
* add setup-bun
* uppercase NPM_TOKEN
* add debug npm token
* add env to debug token
* rename to NPM_AUTH_TOKEN
* add working-directory
* trying something else
* use other approach
* fix git url
* add npm version
* remove -m
* hackaround
* maybe git commit is not needed
* fix working-directory
* move bun install
* revert
* add working directory, remove all mumbo-jumbo
* add nail version script
* trying a different approach
* remove potential newline
* add --no-verify
* make sure we get a clean version
* bump version
* change push logic
* add more debugging
* test
* add git add and commit
* update again
* git commit —no-verify
* chore: update version
* add test for getActivitySelectionPrefixedConfigFromUserDefaults
* upgrade rn
* tests
* more tests, add missing categoryTokens, update types
* fix types
* chore: update version
* fix tests by ignoring test activityNames
* swiftlint
* add timeouts to workflows
* starts bundler before running native tests
* bump xcode-elect to 16.2
* copying swiftlint config to make sure it’s available, also remove it from build process
* Add some more to the readme
* stricter peer deps, clean up names and comments
* prettier
* skip rn setup for native tests
* update lockfiles
* specify swift version once
* try swift_version 5.8
* print out swift version, remove trailing commas
* adjust platforms
Copy file name to clipboardExpand all lines: README.md
+41-8Lines changed: 41 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -88,7 +88,7 @@ The package requires native code, which includes a custom app target. Currently
88
88
"expo-build-properties",
89
89
{
90
90
"ios": {
91
-
"deploymentTarget": "15.0"
91
+
"deploymentTarget": "15.1"
92
92
},
93
93
},
94
94
],
@@ -110,6 +110,18 @@ For Expo to be able to automatically handle provisioning you need to specify ext
110
110
111
111
You can potentially modify the targets manually, although you risk the library and your app code diverging. If you want to disable the automatic copying of the targets, you can set `copyToTargetFolder` to `false` in the plugin configuration [as seen here](https://github.com/Intentional-Digital/react-native-device-activity/blob/main/example/app.json#L53).
112
112
113
+
## Some notes
114
+
- It's not possible to 100% know which familyActivitySelection an event being handled is triggered for in the context of the Shield UI/actions. We try to make a best guess here - prioritizing apps/websites in an activitySelection over categories, and smaller activitySelections over larger ones (i.e. "Instagram" over "Instagram + Facebook" over "Social Media Apps"). This means that if you display a shield specific for the Instagram selection that will take precedence over the less specific shields.
115
+
- When determining which familyActivitySelectionId that should be used it will only look for familyActivitySelectionIds that are contained in any of the currently monitored activity names (i.e. if familyActivitySelectionId is "social-media-apps" it will only trigger if there is an activity name that contains "social-media-apps"). This might be a limitation for some implementations, it would probably be nice to make this configurable.
116
+
117
+
## Data model
118
+
Almost all the functionality is built around persisting configuration as well as event history to UserDefaults.
119
+
120
+
- familyActivitySelectionId mapping. This makes it possible for us to tie a familyActivitySelection token to an id that we can reuse and refer to at a later stage.
121
+
- Triggers. This includes configuring shield UI/actions as well as sending web requests or notifications from the Swift background side, in the context of the device activity monitor process. Prefixed like actions_for_${goalId} in userDefaults. This is how we do blocking of apps, updates to shield UI/actions etc.
122
+
- Event history. Contains information of which events have been triggered and when. Prefixed like events_${goalId} in userDefaults. This can be useful for tracking time spent.
123
+
- ShieldIds. To reduce the storage strain on userDefaults shields are referenced with shieldIds.
124
+
113
125
# Installation in bare React Native projects
114
126
115
127
For bare React Native projects, you must ensure that you have [installed and configured the `expo` package](https://docs.expo.dev/bare/installing-expo-modules/) before continuing.
@@ -130,7 +142,7 @@ As early as possible you want to [request approval from Apple](https://developer
130
142
131
143
Note that until you have approval for all bundleIdentifiers you want to use, you are stuck with local development builds in XCode. I.e. you can't even build an Expo Dev Client.
132
144
133
-
For every base bundleIdentifier you need approval for 4 bundleIdentifiers:
145
+
For every base bundleIdentifier you need approval for 4 bundleIdentifiers (if you want to use all the native extensions that is, you can potentially just use the Shield-related ones if you have no need to listen to the events, or similarly just use the ActivityMonitor if you do not need control over the Shield UI):
134
146
135
147
- com.your-bundleIdentifier
136
148
- com.your-bundleIdentifier.ActivityMonitor
@@ -141,12 +153,33 @@ Once you've gotten approval you need to manually add the "Family Controls (Distr
141
153
142
154
⚠️ If you don't do all the above you will run in to a lot of strange provisioning errors.
143
155
144
-
## Limitations and weird/notable things
145
-
146
-
- The DeviceActivitySelectionView is prone to crashes, which is outside of our control. The best we can do is provide fallback views that allows the user to know what's happening and reload the view.
147
-
- If you've asked about the authorization status once and the user after that revokes it outside the app, the native APIs won't reflect this until the app is restarted.
148
-
- requestAuthorization() can be called multiple times, even when the user has already denied permission.
149
-
150
156
# Contributing
151
157
152
158
Contributions are very welcome! Please refer to guidelines described in the [contributing guide](https://github.com/expo/expo#contributing).
159
+
160
+
# Weird behaviors ⚠️
161
+
162
+
- Authorization changes outside app not captured
163
+
When we've asked whether the user has authorized us to use screen time, and the state is changed outside the app, the native API doesn't update until the app restarts, i.e. this flow:
164
+
1. Ask for current permission
165
+
2. Change permission outside the app
166
+
3. Ask for current permission again will return same as (1)
167
+
4.**Workaround: restart the app**
168
+
169
+
- We can both request and revoke permissions as we like, and how many times we like, even when the user has denied permissions. This is very unlike most authorization flows on iOS.
170
+
171
+
- When calling `getAuthorizationStatus` it can sometimes return `notDetermined` even though the user has already made a choice, this comes with a delay. Workaround: keep polling the status for a while (`pollAuthorizationStatus` is a convenience function for this).
172
+
173
+
- The DeviceActivitySelectionView is prone to crashes, which is outside of our control. The best we can do is provide fallback views that allows the user to know what's happening and reload the view.
174
+
175
+
# Troubleshooting 📱
176
+
The Screen Time APIs are known to be very finnicky. Here are some things you can try to troubleshoot events not being reported:
177
+
178
+
- Disable Low Power Mode (mentioned by Apple Community Specialist [here](https://discussions.apple.com/thread/254808070)) 🪫
179
+
- Turn off/turn on app & website activity
180
+
- Disable/reenable sync between devices for screen time
181
+
- Restart device
182
+
- Make sure device is not low on storage (mentioned by Apple Community Specialist [here](https://discussions.apple.com/thread/254808070)) 💾
183
+
- Upgrade iOS version
184
+
- Content & Privacy Restrictions: If any restrictions are enabled under Screen Time’s Content & Privacy Restrictions, ensure none are blocking your app.
0 commit comments