26 Commits

Author SHA1 Message Date
Cody Weaver
96c8a5f6e8
[ActionSheet] Remove Beta test from Ready component (#6677)
## Related links
* Component: [ActionSheet](https://github.com/material-components/material-components-ios/tree/develop/components/ActionSheet)

## Introduction
When I moved `MDCActionSheet` to ready I didn't properly update the cocoapods tests. The test were relying on the `MaterialComponentsBeta` podspec. This change fixes their reliance on the `Beta` pod and the test weren't being run.

## The fix
This fixes the issue where the test weren't part of the scheme and relying on beta things.
2019-02-21 13:49:26 -05:00
Yarden Eitan
136273636d
[Cards] [Ripple] Integrate the new ripple and states into the Cards component (#6621)
**Overview**
This PR integrates the new Ripple component and its state support into our existing Cards and CardCells components. It does so in an opt in form, where you must have MaterialComponentsBeta installed for one to have Cards use the new behavior. The PR also includes 2 examples showcasing the new behavior with MDCCard and MDCCardCollectionCell.

**Resolves**: #6463

**Acceptance Criteria:**
* The Cards have an opt in property (as ripple is in beta) to be able to activate the ripple and its states support in Cards. It will fallback to the existing (legacy) implementation by default.
* An MDC example that showcases the work for Cards.
* Interaction and animation with the card should follow the guidelines from the updated cards design doc.

**Implementation Explained**
This is a pioneer PR, trying to converge a beta component into a ready component. To do so we had to have our Card component not be aware of the existence of the beta component Ripple, but we needed the Ripple component to be able to plug in to the Card component.

To achieve this I created a few different things:
1. A ripple delegate that plugs into MDCCard and MDCCardCollectionCell that consists of methods that should be invoked in the component where the Ripple work needs to be inserted. A check for the existence of the delegate and the corresponding delegate method is checked in the Card component before invoked. This allows us to identify if Ripple should be used or not.

2. A MDCCard+Private and MDCCardCollectionCell+Private categories that expose the RippleView property in the implementation files of the Card component, and also exposing other methods that the Ripple integration needs to invoke but aren't exposed in the original Card header files.

3. An MDCCard+Ripple and MDCCardCollectionCell+Ripple categories under beta, that implement the delegate introduced in 1. and have knowledge and access to the beta component Ripple. This is where the actual implementation of the ripple integration sits.

4. Lastly, we need a way to set card.rippleDelegate = self for the +Ripple categories. However, there are a few issues in achieving this. If we create a BOOL property like `shouldIntegrateRipple`, we would need to be able to switch the state from `YES` to `NO` and back correctly. The state is very complicated when you have states, ripple vs ink, etc. Therefore the best way to do this is not to allow users to trigger a BOOL, but to have a separate initializer for `initWithRipple`. However, CardCollectionCells are reused and the dequeue method calls `initWithFrame` and we can't ask it to invoke `initWithRippleandFrame` instead. Therefore, I added performSelector logic in the init methods of the Card component that checks to see if the Cards+Ripple category is apparent (meaning Beta is integrated in the framework), and if so initializes the Ripple. Happy to find alternatives if better ones are offered.

**GIFs before and after**

Before:
![oldtop9card](https://user-images.githubusercontent.com/4066863/53095318-8501f380-34ea-11e9-8b79-328af61e0fc1.gif)

After:
![newtop9card](https://user-images.githubusercontent.com/4066863/53095334-8c290180-34ea-11e9-9767-73d74e8fefd8.gif)
2019-02-20 11:32:19 -05:00
Randall Li
7b73a03e14 Merge branch 'release-candidate' into develop 2019-02-15 00:18:41 -05:00
Randall Li
85d3f991c8 Bumped version number to 77.0.0. 2019-02-13 13:38:03 -05:00
Cody Weaver
7614c80c26
[ActionSheet] Promote to Ready (#6613)
## Related links
* Component: [ActionSheet](https://github.com/material-components/material-components-ios/tree/develop/components/ActionSheet)
* Component readiness: [beta-components](https://github.com/material-components/material-components-ios/blob/develop/contributing/beta_components.md)

## Introduction
MDCActionSheet has been in the beta program [since last August](https://github.com/material-components/material-components-ios/pull/4830). I don't foresee any major API changes. 

## Motivation
This will allow clients to use MDCActionSheet through CocoaPods instead of having to clone our repo.

## Proposed solution
Update the Podspec to reflect the `MDCActionSheet` component as a _Ready_ component.
2019-02-13 12:34:35 -05:00
Ian Gordon
ac78d824a9 Bumped version number to 76.1.2. 2019-02-08 14:54:24 -05:00
Ian Gordon
fa686995c7 Bump Version 2019-02-07 13:11:55 -05:00
Ian Gordon
e650856240 Bumped version number to 76.1.0. 2019-02-06 17:49:09 -05:00
Robert Moore
68794ae90a Bumped version number to 76.0.0. 2019-01-30 13:17:41 -05:00
Robert Moore
1b98e1ea21
[BottomNavigation] Move controller out of /beta. (#6501)
Instead of having separate `/beta` file paths for beta code, the beta files
can be excluded from CocoaPods. Also adding targets to bazel since it was trying to compile all of the source files (and failing).

Part of #4160
2019-01-29 11:33:51 -05:00
Eric Lee
d8fed59535 [BottomNavigation] Elevates the BottomNavigationBarController to beta status and re-adds its unit tests. (#6311)
Contributes to #4160
2019-01-24 07:47:40 -05:00
Rob Moore
a7cb1d6a2e Bumped version number to 75.0.1. 2019-01-23 15:33:37 -05:00
Rob Moore
e13c926089 Bumped version number to 75.0.0. 2019-01-23 10:29:37 -05:00
Rob Moore
f843c11da4 Bumped version number to 74.0.0. 2019-01-16 13:16:29 -05:00
Yarden Eitan
c3b0246662 Merge branch 'release-candidate' into develop 2019-01-11 17:01:11 -05:00
Yarden Eitan
a622aa5a8d update changelog and version bump 2019-01-11 15:46:47 -05:00
Andrew Overton
056e4701f0
Make pod install work on Cocoapods 1.6.0.beta.2 (#5966)
# Original PR description:

On Cocoapods version 1.6.0 beta 2 we get an error on pod install because certain test targets don't have any sources to compile. This PR adds some skeleton unit test source files to get that working. Is everyone okay with these (for now) basically empty files?

Closes #5825

# FInal PR description:

The original aim of this PR was to get the project working with the Cocoapods 1.6 beta.

I initially didn't know where to begin getting it to work, so I used `pod lib lint` to get answers. `pod lib lint` had issues with the following things:

1. test_specs not having any sources to compile. This was due to our pattern of putting unit test test_specs inside of parent test_specs that didn't have anything else.

To address this I did two things. First, I moved away from the nested test_spec pattern. Now, instead of "Subspec/tests/unit_tests" it's "Subspec/UnitTests". This is more in line with the style Cocoapods uses [here](http://blog.cocoapods.org/CocoaPods-1.6.0-beta/). Secondly, I added some dummy files for things like UIMetrics and MaterialMath.

2. Importing headers across modules without using framework style imports.

I added framework style imports. This required some additional rewrite rules in the kokoro script.

3. Dependencies across subspecs being implicit.

I made them explicit by adding dependency statements to the podspecs where needed. 

`pod lib lint` didn't take issue with this, but I also saw that `MaterialComponents` was depending on `MaterialComponentsBeta` in various places. For example, all the theming extensions were in beta, but the tests for them weren't. I moved the tests to test_specs within the beta extensions. This required some directory structure changes. These changes then required some BUILD file changes. Making BUILD file changes made me realize that some swift unit tests weren't being accounted for by bazel. I took care of this too.

This PR also fixes some swift debugging stuff--"po" statements that weren't working before now do. I didn't rigorously verify this, but I also think this PR will lead to faster clean build times? It kinda seemed like it was while I was working on it.
2019-01-11 10:08:05 -05:00
Yarden Eitan
b9d3045d37 Bumped version number to 73.1.0. 2019-01-08 12:58:43 -05:00
Yarden Eitan
1753e12717
[Ripple] Ripple implementation + example + unit tests (#6174)
This PR includes the ripple implementation that is up to date with Material design and motion guidelines.

A ripple by definition is a visual form of feedback for touch events providing users a clear signal that an element is being touched. The ripple effect is a core functionality for components such as buttons, cells, cards, etc.

This will eventually succeed the outdated Ink component, and is currently being added under MaterialComponentsBeta.

There are unit tests and an example included to this PR.

The full design doc can be found here: go/ripple-ios-revisited
2019-01-02 19:31:03 -05:00
rami-a
d442f89028
[Chips] Create theming extension for Chips (#6087)
### Context
As the team pivots to using theming within extensions we continue this work with Chips.

### The problem
We currently do not theme chips using a theming extension

### The fix
* Add theming extension for MDCChipView
* Write unit tests for new extension

In follow-up PRs, I will update the existing examples to utilize the new extension and write snapshot tests as well.

### Bug
Part of #6083
2018-12-20 16:13:09 -05:00
rami-a
b380bca14e Fix for release-candidate merge issue with develop (#6068)
It appears when the release-candidate was merged back into develop, some code changes were lost/reverted unintentionally. 

See for the details here: 026a2005e7

This change brings all the necessary changes back into develop. Specifically around the cards theming extension and the updated Card theming examples.

This issue appears to stem from the fact that these 2 PRs landed in develop after the release-candidate was branched:
#6048
#6049
2018-12-19 23:14:29 -05:00
Robert Moore
970de21252
{Beta} Fix name of "fake" Beta header. (#6055)
There is a "fake" header that always exists for the "Beta" podspec target. It
was accidentally not renamed from "Alpha" in an earlier PR that changed Alpha
to Beta.
2018-12-19 22:43:19 -05:00
Rob Moore
b29796f996 Release bump (again!) 2018-12-19 15:00:07 -05:00
Robert Moore
11a74d41ac Revert "[Cards] Add theming extension for Cards component (#6033)"
This reverts commit fdaf872c605cab44a4579cb8b7f0ea168c445318. The
container scheme import is missing in a Swift example.

```
material_components_ios/components/Cards/examples/EditReorderCollectionViewController.swift:38:24 use of undeclared type 'MDCContainerScheming'
  var containerScheme: MDCContainerScheming {
                       ^~~~~~~~~~~~~~~~~~~~
```
Reopens #6030
2018-12-19 14:59:14 -05:00
rami-a
fdaf872c60
[Cards] Add theming extension for Cards component (#6033)
### Context
As the team pivots to using theming within extensions we continue this work with Cards.

### The problem
We currently do not theme cards using a theming extension

### The fix
* Add theming extension for MDCCard and MDCCardCollectionCell
* Write unit tests for new extension
* Update existing examples to utilize the extension

### Bug
Closes #6030 

### Screenshots
Everything should be exactly the same visually.

| Before | After |
| - | - |
|![simulator screen shot - iphone 7 - 2018-12-17 at 13 59 52](https://user-images.githubusercontent.com/2364772/50110092-65f39680-0207-11e9-9a32-02161f7b2df4.png)|![simulator screen shot - iphone 7 - 2018-12-17 at 14 01 51](https://user-images.githubusercontent.com/2364772/50110130-7dcb1a80-0207-11e9-83d9-53bc98ad374b.png)|
2018-12-18 09:38:37 -05:00
featherless
73bdc03c2b
[automated] Rename MaterialComponentsAlpha to MaterialComponentsBeta. (#6018)
This is an automated change generated by replacing all instances of MaterialComponentsAlpha with MaterialComponentsBeta. This is not a breaking change because changes to Alpha/Beta components (including renaming them) are not considered breaking.

The MaterialComponentsAlpha podspec was mistakenly named Alpha, when what we meant was more close to Beta. The distinction is that Alpha components are not expected to be used by clients, while Beta components are.
2018-12-14 10:47:31 -05:00