mateusfccp / magiceye Goto Github PK

Since v0.1.6+1, the Github Actions configured are not passing.

This seems to be because of some analyzer related issues.

How to stream camera and preview Camera stream is you have any idea please tell me

As discussed on #6, although it's not currently viable to provide a way to make burst capture of images, it is possible to provide a way to take photos sequentially asynchronously.

This will be made by, instead of returning a Future<String> containing the path to the taken picture, provide a way to pass a Stream<String> where the MagicEye page will add each taken photo.

This will, possibly, require changes on the API, making it a breaking change.

I took a photo, and then got an exception.

The getter 'value' was called on null.
Receiver: null
Tried calling: value

The relevant error-causing widget was
    MaterialApp 
lib/main.dart:20
When the exception was thrown, this was the stack
#0      Object.noSuchMethod  (dart:core-patch/object_patch.dart:53:5)
#1      CircleButton.build 
package:magiceye/…/extra/circle_button.dart:29
#2      StatelessElement.build 
package:flutter/…/widgets/framework.dart:4291
#3      ComponentElement.performRebuild 
package:flutter/…/widgets/framework.dart:4223
#4      Element.rebuild 
package:flutter/…/widgets/framework.dart:3947
...
════════════════════════════════════════════════════════════════════════════════

════════ Exception caught by widgets library ═══════════════════════════════════
The getter 'value' was called on null.
Receiver: null
Tried calling: value
The relevant error-causing widget was
    MaterialApp 

calling value on null.

class CircleButton extends StatelessWidget {
final IconData icon;
final void Function() onPressed;
final BehaviorSubject orientationStream;

const CircleButton({
Key key,
@required this.icon,
this.onPressed,
this.orientationStream,
}) : assert(icon != null),
super(key: key);

Widget build(BuildContext context) {
Tuple2<int, int> orientations = Tuple2(0, 0);

return Circle(
  radius: 25,
  child: StreamBuilder<DeviceDirection>(
    initialData: orientationStream.value,    <-- orientationStream is null

Dart 2.7 released it's null-safety preview.

With this feature, Dart will be able to make all the null checks on compile-time instead of runtime, which is safer.

This experimental work has started on nnbd branch, and is not stable.

Currently, the CameraPreview is aligned to the bottom.

When a device has an higher aspect ratio than the camera's, a black area will appear at the top, in the remaining space.

This is not that bad. However, MagicEye could handle it better, like Android default camera does.

Reference

My device (Xiaomi Mi 2 Lite) has a aspect ratio of 18:9. This is how Android camera handle aspect ratios:

18:9: When the camera matches the device aspect ratio, the preview is fullscreened.

16:9: When the camera aspect ratio is a little lower, the top control area becomes black, and the bottom remains as in 18:9.

4:3: When the aspect ratio is considerably lower, both top and bottom control areas become black and the preview is in between them.

Issue

The main issue on implementing this is the consideration about control layers. I can make the default camera layer behave well without much effort. However, what if someone would want to provide a custom control layer where all the controls should be at the bottom or top, for instance?

Considering this, it's possible to:

1. Ignore the issue. This is easier and won't break anything.
2. Provide a way to control the preview positioning with the control layer API. This takes more time and may result on a more complex API, or even API breakage.

The current example is stable and works as it is. However, it has only the simplest configuration possible.

It would be nice to have an example with diverse MagicEye possibilities, to show a little more of it's potential and help newcomers with more complex cases.

Some kind of regressions may be prevented by writing tests that reproduce the default behavior of the component.

Of course, it's not a trivial task to cover all the cases, but the simplest ones, like the regression of #3, could be prevented by the pipeline.

Said so, we may use the example itself to reproduce the expected simple behaviors of the camera.

Hi there,

Looks like a fantastic package! I was wondering if it's possible to take multiple photos without actually leaving the camera screen?

I'm working on an app where the user may want to take multiple photos at once (similar to iOS burst mode).

Thanks!
James