lickability / pinpointkit Goto Github PK

The configuration type should allow the developer to configure:

• Colors
• Fonts
• Text
• Which LogCollector to use (defaults to system log collector)
• Which Sender to use (defaults to mail sender)
• Which Editor to use (defaults to edit view controller)
• Which FeedbackViewer to use
• Which LogViewer to use
• Whether logs should be collected
• Whether logs should be disable-able by the user.
• How Pinpoint is invoked.

• Write down what we’re doing
• Make things consistent
• SwiftLint?

Allow the developer to sign up for UIApplicationUserDidTakeScreenshotNotification to automatically open Pinpoint with the latest screenshot.

All public and internal APIs should be documented. Make a pass at all types missing documentation, e.g. AssetViewModel.

Off the top of my head, the various components that we’d need that can not be extracted from Pinpoint.app would be:

• Initialization/UIWindow gesture recognizer integration
• View controller traversal/presentation
• Launch view controller design and development
• System log consumption
• Delegate protocol design

If you shake while we're already displaying a feedback view controller, it crashes with *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Application tried to present modally an active controller <PinpointKitExample.ViewController: 0x7feff8c333d0>.'

Right now your only option out of editing a screenshot in Pinpoint kit is the X button, which is different than the pinpoint app, and the current alert doesn't make a lot of sense.

When adding text to an area which the keyboard would cover, the editable area shifts up to avoid the keyboard. However, the editor is not restored to its normal state when the keyboard dismisses.

Follow-up to #124

Once we make it simpler (and required) to specify feedback recipients, we’ll need to update the README to fix outdated code in the Usage section.

• A protocol that represents a Sender that can be used to send the feedback.
• A type (struct) that represents a Submission that can be used to gather what is sent. (image, text, app name, etc).
• A concrete MailComposeSender that implements Sender and populates an MFMailComposeViewController

Is there a reason we're only using custom fonts in EditImageViewController and not in FeedbackViewController?

We should figure out what to do with errors, at least for 1.0. My vote is to just print 'em out for now.

• An Editor protocol that we show when the user taps the screenshot from the Feedback screen.
• A concrete implementation of Editor that is Pinpoint’s editor.

A custom window that can detect shake and can be subclassed by the developer that lets the PinpointKit know that it should present (probably via delegation?).

Right now, there's no way to see what the feedback UI looks like until you actually install this into your project. Excited to check it out!

As requested in #19, we should make a sample project that integrates PinpointKit.

These properties on InterfaceCustomization.Appearance are never being used. They should be used to color the components in the editor.

Furthermore, perhaps the editor's view's tintColor should match InterfaceCustomization.Appearance's tintColor. Right now it's the default blue tintColor.

I'm looking to prefill the subject and body with a custom message but don't see an easy way to do so

When following the steps for manual integration assets appear missing when showing PinpointKit's UI.

It would be nice to add a tiny little pitch for Lickability in the README saying that we're available to hire if you want help supporting PinpointKit or working on your app.

On iOS 10, there’s a lot of space between components:

Proposed solutions

• Don't blur any people out
• Blur everyone
• Use a different screenshot without people in them
• Don't use blur annotation

The feedback recipients is left blank on the default PinpointKit instance, and it requires a convoluted series of object initialization just to set a property that should always be set by the app.

It should be possible to do this:

    lazy var window: UIWindow? = ShakeDetectingWindow(frame: UIScreen.mainScreen().bounds, delegate: PinpointKit.defaultPinpointKit)

    func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
        // Override point for customization after application launch.

        PinpointKit.defaultPinpointKit.configuration.feedbackRecipients = ["[email protected]"]
    }

There's currently a TODO for it, but we haven't done it yet.

Description

Ending the editing of text to allow an autocorrect that adds a space can result in a text annotation of the wrong size, hiding some text.

Steps to Reproduce

1. Edit a screenshot
2. Choose the text tool
3. Type two words without the space between them so that autocorrect suggests a correction to add the space
4. Tap outside of the text view or tap the Done button
5. Observe the hidden text
6. Make a change to the text to see that the text is still within the text view

Expected Results

The text view should resize to fit the text post-correction

Actual Results

Autocorrection causes some text to hide

Notes

This occurs in both Pinpoint and PinpointKit

We need a project / workspace to work in. It should be set up in a way that allows the library to eventually be used as either: a Cocoapod, Carthage / manual installation, and eventually Swift Package Manager.

Requirements:

1. Initially iOS 9+. We may chose to support older OSes.
2. iOS only. No Mac or Watch or TV.
3. Asset catalog.
4. Bundle ID should begin with net.lickability if one is needed.

• LogCollector protocol
• LogViewer protocol

Concrete implementations for collection from system NSLog and displaying the logs in a simple scrolling text view that can be pushed onto a nav stack.

There’s an animation issue with status bar hiding when running the example project on iOS 10.

• Determine if this is an iOS 10 SDK bug and file a radar or address the issue.

To reproduce:

• Checkout the swift-2.3 branch
• Run the example app in Xcode 8
• Tap the screenshot to bring up the editor
• Observe the stutter near the status bar and the navigation bar contents slightly overlapping the bar’s bottom border during the transition

The god object. This object takes a Configuration and provides the developer with a way to invoke Pinpoint. See also #4 for discussion.

We should allow them to display in whatever orientation they were taken.

What should the interface from which the app can respond to reports created via PinpointKit look like?

In my quick-and-dirty attempt to rip out the email dependency from BugshotKit, I ended up with a delegate protocol that looks like:

@protocol BugshotKitDelegate

- (BOOL)bugshotKitShouldPresent;

- (void)bugshotKitDidSubmit:(nonnull BSKSubmission *)submission;

@end

@interface BSKSubmission : NSObject

@property (nonatomic, readonly, nonnull) NSString *appName;
@property (nonatomic, readonly, nonnull) NSString *appVersion;
@property (nonatomic, readonly, nonnull) NSString *modelIdentifier;
@property (nonatomic, readonly, nonnull) NSString *systemVersion;
@property (nonatomic, readonly, nonnull) UIImage *screenshot;
@property (nonatomic, readonly, nonnull) NSString *log;

@end

In my implementation of this delegate callback, I present a custom compose sheet that posts to Trello. One tricky part was determining which view controller I should present this Trello composer from. Perhaps the PinpointKit delegate protocol should pass the view controller that it presented itself from, so the delegate can easily make use of it afterwards (I am imagining PinpointKit will recursively walk the view controller hierarchy to determine where it should present from?).

How should PinpointKit be initialized and invoked?

It could be passed a window instance and be responsible for attaching its own gesture recognizers.

class AppDelegate {
    func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
        self.window = UIWindow()
        self.pinpointKit = PinpointKit(window: window)
    }
}

PinpointKit could also take other configuration options that would dictate e.g. which gesture recognizers it attaches to the window. We could also support shaking, though like in BugshotKit, this would require a UIWindow subclass.

• Displays title text, cancel button, and send button
• Displays the current screenshot + annotations
• Allows the user to edit more
• Instructional text
• Outline color
• Log collection on/off
• Way to get to the log viewer

Once we’re completely finished with the release.

What should the screen displayed when PinpointKit is first launched look like? We need an analog for BugshotKit’s:

via @calebd