6 Commits

Author SHA1 Message Date
Valentin Shergin
54e83e0eee Fabric: Free image bitmap data during RCTImageComponentView recycling
Summary: Trivial. `imageLocalData` retains a network request, observers and actual bitmaps.

Reviewed By: mdvacca

Differential Revision: D10054430

fbshipit-source-id: 9bea11677b73e9e7ce7bc50bd14ec5515dac60de
2018-09-26 14:34:10 -07:00
Valentin Shergin
8206e841d1 Fabric: Fixed crash caused by incorrect bridge transfer annotation
Summary:
Don't ask.
Really, all those descriptions from official docs like below are useless:
 * `__bridge_transfer` Moves a Core Foundation pointer to Objective-C with transfer of the ownership to ARC.
 * `__bridge` Transfers a pointer between Objective-C and Core Foundation with no transfer of ownership

All that is totally confusing and useless. At the end of the day, we only have to think about which additional `CFRetain` and `CFRelease` ARC will add or will not add for our pointers.
So, following official docs recommendation, we would like to add `__bridge_transfer` because of course, we do want to ARC managing the variable after we introduced it to ARC here. But we also want to have shared ownership of this. That's the key. If we use `__bridge_transfer` ARC will assume that this variable already retained once (because it exists) and will call CFRelease at the end of the scope. Right before that when we pass this variable down to call stack ARC will retain and then manage the variable according to the rest of the code. But still, from this point, we will have zero-balanced reference counter; the owning by `shared_ptr` bump is already compensated with `CFRelease` at the end of the scope. As soon as the rest of the code release the object, it will be incorrectly deallocated.

So, instead of using `__bridge_transfer` we have to use `__bridge`. That will indicate that *in this block* ARC does not manage the reference counter of the variable (which is kinda true because having `shared_ptr` inside the block already retains that) and will not add `CFRelease` at the end of the block.

Reviewed By: mdvacca

Differential Revision: D10054241

fbshipit-source-id: 6e82c5270fe5d53f1ed68e167b94f70dc4367a9f
2018-09-26 14:34:09 -07:00
Héctor Ramos
1151c096da Update copyright headers to yearless format
Summary: This change drops the year from the copyright headers and the LICENSE file.

Reviewed By: yungsters

Differential Revision: D9727774

fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
2018-09-11 15:33:07 -07:00
Valentin Shergin
37d19aaae3 Fabric: Unification of props management in RCTViewComponentView and subclasses
Summary:
* Now all `RCTViewComponentView` subclasses are required to set `_props` instance variable in the constructor with a default value;
* `RCTViewComponentView`'s `_props` instance variable now has `ShadredViewProps` type (that enforced by `static_assert` in `ConcreteViewShadowNode` template);
* New we use `static_pointer_cast` instead of `dynamic_pointer_cast` for casting props.

Reviewed By: mdvacca

Differential Revision: D9734199

fbshipit-source-id: b0a0939c936f8b5b540fa5fa1e4a2f1037346fc5
2018-09-10 16:50:02 -07:00
Valentin Shergin
d629e4b0e5 Fabric: Releasing image bitmap as part of prepareForRecycle
Summary:
@public
When some `RCTImageComponentView` is going to be recycled, it makes sense to free an associated bitmap because it will not be reused anyways.

Reviewed By: mdvacca

Differential Revision: D8601751

fbshipit-source-id: 1318622b66460b8e5588a4420c91c516fe2b1106
2018-06-26 11:48:12 -07:00
Valentin Shergin
f6aa5db0e4 Fabric: RCTImageComponentView
Summary:
@public
This is iOS-specific implementation of <Image> view.
Not all props and features are supported yet.
Known issues:
 - Animated GIFs;
 - CA transitions during image appearance.

Reviewed By: mdvacca

Differential Revision: D8526570

fbshipit-source-id: a4b1dca583b139b8a09431565a79f051fae67a36
2018-06-22 07:32:50 -07:00