profile
viewpoint
SwiftKick Mobile SwiftKickMobile Austin, TX http://www.swiftkickmobile.com Mobile app design and development agency

startedSwiftKickMobile/SwiftMessages

started time in an hour

startedSwiftKickMobile/SwiftMessages

started time in 2 hours

startedSwiftKickMobile/SwiftMessages

started time in 3 hours

issue commentSwiftKickMobile/SwiftMessages

CardView doesn't center pure textural content

The nibs are intended to supply basic form factors only. Supporting all of the permutations of form factor and content wouldn't be practical IMO. The nibs are provided so you can copy them into your project and easily modify them to suit your specific needs.

In any case, I'm fine with changing the alignment to Fill. Did you foresee an issue with that?

danielsaidi

comment created time in 6 hours

issue commentSwiftKickMobile/SwiftMessages

Crash in installMaskingView

Ugh...18% of users is the worst kind of crash since my chance of reproducing it is very slim :(

Any chance that they're jailbroken? Or any other commonalities? I've had crashes with jailbroken users in the past.

amaurydavid

comment created time in 6 hours

startedSwiftKickMobile/SwiftMessages

started time in 9 hours

startedSwiftKickMobile/SwiftMessages

started time in 10 hours

startedSwiftKickMobile/SwiftMessages

started time in 13 hours

startedSwiftKickMobile/SwiftMessages

started time in 13 hours

startedSwiftKickMobile/SwiftMessages

started time in 15 hours

startedSwiftKickMobile/SwiftMessages

started time in 18 hours

PR opened SwiftKickMobile/SwiftMessages

Add plan centered text card view

I'm not sure if this is the way you prefer to solve it, but this fixes https://github.com/SwiftKickMobile/SwiftMessages/issues/355 by introducing a new message type.

+149 -5

0 comment

4 changed files

pr created time in 18 hours

startedSwiftKickMobile/SwiftMessages

started time in 19 hours

issue openedSwiftKickMobile/SwiftMessages

CardView doesn't center pure textural content

We use CardView.xib to display a pure text message, without an icon, title or button. We set the body label's text alignment to center, since we want the text centered in the card.

The problem is that the content is only centered when the text is long enough to wrap over two lines. We can fix this by opening CardView.xib and set Alignment to Fill for the vertical, innermost stack view.

We considered a couple of ways this could be done, but ended up in that it would be nice to have a "pure text card" view, for which the content is centered. We will add such a xib to our project now, but it would be nice if the library could include such a xib as well.

created time in 19 hours

startedSwiftKickMobile/SwiftMessages

started time in 19 hours

fork jiblatech/SwiftMessages

A very flexible message bar for iOS written in Swift.

fork in 20 hours

startedSwiftKickMobile/SwiftMessages

started time in 21 hours

startedSwiftKickMobile/SwiftMessages

started time in a day

startedSwiftKickMobile/SwiftMessages

started time in a day

startedSwiftKickMobile/SwiftMessages

started time in a day

issue commentSwiftKickMobile/SwiftMessages

Crash in installMaskingView

I have a similar issue in 7.0.0.

Fatal Exception: NSGenericException 0 CoreFoundation 0x1aa285c30 __exceptionPreprocess 1 libobjc.A.dylib 0x1a9fa00c8 objc_exception_throw 2 Foundation 0x1aa55eb8c -[NSLayoutConstraint isActive] 3 MyApp 0x105841d2c installMaskingView #1 (containerView:) in Presenter.install() (<compiler-generated>) 4 MyApp 0x1058414e0 Presenter.install() + 412 (Presenter.swift:412) 5 MyApp 0x10583f298 Presenter.show(completion:) (<compiler-generated>) 6 MyApp 0x105848a58 closure #1 in SwiftMessages.dequeueNext() + 552 (SwiftMessages.swift:552) 7 MyApp 0x104ce8554 thunk for @escaping @callee_guaranteed () -> () (<compiler-generated>) 8 libdispatch.dylib 0x1a9f2bbb0 _dispatch_call_block_and_release 9 libdispatch.dylib 0x1a9f2d00c _dispatch_client_callout 10 libdispatch.dylib 0x1a9f38cd8 _dispatch_main_queue_callback_4CF 11 CoreFoundation 0x1aa200e20 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ 12 CoreFoundation 0x1aa1fbb7c __CFRunLoopRun 13 CoreFoundation 0x1aa1fb098 CFRunLoopRunSpecific 14 GraphicsServices 0x1b4365534 GSEventRunModal 15 UIKitCore 0x1ae31b7ac UIApplicationMain 16 MyApp 0x104cb4c90 main + 15 (main.m:15) 17 libdyld.dylib 0x1aa07af30 (Missing)

It crashes with the exception:

Unable to activate constraint with anchors <NSLayoutYAxisAnchor:0x281594b80 "SwiftMessages.MaskingView:0x1564e2a60.bottom"> and <NSLayoutYAxisAnchor:0x281594d80 "UITabBar:0x151d09c30.top"> because they have no common ancestor. Does the constraint or its anchors reference items in different view hierarchies? That's illegal.

My SwiftMessages are displayed using the block creation pattern SwiftMessages.show(config, {}), inside UIViewController subclasses that are the root view controller of a UINavigationController that is in the viewControllers of a UITabBarController.

This happens to approximately 0.18% of users in production. I've not yet been able to reproduce it myself.

I'm upgrading to 7.0.1 this release and will update.

amaurydavid

comment created time in a day

startedSwiftKickMobile/SwiftMessages

started time in a day

fork emersonsoftware/SwiftMessages

A very flexible message bar for iOS written in Swift.

fork in a day

startedSwiftKickMobile/SwiftMessages

started time in a day

startedSwiftKickMobile/SwiftMessages

started time in 2 days

startedSwiftKickMobile/SwiftMessages

started time in 2 days

startedSwiftKickMobile/SwiftMessages

started time in 2 days

startedSwiftKickMobile/SwiftMessages

started time in 2 days

issue commentSwiftKickMobile/SwiftMessages

Accessibility for View Controllers Presented Via SwiftMessagesSegue

Great. Will close when I release the change.

patmalt

comment created time in 3 days

issue commentSwiftKickMobile/SwiftMessages

Accessibility for View Controllers Presented Via SwiftMessagesSegue

This fix worked for me! Thanks

patmalt

comment created time in 3 days

issue commentSwiftKickMobile/SwiftMessages

Accessibility for View Controllers Presented Via SwiftMessagesSegue

@patmalt @dtashkandi I pushed a fix for this to the head of master if you want to try it out and let me know.

Previously, if a view that didn't adopt AccessibleMessage was ignored by Voice Over. With meh fix, these views are not ignored by Voice Over and are responsible for their own accessibility. I think this is the ideal behavior for view controllers. I don't recommend putting view controllers behind the AccessibleMessage protocol, but you can do that if you want to (as you've done above).

patmalt

comment created time in 3 days

push eventSwiftKickMobile/SwiftMessages

Timothy Moose

commit sha c0d69eecf6a0a4130c25aee4d1e303db2b0ab082

Fix accessibility for view controllers

view details

push time in 3 days

startedSwiftKickMobile/SwiftMessages

started time in 3 days

startedSwiftKickMobile/SwiftMessages

started time in 3 days

startedSwiftKickMobile/SwiftMessages

started time in 3 days

startedSwiftKickMobile/SwiftMessages

started time in 4 days

startedSwiftKickMobile/SwiftMessages

started time in 4 days

startedSwiftKickMobile/SwiftMessages

started time in 5 days

startedSwiftKickMobile/SwiftMessages

started time in 5 days

startedSwiftKickMobile/SwiftMessages

started time in 6 days

startedSwiftKickMobile/SwiftMessages

started time in 6 days

issue commentSwiftKickMobile/SwiftMessages

Accessibility for View Controllers Presented Via SwiftMessagesSegue

import SwiftMessages

class SwiftMessagesBottomSegue: SwiftMessagesSegue {
    init(source: UIViewController, destination: UIViewController) {
        super.init(identifier: nil, source: source, destination: destination)
        configure(layout: .bottomCard)
        self.messageView = MyNewBaseView(destination)
    }
}

class MyNewBaseView: BaseView, AccessibleMessage {
    var uiViewController: UIViewController?

    init(_ destination: UIViewController) {
        uiViewController = destination
        super.init(frame: destination.view.frame)
    }

    required init?(coder aDecoder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    var accessibilityMessage: String? = "System Mode Bottom Sheet"
    open var additonalAccessibilityElements: [NSObject]? {
        var elements: [NSObject] = []
        func getAccessibleSubviews(view: UIView) {
            for subview in view.subviews {
                if subview.isAccessibilityElement {
                    elements.append(subview)
                } else {
                    getAccessibleSubviews(view: subview)
                }
            }
        }
        getAccessibleSubviews(view: self.backgroundView)
        return elements
    }
    var accessibilityElement: NSObject?
}

I believe I copied the accessibility code from another part of SwiftMessages

patmalt

comment created time in 7 days

issue commentSwiftKickMobile/SwiftMessages

changing the hight of presented view

SwiftMessages isn’t going to automatically perform animated height changes for you, but you should be able to do your own animations. Navigation controllers don’t naturally size to fit the content of their child view controllers. So you’ll have to explicitly set and animate the UINavigationController‘s height.0

embassem

comment created time in 7 days

issue commentSwiftKickMobile/SwiftMessages

overrideUserInterfaceStyle ignored when using SwiftMessages.show(config:, view:) with presentationContext = .window

Thanks for bringing this up. I need to add something to handle this.

JanBrinker

comment created time in 7 days

issue commentSwiftKickMobile/SwiftMessages

Accessibility for View Controllers Presented Via SwiftMessagesSegue

@patmalt can you please share your subclass of BaseView?

patmalt

comment created time in 7 days

fork decidion/SwiftMessages

A very flexible message bar for iOS written in Swift.

fork in 7 days

issue openedSwiftKickMobile/SwiftMessages

overrideUserInterfaceStyle ignored when using SwiftMessages.show(config:, view:) with presentationContext = .window

So I guess we're all currently in the phase of stumbilng all over weird kinks of iOS 13. The app I'm working on right now is not dark mode ready, so we overrode the user interface style in our app delegate:

if #available(iOS 13.0, *) {
    window?.overrideUserInterfaceStyle = .light
}

This does the trick, however at one place we use SwiftMessages like this:

private func openAmountPicker(withInitialAmount initialAmount: Int) {
    var config = SwiftMessages.Config()
    config.presentationStyle = .bottom
    config.presentationContext = .window(windowLevel: .statusBar) // <-- the important bit
    config.duration = .forever
    config.dimMode = .gray(interactive: true)
    config.interactiveHide = false
    config.preferredStatusBarStyle = .lightContent

    let picker = AmountPicker() // <-- view containing a picker view and a close button
    picker.initialAmount = initialAmount
    picker.delegate = self
    SwiftMessages.show(config: config, view: picker)
}

Now if my phone is set to dark mode iOS will try to use dark mode colors for UI elements inside even though I overrode the user interface style for the window. If I use .view(someView) for presentationContext the label colors in the view are back to what they should be as the someView is inside the window defined in the AppDelegate and that is forced to .light mode.

So I guess that SwiftMessages creates a new window for .window and doesn't copy over the overrideUserInterface value.

Now the question is whether this is a bug or not. Difficult to say, but it definitely is behavior one wouldn't neccessarily expect.

created time in 7 days

fork Damon-cw/SwiftMessages

A very flexible message bar for iOS written in Swift.

fork in 7 days

startedSwiftKickMobile/SwiftMessages

started time in 7 days

startedSwiftKickMobile/SwiftMessages

started time in 7 days

issue openedSwiftKickMobile/SwiftMessages

changing the hight of presented view

I'd like to change the height when navigating. I'm presenting navigation Controller with VC1 as root with as a bottom Message with the height of 350 when some action in VC1 happened it will push VC2 witch should change the height to 500 if push VC3 height is 400 if pop to VC1 height is 350 again and so on is this behavior applicable?

created time in 7 days

startedSwiftKickMobile/SwiftMessages

started time in 7 days

issue commentSwiftKickMobile/SwiftMessages

Accessibility for View Controllers Presented Via SwiftMessagesSegue

I do not believe this to be true

patmalt

comment created time in 7 days

issue commentSwiftKickMobile/SwiftMessages

Accessibility for View Controllers Presented Via SwiftMessagesSegue

Hmm. I think ideally you’d get the view controller’s default voice over behavior. I’ll need to look into it.

patmalt

comment created time in 7 days

issue commentSwiftKickMobile/SwiftMessages

Accessibility for View Controllers Presented Via SwiftMessagesSegue

Yes, so we can use Voice Over on view controllers we present with SwiftMessagesSegue

patmalt

comment created time in 7 days

issue commentSwiftKickMobile/SwiftMessages

Accessibility for View Controllers Presented Via SwiftMessagesSegue

I’m not sure I’d use AccessibleMessage with view controllers at all due to their complexity. AccessibleMessage was meant to help improve voice over for simple views, such as reading the title + body out as a single unit. Was there a specific reason you wanted to use AccessibleMessage?

patmalt

comment created time in 7 days

issue openedSwiftKickMobile/SwiftMessages

Accessibility for View Controllers Presented Via SwiftMessagesSegue

SwiftMessagesSegue's messageView is a BaseView, and since BaseView does not conform to AccessibleMessage, presented view controllers will not be accessible via Accessibility Inspector or Voice Over.

I implemented a subclass of BaseView that does conform to AccessibleMessage, and set it to the messageView property of SwiftMessagesSegue. This should work in most cases...

Expect where the presented view controller is wrapped inside of a UINavigationController.

During the install phase of Presenter, the UINavigationController's rootViewController is not added to the messageView's view hierarchy yet, and the elements are also not exposed.

Any thoughts or suggestions?

created time in 7 days

startedSwiftKickMobile/SwiftMessages

started time in 8 days

fork Extendas/SwiftMessages

A very flexible message bar for iOS written in Swift.

fork in 8 days

startedSwiftKickMobile/SwiftMessages

started time in 8 days

startedSwiftKickMobile/SwiftMessages

started time in 8 days

startedSwiftKickMobile/SwiftMessages

started time in 9 days

startedSwiftKickMobile/SwiftMessages

started time in 9 days

pull request commentSwiftKickMobile/SwiftMessages

Inserted a conditional check to support Xcode 10.3

@epastoor How does 7.0.0 not work for you? And how would this PR fix that?

TizianoCoroneo

comment created time in 9 days

pull request commentSwiftKickMobile/SwiftMessages

Inserted a conditional check to support Xcode 10.3

6.0.2 works but 7.0.0 doesn’t work for me on Xcode 10.1.

I’m running high Sierra so I can’t upgrade Xcode any higher until I get a new machine.

TizianoCoroneo

comment created time in 9 days

fork persiona/SwiftMessages

A very flexible message bar for iOS written in Swift.

fork in 10 days

issue closedSwiftKickMobile/SwiftMessages

Use of undeclared type 'UIWindowScene'

When I try to build my Xcode application, I get the error Use of undeclared type 'UIWindowScene' on line 44 of WindowViewController.

I'm using Xcode V10.2 IOS V 10.2

Can someone please help?

closed time in 10 days

naissa12

issue commentSwiftKickMobile/SwiftMessages

Use of undeclared type 'UIWindowScene'

Upgrade to Xcode 11 or downgrade to SwiftMessages 7.0.0.

naissa12

comment created time in 10 days

issue openedSwiftKickMobile/SwiftMessages

Use of undeclared type 'UIWindowScene'

When I try to build my Xcode application, I get the error Use of undeclared type 'UIWindowScene' on line 44 of WindowViewController.

I'm using Xcode V10.2 IOS V 10.2

Can someone please help?

created time in 10 days

startedSwiftKickMobile/SwiftMessages

started time in 11 days

startedSwiftKickMobile/SwiftMessages

started time in 11 days

startedSwiftKickMobile/SwiftMessages

started time in 11 days

startedSwiftKickMobile/SwiftMessages

started time in 11 days

startedSwiftKickMobile/SwiftMessages

started time in 13 days

fork hut2016/SwiftMessages

A very flexible message bar for iOS written in Swift.

fork in 13 days

startedSwiftKickMobile/CustomSegueDemo

started time in 13 days

startedSwiftKickMobile/SwiftMessages

started time in 13 days

fork StalkerRus/SwiftMessages

A very flexible message bar for iOS written in Swift.

fork in 14 days

fork GaneshManickam/SwiftMessages

A very flexible message bar for iOS written in Swift.

fork in 14 days

fork insightmind/SwiftMessages

A very flexible message bar for iOS written in Swift.

fork in 15 days

startedSwiftKickMobile/SwiftMessages

started time in 15 days

startedSwiftKickMobile/SwiftMessages

started time in 15 days

fork MonumentLabs/SwiftMessages

A very flexible message bar for iOS written in Swift.

fork in 15 days

startedSwiftKickMobile/SwiftMessages

started time in 16 days

startedSwiftKickMobile/SwiftMessages

started time in 16 days

fork alex-balobanov/SwiftMessages

A very flexible message bar for iOS written in Swift.

fork in 16 days

startedSwiftKickMobile/SwiftMessages

started time in 16 days

startedSwiftKickMobile/SwiftMessages

started time in 16 days

issue commentSwiftKickMobile/SwiftMessages

`windowLevel` in iOS 13

@FIndustries It only has an effect when you’re displaying a message in its own window.

tchambers3

comment created time in 17 days

issue commentSwiftKickMobile/SwiftMessages

`windowLevel` in iOS 13

I don't know if I'm wrong but the prefersStatusBarHidden option doesn't seem to have any effect on iOS 13.

tchambers3

comment created time in 17 days

pull request commentSwiftKickMobile/SwiftMessages

Inserted a conditional check to support Xcode 10.3

@epastoor any reason why you don’t just use 7.0.0? I don’t see the point in doing another release when there’s already a workaround.

TizianoCoroneo

comment created time in 17 days

fork sisomollov/SwiftMessages

A very flexible message bar for iOS written in Swift.

fork in 17 days

startedSwiftKickMobile/SwiftMessages

started time in 17 days

startedSwiftKickMobile/SwiftMessages

started time in 17 days

startedSwiftKickMobile/SwiftMessages

started time in 17 days

startedSwiftKickMobile/SwiftMessages

started time in 17 days

pull request commentSwiftKickMobile/SwiftMessages

Inserted a conditional check to support Xcode 10.3

I’m developing an app but have an older Mac that can’t run the latest Xcode. Having this flag would let me develop for a little while longer until I can afford a newer Mac running the latest Xcode.

TizianoCoroneo

comment created time in 17 days

fork Amy511/SwiftMessages

A very flexible message bar for iOS written in Swift.

fork in 17 days

issue commentSwiftKickMobile/SwiftMessages

iOS 13 issue

No reply from OP. Closing.

petrykDima

comment created time in 17 days

more