I recently launched an iOS 14 Widget for my app. In testing everything seemed a-okay but on launch I am having inconsistent behaviour. On some devices the widget loads as just black, on other devices it only loads the placeholder content and on some devices it works as intended. The behaviour exhibited, good or bad, is consistent in the Add Widget Screen and when it's added to the Home Screen. On the devices where my widget does not work, other widgets do work.
The content in the Widget only changes when something is changed in the app thus I call WidgetCenter.shared.reloadAllTimelines() in the SceneDelegate when sceneWillResignActive is called. The expected behaviour is that when the user backgrounds the application the widget will update. On the devices that show black or placeholder content this Widget Center Update does not work, on the devices where it does work the update function works as expected.
This is the code for my Widget:
struct ThisWeekProvider: TimelineProvider {
func placeholder(in context: Context) -> ThisWeekEntry {
return ThisWeekEntry(date: Date(), thisWeekJSON: getDefaultTimeSummaryJSON())
}
func getSnapshot(in context: Context, completion: #escaping (ThisWeekEntry) -> ()) {
var thisWeekData = TimeSummaryJSON()
if context.isPreview {
thisWeekData = getThisWeekData()
} else {
thisWeekData = getThisWeekData()
}
let entry = ThisWeekEntry(date: Date(), thisWeekJSON: thisWeekData)
completion(entry)
}
func getTimeline(in context: Context, completion: #escaping (Timeline<Entry>) -> ()) {
let entries: [ThisWeekEntry] = [ThisWeekEntry(date: Date(), thisWeekJSON: getThisWeekData())]
let timeline = Timeline(entries: entries, policy: .after(entries[0].thisWeekJSON.endDate))
completion(timeline)
}
}
struct ThisWeekEntry: TimelineEntry {
let date: Date
let thisWeekJSON: TimeSummaryJSON
}
struct ThisWeekWidgetEntryView : View {
var entry: ThisWeekProvider.Entry
var body: some View {
// Generate View
// Use data from 'entry' to fill widget
}
struct ThisWeekWidget: Widget {
let kind: String = K.thisWeekWidget
var body: some WidgetConfiguration {
StaticConfiguration(kind: kind, provider: ThisWeekProvider()) { entry in
ThisWeekWidgetEntryView(entry: entry)
}
.configurationDisplayName("this_week_widget".localized())
.description("this_week_description".localized())
.supportedFamilies([.systemSmall])
}
}
The custom data type 'TimeSummaryJSON' is as follows:
struct TimeSummaryJSON: Codable {
var labourIncome: String = "$0.00"
var equipmentIncome: String = "$0.00"
var days: String = "0"
var hours: String = "0"
var endDate: Date = Date()
var settingsFirstDayOfWeek: String = K.monday
var localeFirstDayOfWeek: Bool = false
}
The custom function that retrieves the data 'getThisWeekData()' is as follows:
private func getThisWeekData() -> TimeSummaryJSON {
if let encodedData = UserDefaults(suiteName: AppGroup.shared.rawValue)!.object(forKey: K.thisWeek) as? Data {
if let thisWeekJSON = try? JSONDecoder().decode(TimeSummaryJSON.self, from: encodedData) {
return checkExpiryForCurrentWeek(thisWeekJSON)
} else {
print("Decoding Error - Return Default This Week")
return getDefaultTimeSummaryJSON()
}
} else {
print("No Shared Data - Return Default This Week")
return getDefaultTimeSummaryJSON()
}
}
The process of saving and retrieving the data works like this:
SceneDelegate calls sceneWillResignActive
Data is pulled from the Local Realm Database, calculated and saved into a TimeSummaryJSON
TimeSummaryJSON is encoded and saved to a shared AppGroup
WidgetCenter.shared calls reloadAllTimelines()
Widget decodes JSON data from AppGroup
If the JSON Decode is successful the current user data is shown in the widget, if the JSON Decode fails a default TimeSummaryJSON is sent instead
I've looked over my code quite extensively and read countless forums and it seems that I am doing everything correctly. Have I missed something? Could anyone suggest why the behaviour is inconsistent between devices? I'm well and truly stuck and am not sure what to try next.
Any help you can offer would be kindly appreciated.
Thank you!
I finally got to the bottom of my issue thanks to some help on reddit. The problem was an image I was using was too large in resolution, the large file size capped out the 30MB Memory Limit of Widgets.
The reddit user that helped me had this to say:
'Black or redacted widget means that during loading you hit the 30 mb memory limit.
Also if you're reloading more than one widget at a time, it seems that there's a higher chance you'll hit the memory budget.'
'Forgot to mention that black/redacted widget can also happen if the widget crashes (not necessary due to memory budget). So maybe you have some threading problems or are force unwrapping something that is nil.'
This is the link to the full discussion:
https://www.reddit.com/r/iOSProgramming/comments/mmo5lf/inconsistent_widget_behaviour_between_devices_in/
Related
I have a production-ready app where I need to run some code only on users with the previous versions installed but not on new installations. For instance, if 1.0 is the latest version in the AppStore and 2.0 is the new one that will introduce code that needs to run only on users with version 1.0 but not on new users.
e.g.
if isExistingUser{
// run code
}
What would be the best way to run some code only for existing users? How can one determine whether it's a new or existing user?
Does your app create any data? Maybe files in the Documents directory, or maybe a UserDefaults key? If so, check for the presence of one of those things very early in launch, which will signal to you that this must be an upgrade and you should do your thing.
A lot of people store the app's CFBundleShortVersionString Info.plist key into UserDefaults at launch, which makes it easy to know the last version that was run and let you write the logic of what needs to happen to migrate from that version to the new version. This is something you might want to think about doing in future versions.
I see this often and knowing how to do this can be extremely valuable, especially when doing something like introducing a new feature that changes the experience your previous users had.
There are a few approaches you can take depending on your needs.
Firstly, you could create a boolean variable in your user model class that is set during user registration in the standard user registration flow and indicates that this is a newly created user - and name it something like isNewOnVersionTwo which will indicate this user is a new user on this new version.
Code Example:
class User: Decodable {
var uid: string!
var username: string!
var isNewOnVersionTwo: Bool = false
}
class RegistrationViewController: UIViewController {
var user: User!
var isNewOnVersionTwo: Bool = false
override func viewDidLoad() {
super.viewDidLoad()
user.isNewOnVersionTwo = true
}
}
class HomeViewController: UIViewController {
var user: User!
override func viewDidLoad() {
super.viewDidLoad()
isNewOnVersionTwo == true ? normalInit() : showOldUserAView()
}
func normalInit() {
// Run normal functions for the 'HomeViewController' or do nothing.
}
func showOldUserAView() {
//Do something specific for only old users.
}
}
You can choose whether you want to hold onto this variable permanently or not - it could be useful for tracking the new users you've gained on this version versus the previous versions - and you could send it to your database along with the rest of the data from your user model.
A second and cleaner approach...
Could be to only set the boolean on the very last view controller of the registration flow and pass it to the home view controller when you push the user to the view controller.
Like this:
class ViewControllerOne: UIViewController {
var isNewOnVersionTwo: Bool = false
private func pushToNewViewController() {
let vc = HomeViewController()
vc.isNewOnVersionTwo = true
navigationController?.pushViewController(vc, animated: true)
}
}
class HomeViewController: UIViewController {
var isNewOnVersionTwo: Bool = false
override func viewDidLoad() {
super.viewDidLoad()
isNewOnVersionTwo == true ? normalInit() : showOldUserAView()
}
func normalInit() {
// Run normal functions for the 'HomeViewController' or do nothing.
}
func showOldUserAView() {
//Do something specific for only old users.
}
}
I wouldn't take the approach of using UserDefaults for the few following reasons:
1. Devices occasionally wipe this randomly and it's not as reliable as hardcoding a flag in the source code.
2. UserDefaults isn't available for a few moments on cold app launches / initial startup which can complicate things, varying on when you want to show the older users whatever you want to show them.
Here is what I came up with that I think works for 95-98% of the users. What I'm doing is basically comparing the date when the Documents folder was created and the date when version2 will be released. The only issue I see with this method is for users installing the app between the date you specified as the release date and the actual App Store release date. In other words, if you specify a date of June, 5 as the release date but the app isn't really approved until the 7th, users who installed the app on the 6th will be missed.
Ideally and it's what I will start doing is what #Rudedog suggested, basically saving the versions to keep track of what version a user has.
/// - Returns: Returns true if it's a new user otherwise returns false.
func isExistingUser()->Bool{
var isExistingUser:Bool?
var appInstallationDate:Date?
/// Set the date when the version two is released.
var dateComponents = DateComponents()
dateComponents.year = 2022
dateComponents.month = 06
dateComponents.day = 4
let userCalendar = Calendar.current
let versionsTwoReleaseDate = userCalendar.date(from: dateComponents)
/// Get the date of when the documents folder was created to determine when the app was installed.
let documentsDirectory = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first
if let creationDate = (try? documentsDirectory!.resourceValues(forKeys: [.creationDateKey]))?.creationDate{
appInstallationDate = creationDate
}
/// Compare dates
if appInstallationDate! < versionsTwoReleaseDate!{
// print("It's existing user")
isExistingUser = true
}else{
// print("It's NEW user")
isExistingUser = false
}
return isExistingUser!
}
I've followed along the Apple Developer Code-Along videos (https://developer.apple.com/news/?id=yv6so7ie) as well as looked at this repo with different Widget types (https://github.com/pawello2222/WidgetExamples) in search on how to populate a dynamic intent with items from Core Data.
My question is: How can I used the saved Core Data objects from the user to have them as "filters" or options in widget settings?
My Core Data model is called Favourite and it is a Class Definition CodeGen file.
I have added the Intent target to my project and can get it to appear in the Widget settings, but when I tap in to "Choose" the list is empty. However, in my Core Data there are 3 saved items.
I have tried doing simple things like print(CoreDM.shared.getAllFavourites()) to see if I am even retrieving them all, but not listing in the settings, but the console prints out:
<NextDeparturesIntent: 0x283490bd0> {
favourite = <null>;
}
At this point I'm stuck on understanding on how I can get my Favourites visible and then usable. It seems everything else is hooked up and working or ready but the retrieval.
I have also tried re-adding into the Info.plist of the intent the IntentSupported of the intent's name: NextDeparturesIntentHandling:but that had no success.
Files
Core Data Model - Favourite - FavouritesCDModel
In my Core Data model I have more options but for this example:
UUID
beginName
finishName
Widget Intent - NextDepartures.intentdefinition
This is what has been set up as followed by Apple's Code Along videos:
app-name-intent - IntentHandler.swift
import Intents
class IntentHandler: INExtension, NextDeparturesIntentHandling {
let coreDM = CoreDataManager.shared
func provideFavouriteOptionsCollection(
for intent: NextDeparturesIntent,
with completion: #escaping (INObjectCollection<FavouriteRoutes>?, Error?) -> Void
) {
dump( coreDM.getAllFavourites() ) // <--- debug line
let favouriteRoutes = coreDM.getAllFavourites().map {
FavouriteRoutes(identifier: $0.uniqueId, display: $0.departingStopName!)
}
let collection = INObjectCollection(items: favouriteRoutes)
completion(collection, nil)
}
override func handler(for intent: INIntent) -> Any {
return self
}
}
CoreDataManager
import CoreData
final class CoreDataManager {
static let shared = CoreDataManager()
private init() {}
private let persistentContainer: NSPersistentContainer = {
let container = NSPersistentContainer(name: "FavouritesCDModel")
container.loadPersistentStores(completionHandler: { description, error in
if let error = error as NSError? {
fatalError("Core Data Store failed \(error.localizedDescription)")
}
})
return container
}()
var managedObjectContext: NSManagedObjectContext {
persistentContainer.viewContext
}
func getAllFavourites() -> [Favourite] {
let fetchRequest: NSFetchRequest<Favourite> = Favourite.fetchRequest()
do {
return try managedObjectContext.fetch(fetchRequest)
} catch {
return []
}
}
}
I didn't realise that the app, widget, and other targets are all sandboxed.
I incorrectly assumed everything within the same app ecosystem would be allowed access to the same items.
In order to get the above code to work is adding the file to the App Groups and FileManager.
CoreDataManager
Inside the persistentContainer add in the storeURL and descriptions:
let storeURL = FileManager.appGroupContainerURL.appendingPathComponent("COREDATAFILE.sqlite")
container.persistentStoreDescriptions = [NSPersistentStoreDescription(url: storeURL)]
FileManager+Ext
Create a FileManager extension for the container url:
extension FileManager {
static let appGroupContainerURL = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.domain.app")!
}
Info.plist
Make sure that the Info.plist files have access to the app group
Signing and Capabilities
Make sure you add the App Groups capability to each target that needs it, and add it in App Store Connect
I have a vertical list in the screen to show the images category wise and each category/list contains list of images which is shown horizontally. (Attached image for reference)
Now when I am scrolling horizontally or vertically then application is crashing due to memory leaking. I guess lots of people facing this issue in the ForEach loop.
I have also try with List instead of ForEach and ScrollView for both vertical/horizontal scrolling but unfortunately facing same issue.
Below code is the main view which create the vertical list :
#ObservedObject var mainCatData = DataFetcher.sharedInstance
var body: some View {
NavigationView {
VStack {
ScrollView(showsIndicators: false) {
LazyVStack(spacing: 20) {
ForEach(0..<self.mainCatData.arrCatData.count, id: \.self) { index in
self.horizontalImgListView(index: index)
}
}
}
}.padding(.top, 5)
.navigationBarTitle("Navigation Title", displayMode: .inline)
}
}
I am using below code to create the horizontal list inside each category, I have used LazyHStack, ForEach loop and ScrollView
#ViewBuilder
func horizontalImgListView(index : Int) -> some View {
let dataContent = self.mainCatData.arrCatData[index]
VStack {
HStack {
Spacer().frame(width : 20)
Text("Category \(index + 1)").systemFontWithStyle(style: .headline, design: .rounded, weight: .bold)
Spacer()
}
ScrollView(.horizontal, showsIndicators: false) {
LazyHStack(spacing: 20) {
ForEach(0..<dataContent.catData.count, id: \.self) { count in
VStack(spacing : 0) {
VStack(spacing : 0) {
if let arrImgNames = themeContent.catData[count].previewImgName {
// Use dynamic image name and it occurs app crash & memory issue and it reached above 1.0 gb memory
Image(arrImgNames.first!).resizable().aspectRatio(contentMode: .fit)
// If I will use the same image name then there is no memory issue and it consumes only 75 mb
// Image("Category_Image_1").resizable().aspectRatio(contentMode: .fit)
}
}.frame(width: 150, height: 325).cornerRadius(8.0)
}
}
}
}
}
}
Below is the data model which I am using to fetch images from json file and shows it in the list
class DataFetcher: ObservableObject {
static let sharedInstance = DataFetcher()
#Published var arrCatData = [CategoryModel]()
init() {
do {
if let bundlePath = Bundle.main.url(forResource: FileName.CategoryData, withExtension: "json"),
let jsonData = try? Data(contentsOf: bundlePath) {
let decodedData = try JSONDecoder().decode([CategoryModel].self, from: jsonData)
DispatchQueue.main.async { [weak self] in
self?.arrCatData = decodedData
}
}
} catch {
print("Could not load \(FileName.CategoryData).json data : \(error)")
}
}
}
struct CategoryModel : Codable , Identifiable {
let id: Int
let catName: String
var catData: [CategoryContentDataModel]
}
struct CategoryContentDataModel : Codable {
var catId : Int
var previewImgName : [String]
}
Crash logs :
malloc: can't allocate region
:*** mach_vm_map(size=311296, flags: 100) failed (error code=3)
(82620,0x106177880) malloc: *** set a breakpoint in malloc_error_break to debug
2021-07-01 18:33:06.934519+0530 [82620:5793991] [framework] CoreUI: vImageDeepmap2Decode() returned 0.
2021-07-01 18:33:06.934781+0530 [82620:5793991] [framework] CoreUI: CUIUncompressDeepmap2ImageData() fails [version 1].
2021-07-01 18:33:06.934814+0530 [82620:5793991] [framework] CoreUI: Unable to decompress 2.0 stream for CSI image block data. 'deepmap2'
(82620,0x106177880) malloc: can't allocate region
:*** mach_vm_map(size=311296, flags: 100) failed (error code=3)
(82620,0x106177880) malloc: *** set a breakpoint in malloc_error_break to debug
Note: All images of category are loading from the assets only and If I will use the static name of the image in the loop then there is no memory pressure and it will consume only 75 mb.
I think there is a image caching issue. Does I have to manage image caching even if I am loading images from assets?
Can anyone assist me to resolve this issue? Any help will be much appreciated. Thanks!!
I faced the same problem when building the app using the SwiftUI framework. I fetched ~600 items from the server (200 ms), then tried to show it in UI using ForEach. But it took 3 GBs of RAM. After research, I understand that it's not an issue of SwiftUI. Memory issue happens because of the loop (for-loop).
I found the following:
In the pre-ARC Obj-C days of manual memory management, retain() and
release() had to be used to control the memory flow of an iOS app. As
iOS's memory management works based on the retain count of an object,
users could use these methods to signal how many times an object is
being referenced so it can be safely deallocated if this value ever
reaches zero.
The following code stays at a stable memory level even though it's looping millions of times.
for _ in 0...9999999 {
let obj = getGiantSwiftClass()
}
However, it's a different story if your code deals with legacy Obj-C code, especially old Foundation classes in iOS. Consider the following code that loads a big image ton of time:
func run() {
guard let file = Bundle.main.path(forResource: "bigImage", ofType: "png") else {
return
}
for i in 0..<1000000 {
let url = URL(fileURLWithPath: file)
let imageData = try! Data(contentsOf: url)
}
}
Even though we're in Swift, this will result in the same absurd memory spike shown in the Obj-C example! The Data init is a bridge to the original Obj-C [NSData dataWithContentsOfURL] -- which unfortunately still calls autorelease somewhere inside of it. Just like in Obj-C, you can solve this with the Swift version of #autoreleasepool; autoreleasepool without the #:
autoreleasepool {
let url = URL(fileURLWithPath: file)
let imageData = try! Data(contentsOf: url)
}
In your case, use autoreleasepool inside ForEach:
ForEach(0..<dataContent.catData.count, id: \.self) { count in
autoreleasepool {
// Code
}
}
References:
https://stackoverflow.com/a/25880106/11009631
https://swiftrocks.com/autoreleasepool-in-swift
Try not using explicit self in your ForEach. I've had some weird leaks in my SwiftUI views and switching to implicit self seemed to get rid of them.
Your main problem is that you're using a ScrollView/VStack vs using a List. List is like UITableView which intelligently only maintains content for cells that are showing. ScrollView doesn't assume anything about the structure and so everything within it is retained. The VStack being lazy only means that it doesn't allocate everything immediately. But as it scrolls to the bottom (or HStack to the side), the memory accumulates because it doesn't release the non visible items
You say you tried List, but what did that code look like? You should have replaced both ScrollView and LazyVStack.
Unfortunately, there is no horizonal list at this moment, so you'll either need to roll your own (perhaps based on UICollectionView), or just minimize the memory footprint of your horizonal rows.
What is the size of your images? Image is smart enough to not need to reload duplicate content: the reason why a single image literal works. But if you're loading different images, they'll all be retained in memory. Having said that, you should be able to load many small preview images. But it sounds like your source images may not be that small.
Try LazyVGrid with only one column instead of using Foreach.
let columns = [GridItem(.flexible(minimum: Device.SCREEN_WIDTH - "Your horizontal padding" , maximum: Device.SCREEN_WIDTH - "Your horizontal padding"))]
ScrollView(.vertical ,showsIndicators: false ){
LazyVGrid(columns: columns,spacing: 25, content: {
ForEach(0..< dataContent.catData.count, id: \.self) { index in
"Your View"
}
}
}
In the following example, I create 4 timeline entries in one-second intervals, specifying the timeline reload policy .atEnd.
func getTimeline(for configuration: ConfigurationIntent, in context: Context, completion: #escaping (Timeline<Entry>) -> ()) {
let currentDate = Date()
var entries: [SimpleEntry] = []
for secondOffset in 0...3 {
let entryDate = Calendar.current.date(byAdding: .second, value: secondOffset, to: currentDate)!
let entry = SimpleEntry(date: entryDate, configuration: configuration)
entries.append(entry)
}
completion(Timeline(entries: entries, policy: .atEnd))
}
The widget view will show the second of the timeline entry's date, just to make it visible to the user that the widget has been updated.
struct MyWidgetEntryView : View {
var entry: Provider.Entry
var body: some View {
VStack {
Text("\(Calendar.current.component(.second, from: entry.date))")
}
}
}
Whenever I run this on the simulator or an actual iPhone, the widget will count up 4 times, e.g. showing "17", "18", "19", "20". After that, it'll stop updating.
I expected WidgetKit to request a new timeline at this point, since the timeline reload policy .atEnd has been specified.
I'm aware that in this case the date of the last entry only signifies the earliest date for a new timeline to be requested, but it seems that a new timeline will never be requested, even after minutes of waiting or locking/unlocking the phone etc.
I have found this possibly related question, but my example seems to be even simpler, so I think it might be worth asking.
Am I misunderstanding how the timeline policy works?
Hi i am trying to use alamofire to download json weather data. Here is my code, the working version:
class WeatherModel {
private var _date: String?
private var _location: String?
private var _weatherType: String?
private var _temperature: Double?
func getWeatherInfoFromAPI(completed: #escaping ()-> ()) {
let url = URL(string: WEATHER_URL)!
Alamofire.request(url).responseJSON(completionHandler: { response in
// Test updating data
self._temperature = 25
self._weatherType = "Clear"
self._location = "Vietnam"
completed()
})
}
}
-> This way, i am able to update the property of the class.
Failing to update class property version of getWeatherInfoFromAPI func:
func getWeatherInfoFromAPI(completed: #escaping ()-> ()) {
let url = URL(string: WEATHER_URL)!
Alamofire.request(url).responseJSON{ response in
// Test updating data
self._temperature = 25
self._weatherType = "Clear"
self._location = "Vietnam"
}
completed()
}
So, i dont know what is the difference between them. Please help me to clarify between 2 ways here.
Alamofire.request(url).responseJSON(completionHandler: { response in })
and
Alamofire.request(url).responseJSON{ response in }
What is the reason that my code does not work? Since i see the Alamofire docs also use like the second way! I am thinking about thread difference between them
Also, how do i know what thread the code is running in responseJSON?
Thanks, i appreciate your time and help!
Those two ways are functionally identical, the second one just uses Swift's trailing closure syntax.
What do you do in completed()? Because in first example, you are calling it upon completion of network call, and in second case you are calling it immediately after you start the network call - the call is not completed yet. You should call if in Alamofire callback, like in first example. In second example, if you're inspecting those properties inside completed, then it's no wonder they're not updated yet.