flutter/dev/integration_tests/ios_add2app
Jacob MacDonald 6399be62d2
remove flutter_test quiver dep, use fake_async and clock instead (#54125)
## Description

Removes the `flutter_test` dependency on `quiver`, instead using the more targeted `clock` and `fake_async` packages.

## Related Issues

https://github.com/flutter/flutter/issues/53908

## Tests

No changes to tests

## Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes (`[x]`). This will ensure a smooth and quick review process.

- [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
- [x] I signed the [CLA].
- [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
- [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [x] All existing and new tests are passing.
- [x] The analyzer (`flutter analyze --flutter-repo`) does not report any problems on my PR.
- [x] I am willing to follow-up on review comments in a timely manner.

## Breaking Change

Did any tests fail when you ran them? Please read [Handling breaking changes].

- [ ] No, no existing tests failed, so this is *not* a breaking change.
- [x] Yes, this is a breaking change. *If not, delete the remainder of this section.*
   - [x] I wrote a design doc: https://docs.google.com/document/d/1EkkLbECNBwHgddBQAZqEy7iQLTIxR1rgChKzxcLwhio/edit
   - [x] I got input from the developer relations team, specifically from: @RedBrogdon
   - [x] I wrote a migration guide:  https://github.com/flutter/website/pull/3932

<!-- Links -->
[issue database]: https://github.com/flutter/flutter/issues
[Contributor Guide]: https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Test Coverage]: https://github.com/flutter/flutter/wiki/Test-coverage-for-package%3Aflutter
[Flutter Style Guide]: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[Features we expect every widget to implement]: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene
[Handling breaking changes]: https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
2020-04-15 12:10:26 -07:00
..
flutterapp remove flutter_test quiver dep, use fake_async and clock instead (#54125) 2020-04-15 12:10:26 -07:00
ios_add2app License update (#45373) 2019-11-27 15:04:02 -08:00
ios_add2app.xcodeproj Turn on bitcode for integration tests and add-to-app templates (#44633) 2019-11-12 18:00:31 -08:00
ios_add2app.xcworkspace add2app test (#27712) 2019-02-23 09:56:27 -08:00
ios_add2appTests License update (#45373) 2019-11-27 15:04:02 -08:00
.gitignore Remove ios_add2app Pods directory and add to gitignore (#33772) 2019-06-03 14:27:10 -07:00
build_and_test.sh Revert "Revert "Add many more global analyses. (#47875)" (#48080)" (#48081) 2020-01-02 11:47:28 -08:00
Podfile Remove use_modular_headers from Podfiles using libraries (#42872) 2019-10-17 15:26:10 -07:00
README.md Simple repeating word fixes (#51871) 2020-03-03 11:13:07 -08:00

iOS Add2App Test

This application demonstrates some basic functionality for Add2App, along with a native iOS ViewController as a baseline and to demonstrate interaction.

The following functionality is currently implemented:

  1. A regular iOS view controller (UIViewController), similar to the default flutter create template (NativeViewController.m).
  2. A FlutterViewController subclass that takes over full screen. Demos showing this both from a cold/fresh engine state and a warm engine state (FullScreenViewController.m).
  3. A demo of pushing a FlutterViewController on as a child view.
  4. A demo of showing both the native and the Flutter views using a platform channel to interact with each other (HybridViewController.m).
  5. A demo of showing two FlutterViewControllers simultaneously (DualViewController.m).

A few key things are tested here (IntegrationTests.m):

  1. The ability to pre-warm the engine and attach/detatch a ViewController from it.
  2. The ability to use platform channels to communicate between views.
  3. The ability to simultaneously run two instances of the engine.
  4. That a FlutterViewController can be freed when no longer in use (also tested from FlutterViewControllerTests.m).
  5. That a FlutterEngine can be freed when no longer in use.