Summary:
There is no reason to allocate views ahead of time on the main thread.
There is a chance that this view will not be mounted and we are not saving any time because it's a sequential process anyway (because we are doing it on the main thread). Moreover, the switching context can only slowdown JS execution.
Reviewed By: JoshuaGross
Differential Revision: D14026379
fbshipit-source-id: 2dbe93ab32b611fae942468e7812b78afeaf34fc
Summary:
Now RN has only ReactActivity which extends AppCompatActivity, subclass of FragmentActivity, therefore no need to check if activity is FragmentActivity or not. This PR changes DatePickerDialogModule to work only with FragmentActivity.
Also DialogFragment from Android is deprecated in API 28, and recommends to use DialogFragment from Support Library. Excerpt from DialogFragment documentation.
> **This class was deprecated in API level 28.**
> Use the Support Library DialogFragment for consistent behavior across all devices and access to Lifecycle.
**BREAKING CHANGE**: Brown field apps must extend FragmentActivity or its subclasses
[Android] [Changed] - DatePickerDialogModule supports only FragmentActivity
Pull Request resolved: https://github.com/facebook/react-native/pull/23371
Differential Revision: D14030765
Pulled By: cpojer
fbshipit-source-id: 3a1811102cf68b82c139f0e20b2fc8dab5d98b69
Summary:
Now RN has only ReactActivity which extends AppCompatActivity, subclass of FragmentActivity, therefore no need to check if activity is FragmentActivity or not. This PR changes TimePickerDialogModule to work only with FragmentActivity.
Also DialogFragment from Android is deprecated in API 28, and recommends to use DialogFragment from Support Library. Excerpt from DialogFragment documentation.
> **This class was deprecated in API level 28.**
> Use the Support Library DialogFragment for consistent behavior across all devices and access to Lifecycle.
[Android] [Changed] - TimePickerDialogModule supports only FragmentActivity
Pull Request resolved: https://github.com/facebook/react-native/pull/23372
Differential Revision: D14030748
Pulled By: cpojer
fbshipit-source-id: 9b3778c90eb1c014260327513bc8709264b94431
Summary: Make REACT_CLASS a public property on ReactSwitchManager (similar to our other UI managers) so we can more easily lazily load this class.
Reviewed By: mdvacca
Differential Revision: D14028452
fbshipit-source-id: 84aebd4e2e1e0039957d8c12490022386aab7847
Summary:
This diff disables OverlappingRendering for ReactTextView to avoid the exception:
```
java.lang.IllegalStateException: Unable to create layer for com.facebook.react.views.text.ReactTextView
```
during fade animations
OverlappingRendering enables an optimization during rendering of animations per component, disabling this might affect performance of animations inside TextView.
We will add a ReactFlag to experiment on how this affect other surfaces.
Reviewed By: blairvanderhoof
Differential Revision: D14027631
fbshipit-source-id: c1a84e7488c44582f7b7c78965aeb7bd27f82368
Summary:
Fix lint errors and warning, which might be a cause of various crashes on older Android OS, using Android Support Library.
```bash
./gradlew :ReactAndroid:lint
```
[Android] [Changed] - fix lint error/warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/23333
Differential Revision: D14019322
Pulled By: mdvacca
fbshipit-source-id: 74c98da269c318cf3b114c8d9c876186369f2b8c
Summary:
This adds Nonnull annotations for interfaces and classes used for native modules for Android, to improve Kotlin developer experience, but also code quality checks.
[Android] [Changed] - Nonnull annotations for native module interfaces
Pull Request resolved: https://github.com/facebook/react-native/pull/23353
Differential Revision: D14018181
Pulled By: mdvacca
fbshipit-source-id: 09a583860a6075e1d6f6df8f479369ae96497133
Summary:
Kotlin is getting traction and more developers write RN native modules in it. This PR adds nullable annotations to help with Kotlin null inference and improve developer experience. Also it'll help checking code quality using lint.
I skimmed through JavaOnlyMap.java, JavaOnlyArray.java, ReadableNativeArray.java, ReadableNativeMap.java, WritableNativeArray.java and WritableNativeMap.java to infer nullability.
This is breaking change to Kotlin code.
[Android] [Changed] - Add nullable annotations to ReadableMap, WritableMap, ReadableArray, Writable.
Pull Request resolved: https://github.com/facebook/react-native/pull/23329
Differential Revision: D14002571
Pulled By: cpojer
fbshipit-source-id: 899d8b3b0a5dad43e8300e6c4ea4208cca0f01a9
Summary:
Our long-term plan is to completely illuminate `jsi::Value`-to-`folly::dynamic` serialization step in prop parsing process improving performance and memory pressure. At the same time, we don't want to introduce a hard dependency in application code to JSI because it exposes direct access to VM and prevents parsing some data that come *NOT* from JSVM.
RawValue is an extremely light-weight (hopefully fully optimized-out) abstraction that provides limited JSON-like and C++-idiomatic interface.
The current particular implementation is still using `folly::dynamic` inside, but I have fully JSI-powered one which will replace the current one right after we figure out how to deal with folly::dynamic-specific callsites. Or we can implement RawValue in a hybrid manner if a code-size implication of that will be minimal.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D13962466
fbshipit-source-id: e848522fd242f21e9e771773f2103f1c1d9d7f21
Summary:
In the path to TurboModules, this was the only package that was using LazyReactPackage. Moving this to use TurboReactPackage now ensures that all the packages now have a similar interface, and more importantly, implement `NativeModule getModule(String name)` method.
Note that in OSS, we still do not run the annotation processor. As a result, we manually create the ReactModuleInfoProvider map, so that this works in OSS also.
Reviewed By: fkgozali
Differential Revision: D9419573
fbshipit-source-id: f5b15713aff0c1a221767f1c23d9b76b04434570
Summary:
RN supports API 16 and above, but we have redundant historical artifacts where we check and target APIs 16 and below. This PR removes redundant artifacts.
[Android] [Changed] - remove redundant targetApi and version checks
Pull Request resolved: https://github.com/facebook/react-native/pull/23302
Differential Revision: D13970434
Pulled By: mdvacca
fbshipit-source-id: 096b5ee6c8f076b0365e7dda0e77940290077ea2
Summary:
Location, NetInfo and Vibration modules require its own permissions to work properly, and Android Studio and lint shows warning in the modules because permissions are not found in AndroidManifest.xml of ReactAndroid, due to that not all apps require these functionalities/permissions. Therefore, developers have to add required permissions if they want to use before mentioned functionalities.
This PR suppresses missing permission warnings.
[Android] [Changed] - Suppress missing permission warnings
Pull Request resolved: https://github.com/facebook/react-native/pull/23294
Differential Revision: D13959120
Pulled By: cpojer
fbshipit-source-id: 10526f1218989b805528a5415e03371d5865be63
Summary:
React Native's minSdkVersion is 16, or we support Android versions 16 (Jelly Bean) and above. But in the code we have many checks if Android is Jelly Bean or newer, which are unnecessary. This PR removes unnecessary Android version checks, also uses Android version names instead of numbers.
[Android] [Changes] - remove unnecessary Android version checks
Pull Request resolved: https://github.com/facebook/react-native/pull/23277
Differential Revision: D13955909
Pulled By: cpojer
fbshipit-source-id: 6b1caa5ef4fe42273d3c69a6617fff140a697b5c
Summary:
Adding support for `intent://` URIs.
More details about this type of URIs: https://developer.chrome.com/multidevice/android/intents
Reviewed By: mdvacca
Differential Revision: D13817496
fbshipit-source-id: e1eeb8bd4e293e2c24ce0910286724108b3e10de
Summary:
This diff adds performance loggers for Fabric in Android to be able to compare current version or RN with Fabric
This is the summary of Points and Annotations:
- **UIManager_CommitStart**: time that React starts the commit (react tree is ready to start rendering in native)
- **UIManager_LayoutTime**: this is the time it takes to calculate layout in yoga
- **UIManager_FabricFinishTransactionTime**: Time it takes transform "C++ mutationInstructions" into "Java MountItems" and cross boundaries from C++ to Java (including serialization of data) (THIS IS ONLY FABRIC)
- **UIManager_DispatchViewUpdates**: time right before RN moves the mount operations to the Queue that is going to be processed in the next tick UI thread
- **UIManager_BatchRunStart**: time right before the mountItems are going to be process in the UI Thread
- **UIManager_BatchedExecutionTime**: time it took to run batched mountItems (usually layout and prop updates on views)
- **UIManager_NonBatchedExecutionTime**: time it took to run non-batched mountItems (usually creation of views)
Reviewed By: fkgozali
Differential Revision: D13838337
fbshipit-source-id: 0a707619829e7d95ce94d9305ff434d1224afc46
Summary:
ViewHelper has only setBackground method which works identical to ViewCompat.setBackground from Android Support Library. This PR removes ViewHelper, and uses ViewCompat instead.
[Android] [Changed] - remove ViewHelper, use ViewCompat instead
Pull Request resolved: https://github.com/facebook/react-native/pull/23280
Differential Revision: D13950510
Pulled By: mdvacca
fbshipit-source-id: 10b5122affac17d4b66fb995339c6715c0871ed0
Summary: Simple diff that adds QPL marker to track time it takes to load .so file used by RN Fabric
Reviewed By: fkgozali
Differential Revision: D13934149
fbshipit-source-id: a5cb0fc255394cf6c936b9018c753dcc774c347f
Summary:
In https://github.com/facebook/react-native/pull/20602, I tried to make ReactActivity to extend AppCompatActivity per Google recommendation. But import failed, now ReactActivity extends FragmentActivity which is a parent class of AppCompatActivity and step forward to extend AppCompatActivity.
Pull Request resolved: https://github.com/facebook/react-native/pull/22662
Reviewed By: mdvacca
Differential Revision: D13505140
Pulled By: hramos
fbshipit-source-id: d4edc8dc5c606c45811c1deddf5727a47ad484d8
Summary:
ScrollView (as well as FlatList) used with horizontal={true} and inverted={true} do not scroll as expected due to a known Android P bug.
Fixes#22710. This is pretty much a clone of PR #21117, applied to a horizontal ScrollView.
[Android] [Fixed] - Fix Inverted Horizontal ScrollView on Android
1. Create a test application with a FlatList with horizontal={true} inverted={true}.
2. Fill it with data
3. Scroll and release your finger
Pull Request resolved: https://github.com/facebook/react-native/pull/23233
Differential Revision: D13915911
Pulled By: cpojer
fbshipit-source-id: d32c82e6d9076f5ffdf342fcd71bd921e9c8a97b
Summary:
There is a variation in iOS and Android output while performing perspective transformation. The variation exists even when used in Android devices with different screen density.
Pull Request resolved: https://github.com/facebook/react-native/pull/18302
Differential Revision: D13877483
Pulled By: cpojer
fbshipit-source-id: e48be047a8047c7562722923a67666cb098243d8
Summary: simple diff to eager initialize the PreAllocateViewMountItem class with the rest of the Fabric classes
Reviewed By: sahrens
Differential Revision: D13860612
fbshipit-source-id: d1fbc653420c1c1546bbf605c682ad5bb611d76b
Summary: This diff changes the way pre-allocation of views are executed in Fabric. Before this diff the execution of view preallocation was schedulled at the end of the UIThread queue, now the views are pre-allocated in the next "tick"
Reviewed By: sahrens
Differential Revision: D13857614
fbshipit-source-id: 386bf966d3c8a0d5c0bd626119a92810465aecb7
Summary:
Motivation:
----------
This is one of the more sought after feature requests for RN:
react-native.canny.io/feature-requests/p/add-speed-attribute-to-scrollto
This PR adds the support to add a "duration" whenever using "scrollTo" or "scrollToEnd" with
a scrollView. Currently this only exists for Android as the iOS implementation will be somewhat more involved.
This PR is also backwards compatible and does not yet deprecate the "animated" boolean. It may not make sense to ever deprecate "animated", as it could be the flag that is used when devs want the system default duration (which is 250ms for Android). I'm not sure what it is for iOS. It would simplify things to remove "animated", though.
Pull Request resolved: https://github.com/facebook/react-native/pull/22884
Differential Revision: D13860038
Pulled By: cpojer
fbshipit-source-id: f06751d063a33d7046241c95348b6abbb327d36f
Summary:
Make StatusBar style respect previously set systemUiVisibility
<!--
Thank you for sending the PR! We appreciate you spending the time to work on these changes.
Help us understand your motivation by explaining why you decided to make this change.
You can learn more about contributing to React Native here: http://facebook.github.io/react-native/docs/contributing.html
Happy contributing!
-->
I tried to set `SystemUiVisibility` flag to `SYSTEM_UI_FLAG_LIGHT_NAVIGATION_BAR` to enable Android's light soft navigation bar, but when I had `<StatusBar />` component in my view, then it was always overwritten. This is how I found the bug and fixed it.
1. In MainActivity you can set systemUiFlags like this in onCreate method
```
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
Window window = getWindow();
View rootView = window.getDecorView().getRootView();
rootView.setSystemUiVisibility(View.SYSTEM_UI_FLAG_LIGHT_NAVIGATION_BAR);
}
```
2. Add <StatusBar /> to a view
3. In `android/app/build.gradle` file set `targetSdkVersion` to **27** instead of 22 or something like that
4. In `android/app/src/main/res/values/styles.xml` add 2 lines to `AppTheme`
```
<item name="android:windowDrawsSystemBarBackgrounds">true</item>
<item name="android:navigationBarColor">#ffffff</item>
```
5. Run the app.
6. Test. Previously bottom soft navigation bar was set to white and buttons also to white (so they weren't visible anymore), because StatusBar was overwriting previously set systemUiVisibility Flags. Now the bar should be white and buttons dark as expected.
Previous buggy android bottom navbar
<img width="379" alt="screen shot 2017-12-27 at 17 11 57" src="https://user-images.githubusercontent.com/571171/34385126-2a3edc44-eb29-11e7-812e-846cfd2fb88b.png">
New fixed android bottom navbar
<img width="379" alt="screen shot 2017-12-27 at 17 12 07" src="https://user-images.githubusercontent.com/571171/34385137-3e82517c-eb29-11e7-8af9-a3b7a41ae8e2.png">
This pull request does not change any existing feature. It only makes StatusBar coloring work more properly without affecting bottom navigation bar on android or any other system ui visibility feature.
<!--
Help reviewers and the release process by writing your own release notes
**INTERNAL and MINOR tagged notes will not be included in the next version's final release notes.**
CATEGORY
[----------] TYPE
[ CLI ] [-------------] LOCATION
[ DOCS ] [ BREAKING ] [-------------]
[ GENERAL ] [ BUGFIX ] [-{Component}-]
[ INTERNAL ] [ ENHANCEMENT ] [ {File} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [-------------] |-----------|
[CATEGORY] [TYPE] [LOCATION] - MESSAGE
EXAMPLES:
[IOS] [BREAKING] [FlatList] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [TextInput] - Did a thing to TextInput
[CLI] [FEATURE] [local-cli/info/info.js] - CLI easier to do things with
[DOCS] [BUGFIX] [GettingStarted.md] - Accidentally a thing/word
[GENERAL] [ENHANCEMENT] [Yoga] - Added new yoga thing/position
[INTERNAL] [FEATURE] [./scripts] - Added thing to script that nobody will see
-->
[ANDROID] [BUGFIX] [StatusBar] - Fixed StatusBar overwriting previously set SystemUiVisibility flags
Pull Request resolved: https://github.com/facebook/react-native/pull/17370
Differential Revision: D13860079
Pulled By: cpojer
fbshipit-source-id: a0bca7acb7601eb78f0842239ea4dee76a63d1fd
Summary: This diff removes the components dependencies out of the Fabric/jsi/jni project
Reviewed By: shergin
Differential Revision: D13734001
fbshipit-source-id: 65182bfa5ee9fcd526a9afc40bd9fd6f0b86c5a5
Summary: Simple diff that adds QPL marker to track time it takes to load .so file from RN
Reviewed By: fkgozali
Differential Revision: D13845379
fbshipit-source-id: 6c2272605ba3fb08ab8ebce867f84c6a488438d0
Summary:
Right now you can choose to show Videos OR Photos.
This PR allows to show both in the same time.
[ANDROID][ENHANCEMENT] - Can show videos and photos from CameraRoll in the same time
Pull Request resolved: https://github.com/facebook/react-native/pull/16429
Differential Revision: D13839638
Pulled By: cpojer
fbshipit-source-id: 5edc039552888c3ba8a40f39e262919fa7c00b39
Summary:
This method was originally intended to replace the OkHttp client used by React Native's networking library. However it has effectively been a noop since https://github.com/facebook/react-native/commit/0a71f48b1349ed09bcb6e76ba9ff8eb388518b15#diff-177100ae5a977e4060b54cc2b34c79a7, when the Networking library was modified to create a new client rather than use the reference provided by OkHttpClientProvider.
Leaving this code in place is dangerous. There is no indication to users upgrading React Native that the method is no longer replacing the OkHttpClient used by the Networking library. Any functionality reliant on overriding the client will silently break. This caused us some problems internally.
There's been a PR out for some time that seeks to reintroduce this functionality: https://github.com/facebook/react-native/pull/14068
I've also put up a new PR that adds an interface for replacing the client without introducing breaking changes: https://github.com/facebook/react-native/pull/17237
Do our unit tests continue to pass? Should be safe as this method is not used anywhere inside React Native.
[ANDROID] [BREAKING] [Networking] - removed replaceOkHttpClient method in OkHttpClientProvider.
Pull Request resolved: https://github.com/facebook/react-native/pull/16972
Differential Revision: D13838805
Pulled By: cpojer
fbshipit-source-id: 43606d1d141afb9b5dda4dd64e5ac5448771b45c
Summary:
On Android `textTransform` breaks other styles applied to the text. It seems related to the usage of `ReplacementSpan` which allows drawing the text manually but seems to throw away some changes made by other span applied to the text.
To fix it I removed the usage of `ReplacementSpan` and simply transform the text before appending it to the `Spannable` string. To make sure textTransform is inherited correctly I added it to TextAttributes which handles this.
Pull Request resolved: https://github.com/facebook/react-native/pull/22670
Differential Revision: D13494819
Pulled By: cpojer
fbshipit-source-id: 1c69591084aa906c2d3b10153b354d39c0936340
Summary:
This PR addresses TODO left in _AppState.js_
The goal is to align AppState module implementation between iOS and Android. iOS native module exposes _initialAppState_ constant that AppState.js relies on, while Android doesn't expose that constant and js implementation uses a fallback. This PR aims to remove a need for a fallback
Pull Request resolved: https://github.com/facebook/react-native/pull/19935
Reviewed By: hramos
Differential Revision: D13774044
Pulled By: ejanzer
fbshipit-source-id: 05d27e702cb9aeedf14293158bfd50004df4726b
Summary:
@public
Removes `YGNodeInsertSharedChild` / `addSharedChildAt`.
This functionality is unused, and can cause memory leaks.
Reviewed By: SidharthGuglani
Differential Revision: D13711105
fbshipit-source-id: 86206c05393b3f1a497e6b046006f94ead88c6ce
Summary:
Equivalent of this iOS PR: https://github.com/facebook/react-native/pull/20915
Motivation:
----------
Whenever a user changes the system font size to its maximum allowable setting, React Native apps that allow font scaling can become unusable because the text gets too big. Experimenting with a native app like iMessage on iOS, the font size used for non-body text (e.g. header, navigational elements) is capped while the body text (e.g. text in the message bubbles) is allowed to grow.
This PR introduces a new prop on `<Text>` and `<TextInput>` called `maxFontSizeMultiplier`. This enables devs to set the maximum allowed text scale factor on a Text/TextInput. The default is 0 which means no limit.
Pull Request resolved: https://github.com/facebook/react-native/pull/23069
Differential Revision: D13748513
Pulled By: mdvacca
fbshipit-source-id: 8dd5d6d97bf79387d9a2236fa2e586ccb01afde9
Summary:
On Android, resources with the same name from different libraries conflict, so it's encouraged to have prefixes for resource names.
This is one case where the settings menu preferences file in firefox for android is called `preferences.xml` so it conflicts with the dev support settings menu for react native.
when integrating react-native to the firefox project, react native dev settings menu never shows, and the one from firefox shows up instead.
This a link to a file from a fork project that I'm working on:
https://github.com/ghostery/browser-android/blob/master/mozilla-release/mobile/android/app/src/main/res/xml/preferences.xml
Please, let me know, if anything more needs to be changed
Changelog:
-----------
[Android] [Fixed] Rename dev settings menu preferences file with a RN prefix.
Pull Request resolved: https://github.com/facebook/react-native/pull/23123
Differential Revision: D13781836
Pulled By: cpojer
fbshipit-source-id: f27483d4eca5aa4148759b94b601673985c5aa91
Summary: Eager load classes used by Fabric. This is a temporary change that will be reverted in the near future
Reviewed By: shergin
Differential Revision: D13747454
fbshipit-source-id: 8ceb21f51982bcfcaa005dcc2ad9b457f7211795
Summary:
For certain style props, each time any style prop changed, the previous version of the style would remain. For example, if you passed `"underline"` for `textDecorationLine` on a `TextInput` and then later passed `undefined` for `textDecorationLine`, the underline would remain.
We solved this problem before in https://github.com/facebook/react-native/commit/de586bfa186289114974674bc2aece462f40393e. The fix was to use `manageSpans` to remove the old spans we added before adding the new spans. However, that fix hardcoded the list of spans to remove. Every span type that was introduced since that commit is affected by this bug:
- CustomLetterSpacingSpan
- CustomLineHeightSpan
- CustomTextTransformSpan
- ShadowStyleSpan
- StrikethroughSpan
- UnderlineSpan
- TextInlineImageSpan
The reason this bug was reintroduced is `ReactBaseTextShadowNode` is responsible for adding spans and `ReactEditText` is responsible for removing spans. These classes fell out of sync.
This fix attempts a more robust solution. Every span that React Native adds to text now implements the `ReactSpan` interface. `manageSpans` deletes all spans that React Native adds by targeting the ones that implement `ReactSpan`. `ReactBaseTextShadowNode.SetSpanOperation` has been updated so that it's a compiler error to add a span that doesn't implement `ReactSpan`.
Pull Request resolved: https://github.com/facebook/react-native/pull/22994
Differential Revision: D13727580
Pulled By: mdvacca
fbshipit-source-id: 07b2eb08832efafb6c2806aa3329f0e9466b09fb
Summary:
Changelog:
----------
[Android] [Fixed] - Fix Picker.onValueChange sometimes not fired due to race condition. Fixes#15556
Root Cause:
------------
Please check my code snippet at https://snack.expo.io/kudochien/android-picker-issue
and try to select different items on Picker to see if console.log() hit.
If calling setState() with some latency, e.g. setTimeout() or changes from redux,
the second time changing picker item on UI, the onValueChange() will be not fired.
The root cause comes from the `forceUpdate` in PickerAndroid.android.js.
If user's setState() update comes after forceUpdate(), the flow will be:
1. First time select picker item
2. onValueChange + forceUpdate
3. user's setState() + componentDidUpdate + setNativeProps({ selected: ... })
4. mSuppressNextEvent = true
5. Second time select picker item
6. Since mSuppressNextEvent is true, the onValueChange will not be fired.
Solution:
---------
Like other controlled components, disable change listener during setup values from JS.
Android Spinner `setSelection(int position)` is asynchronous call, i.e. will fire onItemSelected in next run loop and is not suitable for us.
`setSelection(int position, boolean animate)`, however, is synchronous call which I used.
Some more references about setSelection:
https://stackoverflow.com/a/43512925/2590265http://androidxref.com/8.1.0_r33/xref/frameworks/base/core/java/android/widget/AbsSpinner.java#276
The two arguments version will use `setSelectionInt()` which set mBlockLayoutRequests as true to prevent onItemSelected call from next layout().
I also moved the setOnItemSelectedListener() call after onLayout to prevent onValueChange() during intialization.
Pull Request resolved: https://github.com/facebook/react-native/pull/22821
Differential Revision: D13731979
Pulled By: cpojer
fbshipit-source-id: e06bd9aa62463b66c8f3fd7214485898d5375054
Summary: This diff removes the FabricBinding interface becuase it is not needed anymore.
Reviewed By: sahrens
Differential Revision: D13707494
fbshipit-source-id: 7b50dcd40559356464a860ba32d9a0130ab2da6e
Summary: This diff removes the FabricBinder interface as it is not required anymore
Reviewed By: sahrens
Differential Revision: D13707495
fbshipit-source-id: ba470e7b0884d75491b1b162cd6bce09c193d863
David Vacca
Dulmandakh
Emily Janzer
Valentin Shergin
Ram N
Angel Kjoseski
Vojtech Novak
Davide Mainas
Ranjan Shrestha
Kevin Gozali
Michał Osadnik
rogerkerse
Kesha Antonov
Chris Lewis
Janic Duplessis
Jyrno Ader
Oleg Bogdanov
David Aurelio
Adam Comella
Khaled Tantawy
Christoph Nakazawa
Kudo Chien
Luna Wei
