[TIMOB-27133] iOS 13: Add support for SF Symbols
GitHub Issue | n/a |
---|---|
Type | New Feature |
Priority | High |
Status | Closed |
Resolution | Fixed |
Resolution Date | 2019-09-02T12:56:45.000+0000 |
Affected Version/s | n/a |
Fix Version/s | Release 8.2.0 |
Components | iOS |
Labels | n/a |
Reporter | Rene Pot |
Assignee | Vijay Singh |
Created | 2019-06-05T15:32:13.000+0000 |
Updated | 2019-09-02T12:57:50.000+0000 |
Description
SF symbols is a new iOS 13 feature that allows developers to use build-in icons (1500 icons!) in iOS apps.
We should allow users to use these icons. They're supposed to replace the system icons up-to iOS 12
Source: https://developer.apple.com/design/human-interface-guidelines/sf-symbols/overview
Hey Guys, I am planning to expose SF symbols via a new API Ti.UI.iOS.systemImage in Titanium. This will be iOS specific. TestCase -
Any suggestion ? Thanks!
Will we be able to use in Alloy - XML Views directly? If so, can you provide a sample code snippet of how that might look/work?
[~amwinsauto] It can be used in Alloy-XML views directly in following way - In alloy.js create -
and use it inside view-
Is this something you are asking for? Main purpose of this API is to provide ability to access System provided 1500 build-in icons in iOS 13+ to developers.
I *guess* that would work. But, in my opinion, it feels like a bandaid or hack. Why not implement it in a manner similar to that of Titanium.UI.iOS.SystemButton? https://docs.appcelerator.com/platform/latest/#!/api/Titanium.UI.iOS.SystemButton With Titanium.UI.iOS.SystemButton, you can do something like: And there are dozens of icons to chose from (see that doc link above). Why not use a similar property and extend to both Labels and Buttons?
https://github.com/appcelerator/titanium_mobile/pull/11050
[~amwinsauto] The use of SF images are not limited to Labels or Button. It can be used in Ti.UI.ImageView, Ti.UI.iOS.Stepper, Ti.UI.Button, ListView etc. I am not sure if parallel to 'setImage' we should add another api which is neither cross platform nor work for < iOS 12. [~jquick] what you think? I have moved the API under Ti.UI.iOS name space as this is iOS only.
I think having an iOS only getter method to fetch the system image (wrapped in a
Ti.Blob
) is good to have in general. I don't think anyone here will question that. The question is what can we do to make this Alloy friendly. I like Vijay's Alloy solution where you can set the image in the view XML via a variable. Since this is an iOS 13 only feature, you'll need a solution for older iOS versions and Android. With his solution, you can easily assign a different image to that variable, making the view XML completely portable. Alternatively, the image variable can be assigned via an Alloy tss file as well.I guess a solution could be to add a PR to alloy to be able to set the new SF symbol directly in Alloy. Perhaps in the same way the
L()
method is supported in tss and xml. [~eharris] any thoughts?[~topener], remember that this is an iOS 13 only feature. So, what should and Alloy function like this do on other platforms and older iOS versions? Return null? The advantage of the way Vijay is doing it is the app developer can implement a fallback-image if needed.
As with every feature we have that only works on specific versions or platforms, the user will have to use platform/if filters.
It probably should throw a warning & return null for anything pre iOS 13, but obviously fail completely on android.
I think I do agree with Rene here. I was thinking about whether Alloy could make the semantic color usage introduced in TIMOB-27126 easier too. With SFSymbols and that, it seems like a lot of peoples application startup will include tacking on their required SFSymbols/colors onto Alloy.Globals/Alloy.Styles. I think something like L could work quite well, we could maybe expose
systemImage
andfetchSemanticColor
to be used in tss/xml. But I don't want to do that bikeshedding in here, I'll open an ALOY ticket for each of those next week.FR Passed for Master (8_2_X). [~vijaysingh] Could you add a PR for 8_3_X?
Without proper constants or Alloy support, this is useless for larger scaled apps since we cannot define 70+ icons in an alloy.js …
merged to master (8.2.0)
[~vijaysingh] Using SDK version
8.2.0.v20190829124255
. I get the following error with test case you mentioned above:^ SDK Version:
8.2.0.v20190902041145