-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add basic widget for iOS14 #31
Conversation
Really cool contribution, I hope the team considers accepting this feature! @alopezh |
Great contribution! As a minor UI concern, I would suggest adhering to Apple's Human Interface Guidelines and changing SwiftUI's Capsule() shape for a ContainterRelativeShape() in the widget view so the corner radii of both views are concentric. Per the guidelines:
|
Awesome! |
It's better now. Thanks @Androp0v |
b9e1d18
to
366e60b
Compare
Branch has been rebased onto develop for updates |
42912b9
to
4251fb2
Compare
…ses: directly to repository.
4251fb2
to
d9840e1
Compare
Closed due to years of inactivity. At least, we tried... |
Purpose
The purpose of this PR is to quickly and easily obtain the most important information from RadarCOVID, in the form of a Widget for iOS14.
Approach
Obtaining the values directly from the
exposure
andpreferences
repositories, the idea is to build a simple widget that provides the basic exposure information and last update date, as well as the status (active or inactive) of RadarCOVID.Since I do not have access to the original development account, and the entitlements to develop applications of this type are limited, I have created a fictitious group of applications called
group.es.gob.radarcovid
, which should be changed at will once this PR is approved.On the other hand, a change has been introduced to create a suite of
UserDefaults
without using the bundle name. You can see this change in the structConfig
, in which a new static property calleduserDefaultsSuiteName
appears.Some images
Black spots
Since translations are automated server-side, texts has been hardcoded. This must be fixed if this feature goes on production.
I made a mistake pulling out the branch for this job and had to rebase with
git rebase --onto
to isolate this branch. That is why the commit date is not correct.It would be nice to do