• Replies 47 replies
  • Subscribers 22 subscribers
  • Views 5611 views
  • Users 0 members are here
Options
Related

Made some progress on publishing complications!

jim_m_58
over 2 years ago

This is with the 4.2.0 beta1 SDK, the f7 System 6 preview device, and one of my watch apps.  Here's what I see in the sim under Simulation>Complications, when I select the complication.  The app is running in the sim at this point.  The image is the icon I supplied for the complication.  53.10 is the temperature as seen by the app.  A first step!

  • over 2 years ago in reply to FlowState

    so user have to use watch settings and I have to write code to allow him to choose complication (memory, work....)

    and have to save it in storage and user can't choose anything in phone...

    so if I have DF that can display any data I have 2 choices

    1. some data user choses on phone and complication on watch Slight smile

    2. separate DF Slight smile

    3. implement all settings on watch Slight smile

  • over 2 years ago in reply to _psx_

    To answer your question directly, if you already have a Complications.Id for a CIQ complication, you can use it to fetch that complication.

    But the only way to get that CIQ Complications.Id in the first place is to iterate through all installed complications using getComplications().

    At no point will the app UUID or resource ID (index) be exposed to your code, nor can you use them to construct a Complications.Id.

  • over 2 years ago in reply to _psx_

    Yeah, exactly. If you want to use phone settings, the only option is to select native complications.

  • over 2 years ago in reply to _psx_
    _psx_ said:

    so if I have DF that can display any data I have 2 choices

    1. some data user choses on phone and complication on watch

    I think only watchfaces can subscribe to complications.

  • over 2 years ago in reply to FlowState

    And it'd enough  to add one func....

  • over 2 years ago in reply to FlowState

    Yes, I've mentioned about DF on WF

  • over 2 years ago in reply to _psx_
    _psx_ said:
    And it'd enough  to add one func....

    If you mean they should let us construct a Complications.Id from a CIQ app UUID and resource index, I think they purposely don't want to do that for security reasons. Same reason they won't let apps share data by other means. If they already put their foot down and said "apps can't share data", I don't see why they'd open it up now, but only for complications.

    Here the only way for apps to share data is to let the user select a complication from your other app. But you can never be sure if some other dev doesn't have a complication with the same name and icon as yours....

  • over 2 years ago in reply to FlowState

    simple return null, exception "no public" no any problem... without it a lot of code...

    I can use exitto and have to know id of app the same is with the id of app and number of complication

  • over 2 years ago in reply to _psx_
    _psx_ said:
    I can use exitto and have to know id of app the same is with the id of app and number of complication

    Yeah that's a good point and I thought of that too.

    You can file a bug report / enhancement request. Seems to me it was done on purpose tho. Since it's still in beta, maybe it's not too late to change.

    Maybe the compromise is you can construct a Complications.Id from app UUID and resource index (as you implied), but you still can't read those fields in an existing Id (I think you also implied this.)