Posts

Post not yet marked as solved
0 Replies
243 Views
Adding the AppIntent of my app as AppShortcuts to the Shortcuts Apps was easy. This only required an AppShortcutsProvider. However, I am confused how the AppShortcuts are shown in the Shortcuts App. It seems that there are different styles enter image The AppShortcuts of some apps are shown as tiles While shortcuts from other apps are shown as collection of circle icons Some "circle collection" use a default gray background with blue icons Others color or even gradient backgrounds with white icons The only thing I found that might be related to the design is the shortcutTileColor property in the AppShortcutsProvider. However using/changing this property has no effect on how my app's shortcus are shown: On the default gray background / blue icon. Among the different apps on my devices I cannot see any logic which shortcuts are shown as tiles and which as circle icons. Additionally third party apps use colored background or gradients. So there there has to be a way to change this. But how?
Posted
by Agenor.
Last updated
.
Post not yet marked as solved
0 Replies
242 Views
AppIntens can be used as actions when working with Shortcut Automation. iOS offers a bunch of different triggers to start an automation, such as "Time of Day", "Email", "Transaction", etc. Depending on the trigger one can then pass different "Shortcut input" values as parameters to the App Intent. While in many cases the expected type is quite obvious, this is not always the case. An Email type input for example offers Subject, Sender, Recipients, Attachments, Content, Name. Subject will be most likely a String. But is Sender also a String or maybe an IntentPerson? Is Recipients a String (e.g. comma separated) or a collection? Is Attachments a [String], [URL] or [IntentFile]? How to I find out of which types these inputs have? Is there a better way than guessing and trial and error? The documentation provides very little information about supported types in general and I could find nothing about the types used by different triggers. Additionally each "Shortcut input" offers it self as parameter. So the Email type input does not only offer Subject, Sender, etc. as input parameters but also Email. What parameter type does an intent need no accept in order to receive on Email object? Thank you very much for your help.
Posted
by Agenor.
Last updated
.
Post not yet marked as solved
0 Replies
300 Views
The Shortcuts app offers the possibility to trigger shortcuts/intends when a wallet credit card is used and a new transaction is created. I would like to add transaction details to one of my apps and use such a shortcut for it. Other apps do the exact same thing, so this should not be a problem. Adding a shortcut to my app was not a big deal. However, how can this be tested on simulator? When trying to add a new automatization in the Shortcuts app using a wallet transaction as trigger I cannot finish the setup dialog since the Next button is disabled. I assume this is because no card is configured. When trying to add a card in Wallet I just receive that this was not successful. I have connected the simulator to a Sandbox Apple ID account using a region which supports Apple Pay (US). Using a real account does not solve the problem. Any idea how to get this working? Using real transaction within a store could obviously not be the solution for debugging.
Posted
by Agenor.
Last updated
.
Post not yet marked as solved
3 Replies
4.8k Views
I have been trying to understand and utilize intrinsicSize on a custom UIView for some days now. So far with little success. The post is quite long, sorry for that :-) Problem is, that the topic is quite complex. While I know that there might be other solutions, I simply want to understand how intrinsicSize can be used correctly. So when someone knows a good source for a in depth explanation on how to use / implement intrinsicSize you can skip all my questions and just leave me link. My goal: Create a custom UIView which uses intrinsicSize to let AutoLayout automatically adopt to different content. Just like a UILabel which automatically resizes depending on its text content, font, font size, etc. As an example assume a simple view RectsView which does nothing but drawing a given number of rects of a given size with given spacing. If not all rects fit into a single row, the content is wrapped and drawing is continued in another row. Thus the height of the view depends on the different properties (number of rects, rects size, spacing, etc.) This is very much like a UILabel but instead of words or letters simple rects are drawn. However, while UILabel works perfectly I was not able to achive the same for my RectsView. Why intrinsicSize I do not have to use intrinsicSize to achieve my goal. I could also use subviews and add constraints to create such a rect pattern. Or I could use a UICollectionView, etc. While this might certainly work, I think it would add a lot of overhead. If the goal would be to recreate a UILabel class, one would not use AutoLayout or a CollectionView to arrange the letters to words, would one? Instead one would certainly try to draw the letters manually... Especially when using the RectsView in a TableView or a CollectionView a plain view with direct drawing is certainly better than a complex solution compiled of tons of subviews arranged using AutoLayout. Of course this is an extreme example. However, at the bottom line there are cases where using intrinsicSize is certainly the better option. Since UILabel and other build in views uses intrinsicSize perfectly, there has to be a way to get this working and I just want to know how :-) My understanding of intrinsic Size The problem is that I found no source which really explains it... Thus I have spend several hours trying to understand how to correctly use intrinsicSize without little progress. This is what I have learned [from the docs][1]: intrinsicSize is a feature used in AutoLayout. Views which offer an intrinsic height and/or width do not need to specify constraints for these values. There is no guarantee that the view will exactly get its intrinsicSize. It is more like a way to tell autoLayout which size would be best for the view while autoLayout will calculate the actual size. The calculation is done using the intrinsicSize and the Compression Resistance + Content Hugging properties. The calculation of the intrinsicSize should only depend on the content, not of the views frame. What I do not understand: How can the calculation be independent from the views frame? Of course the UIImageView can use the size of its image but the height of a UILabel can obviously only be calculated depending on its content AND its width. So how could my RectsView calculate its height without considering the frames width? When should the calculation of the intrinsicSize happen? In my example of the RectsView the size depends on rect size, spacing and number. In a UILabel the size also depends on multiple properties like text, font, font size, etc. If the calculation is done when setting each property it will be performed multiple times which is quite inefficient. So what is the right place to do it? I will continue the question a second post due to the character limit...
Posted
by Agenor.
Last updated
.
Post not yet marked as solved
4 Replies
1.7k Views
I came across a problem when setting UIDatePicker preferredDatePickerStyle while in Beirut timezone: Create a new, empty iOS 14 Swift project create a new UIDatePicker variable in viewDidLoad of the ViewController at set its preferredDatePicker Style run the app language class ViewController: UIViewController {   override func viewDidLoad() {     super.viewDidLoad()     let datePicker = UIDatePicker()     datePicker.preferredDatePickerStyle = .inline // CRASH   } } This works fine almost all the time. However, when running while Beirut time zone is active, the app will crash: libc++abi.dylib: terminating with uncaught exception of type NSException Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid calculation: number of calculated days is not dividable by the number of days in a week.' Is this a know problem? Is there any workaround to avoid this number of calculated days is not dividable by the number of days in a week error?
Posted
by Agenor.
Last updated
.