I have a medical app for the iPhone that I'm working on, where a user creates timestamped entries for a series of tests performed, which are stored in sqlite for retrieval and subsequent drilldown. In my model class, I have a property uses an NSArray that is populated with these entries, which gets updated as new additions are made in the app.
One thing I'd like to do is display UI behavior similiar to what the Calendar list view does - for any given day, display a section header, that show the name of the day and the date, ans display the entries made for that day.
From a brute force standpoint, I can see how you could precalculate this - as build your list of entries, you could store the entire list in a dictionary, keyed by date.
This seems pretty inelegant though, so I'm wondering if there are other more efficient ways to accomplish this task.
If Core Data WERE available on the iPhone, you could store your information that way instead of sqlite.
Then, when you wanted data for particular day you could search using NSPredicate with a sort descriptor.
Core Data will then return the relevant data sorted according to your descriptor. Nice and neat.
Maybe visit the Apple Dev Center/Forums for some more info on upcoming software...
Related
I currently have a coreData entity called CalorieProgress, which I would like to reset all variables (calorieProgress, fatProgress) to 0, every day.
I am still quite new to SwiftUI, and the only method I thought of as of now, is to add a Date Created variable to this entity called created, and when the user opens the app, to check if that date was yesterday. If so set all values to 0 etc.
Is there a more efficient way to do this?
Thanks
Your design is good and simple, and a reasonable choice if you're getting started.
It can have trouble, however, when people move between time zones. It is even possible for people to move to previous days this way (most dramatically when they cross the date line). There is no single answer to that question. Your app has to decide what it means by "today" when strange clock events happen. (Users also sometimes change their clock, and you want to behave "reasonably" in those cases, even if it means the data is wrong.)
Having built several of these, my suggestion is to just store raw, immutable, data records, and work out things like resetting values when you're running queries. For example, to work out how many calories someone has burned "today" doesn't require that you set any value to zero. You can just perform a query for records that occur after some time and sum their calories (you can even do this with aggregate queries directly on Core Data).
Core Data can be very fast, but if these queries become too slow, you can store daily aggregation records in Core Data. But keeping the original raw data means that those are really just caches and you can throw them away and recompute any time you need to.
Assuming that a new day starts as midnight (I've worked on apps where days started "when the user wakes up in the morning" which is much more complicated...) you should also be aware of significantTimeChangeNotification which is posted at midnight (and a few other times). You can't use this to launch your app or do processing in the background, but it's very nice for updating your UI if the user has the app open.
I am creating a data dictionary and I am supposed to track the location of any used field in a workbook. For example (superstore sample data), I need to specify which sheets/dashboards have the [sub-category] field.
My dataset has hundreds of measures/dimensions/calc fields, so it's incredibly time exhaustive to click into every single sheet/dashboard just to see if a field exists in there, so is there a quicker way to do this?
One robust, but not free, approach is to use Tableau's Data Catalog which is part of the Tableau Server Data Management Add-On
Another option is to build your own cross reference - You could start with Chris Gerrard's ruby libraries described in the article http://tableaufriction.blogspot.com/2018/09/documenting-dashboards-and-their.html
I have a task to create a database to track student results in a school. I came out with a set of relationships between the tables according to the 3 forms of normalisation(I hope I got it right. If not, please enlighten me).
One feature that I want to put in the Filemaker app is that when a teacher want to enter some assignment marks, he will just need to create a new submission record and all the student names in the class will appear.
I could not think how this feature can be done in Filemaker. I can only create a new submissions record and key in a student's score, then create another new record to do the same thing for a second student.
Can someone help? I am a teacher, not a Filemaker developer so please correct me if my database tables are done wrongly.
Update:
I will like the output to be like this
Spreadsheet is not suitable because it can't be used to search/sort easily.
I have a quick sample file here. It's an old sample and it uses a different (but similar) model. Basically the idea is that: You have a calculated field (I use a repeating field) to display the data. You also have a global repeating field that serves as an editing widget. Each time you go to a record you fill this field's reps with data from related records (using a OnRecordLoad trigger). This doesn't mean the field shows the same data for all records, because its conditional formatting rules are set to hide all data; so it only shows a piece of data when you actually enter one of its repetitions. This is the data that can be edited. And finally there's a trigger that fires each time you exit the field and posts your changes to the related table (adds, updates, or deletes).
The sample isn't quite complete because if there's fewer data columns than repetitions, you'd probably want to somehow lock the remaining repetitions; this part isn't done. Otherwise it works fairly well. In FM 12, however, it tends to freeze the app; I reported this to FMI, they acknowledged it, but I don't think it has been fixed already.
I am new to iOS programming and looking for advise for an iPhone app that I am creating.
I have an excel database of about 100 daily tips (which will continue to grow) that I want to import into the app, and have one tip display each day. The user will have access to the current daily tip, plus any prior tips from prior days in the database.
I would like to keep it as a closed app, so if a user feels they want to skip ahead to see new tips by changing their current date - I am not worried about the few who might do that.
From my searches so far, CoreData seems to be the way to go but I was looking for suggestions.
Any help is greatly appreciated.
I'll try to give you some advice to achieve what you want.
First of all, what do you mean with
I would like to keep it as a closed app, so if a user feels they want
to skip ahead to see new tips by changing their current date - I am
not worried about the few who might do that.
I'm not sure about its meaning.
Said this, based on my experience (someone else could give you other advice) I suggest you the following.
About your model you need to create an entity, say Tip, that could have the following attributes:
guid: an identifier that works as an identifier, the type could be a NSString
creation date: the creation date for your tip, the type is a NSDate
text to present: the text to present to the user, the type is a NSString
In addition you can also set a title, etc.
The date has two objectives.
First, it allows you to filter tips based on the current date. To filter you need to create a NSFetchRequest and set a NSPredicate. For example:
[NSPredicate perdicateWithFormat:#"creationDate <= %#", currentDate];
In addition it allows to sync with your service to download data. Based on the max date you find in the core data sql lite file, you could ask a service (if you use one) to give you the tips that are greater than that date.
The guid allows to have only one tip for that identifier (you could just use the date for that but I think is easier to have a guid, say 12345). This could be useful if you decide to download each time the whole data and you don't want to insert the same tips. In addition, you don't want to ricreate the db when you have new tips, but you would add only the new ones. So, you need an identifier that let you to verify if a tip is already there.
Finally, about your service (if you want to set up one) you could download data in JSON format. I think it's simply to set up.
If you are interested, here some links that could make your life easier:
Take a look at importing-and-displaying-large-data-sets-in-core-data in the case the data amount of downloaded data is huge. With iOS 5 new APIs are there, but the concepts you find in the post still remain valid.
A simple intro on Core Data (a question I answered in a previous post)
core-data-on-ios-5-tutorial-getting-started
If you want to know something else, let me know.
Hope it helps.
I keep seeing questions floating through that make reference to a column in a database table named something like DateLastUpdated. I don't get it.
The only companion field I've ever seen is LastUpdateUserId or such. There's never an indicator about why the update took place; or even what the update was.
On top of that, this field is sometimes written from within a trigger, where even less context is available.
It certainly doesn't even come close to being an audit trail; so that can't be the justification. And if there is and audit trail somewhere in a log or whatever, this field would be redundant.
What am I missing? Why is this pattern so popular?
Such a field can be used to detect whether there are conflicting edits made by different processes. When you retrieve a record from the database, you get the previous DateLastUpdated field. After making changes to other fields, you submit the record back to the database layer. The database layer checks that the DateLastUpdated you submit matches the one still in the database. If it matches, then the update is performed (and DateLastUpdated is updated to the current time). However, if it does not match, then some other process has changed the record in the meantime and the current update can be aborted.
It depends on the exact circumstance, but a timestamp like that can be very useful for autogenerated data - you can figure out if something needs to be recalculated if a depedency has changed later on (this is how build systems calculate which files need to be recompiled).
Also, many websites will have data marking "Last changed" on a page, particularly news sites that may edit content. The exact reason isn't necessary (and there likely exist backups in case an audit trail is really necessary), but this data needs to be visible to the end user.
These sorts of things are typically used for business applications where user action is required to initiate the update. Typically, there will be some kind of business app (eg a CRM desktop application) and for most updates there tends to be only one way of making the update.
If you're looking at address data, that was done through the "Maintain Address" screen, etc.
Such database auditing is there to augment business-level auditing, not to replace it. Call centres will sometimes (or always in the case of financial services providers in Australia, as one example) record phone calls. That's part of the audit trail too but doesn't tend to be part of the IT solution as far as the desktop application (and related infrastructure) goes, although that is by no means a hard and fast rule.
Call centre staff will also typically have some sort of "Notes" or "Log" functionality where they can type freeform text as to why the customer called and what action was taken so the next operator can pick up where they left off when the customer rings back.
Triggers will often be used to record exactly what was changed (eg writing the old record to an audit table). The purpose of all this is that with all the information (the notes, recorded call, database audit trail and logs) the previous state of the data can be reconstructed as can the resulting action. This may be to find/resolve bugs in the system or simply as a conflict resolution process with the customer.
It is certainly popular - rails for example has a shorthand for it, as well as a creation timestamp (:timestamps).
At the application level it's very useful, as the same pattern is very common in views - look at the questions here for example (answered 56 secs ago, etc).
It can also be used retrospectively in reporting to generate stats (e.g. what is the growth curve of the number of records in the DB).
there are a couple of scenarios
Let's say you have an address table for your customers
you have your CRM app, the customer calls that his address has changed a month ago, with the LastUpdate column you can see that this row for this customer hasn't been touched in 4 months
usually you use triggers to populate a history table so that you can see all the other history, if you see that the creationdate and updated date are the same there is no point hitting the history table since you won't find anything
you calculate indexes (stock market), you can easily see that it was recalculated just by looking at this column
there are 2 DB servers, by comparing the date column you can find out if all the changes have been replicated or not etc etc ect
This is also very useful if you have to send feeds out to clients that are delta feeds, that is only the records that have been changed or inserted since the data of the last feed are sent.