I wonder if it's a sign that they believe the framework will necessarily spawn related, self-contained projects. Just as Rails has its own organization with dozens of plugins (and separate repos for documentations) as opposed to it being basecamp/rails...though I suppose the analogy isn't quite accurate since Rails is its own community and not marketed as a product maintained by Basecamp. Or maybe this is a sign that Apple wants Carekit to be less monolithic, such that they've removed the explicit Apple branding to encourage developers? The answer to these kind of things are often mundane...but when it comes to marketing and branding, the thinking process behind the eventual decision is both mundane and time-intensive
I tried out one of the CareKit apps this morning (I think the first four were released today) and they're really nice. Very simple, good use of notifications to remind the user to take pills/add progress, and they're still useful even if your doctor isn't signed up.
I wonder why Apple is the only big company doing something like this? It just seems like a really great idea and I'm surprised Google for example hasn't got in on it (that I know of).
There was only one I could really test as two were for women and another was for diabetes which I presume would make it difficult to test without having it. The one I tried was called 'Start' and is for people with depression. It basically lets you set up reminders to take pills, gives advice on the pills your taking (side effects), and allows you to take a questionnaire on a daily basis so you can track your depression level and see if your treatment is working. I was just playing around with it but it seems like it would be really useful for someone with depression and it's very simple to use.
I recently helped a research group at a healthcare organization build a HIPAA-compliant version of mixpanel into their application to help patients with CBTi.
The app used this XML-based framework to manage the formatting of the questions so that the researchers (who were pretty tech savvy) could manipulate the questions. The XML-framework itself was a bit of a mess, but it got the job done. However, as new iOS releases passed, this XML-based framework slowly became outdated and required some extra work to maintain as time went along. Having an Apple-approved way to build surveys seems like it is the solution to that problem.
I could see a researcher who was technical enough being able to extend CareKit to be able to manage their own study without the help of a dedicated iOS dev everytime they needed to make a change to a question or survey. Part of that is CareKit, part of that is the fact that Swift seems more approachable than Objective-C. This was included in ResearchKit, but CareKit provides a way to track if people have completed daily steps and visualizing that for end users. It only took me 5 minutes from cloning the demo app and plugging in my HealthKit Entitlements that I was able to extend the sample app to track Asthma Inhaler Usage.
EHR integration will still be a challenge, but these are the type of things that my team working on Redpoint at Catalyze will work on like we did with HealthKit on it's release.
If you want to check out how I extended the sample project to include a new activity to track, you can check out my fork here: https://github.com/molsches/CareKit
Apple has publically recommended Objective-C code to not call Swift libraries, but rather advises Swift calling Swift frameworks or Swift calling Objective-C frameworks.
Oh I didn't know that. It still seems weird. Objective-C has always been hard for me to read and yet I love reading code—especially Apple's—so I guess the struggle will continue. Even if that means I can't really contribute to this.
That's the best bit, and makes reading blocks of code incredibly efficient. You can observe a method being called like
[table allowsMultipleSelectionDuringEditing:YES]
And even though you might not remember that UITableView method, once you read it you immediately know what it does, often saving you a round trip to the docs.
those methods rarely do exactly what you think, they can be an overloaded version of another method
and more frequently there is another method with a similar method name, or one is singular and one is plural and it becomes very inefficient because the method names look the same, the exact reason why the english language has spaces and punctuation to begin with
Well duh, obviously. They're not going to concatenate entire paragraphs of documentation into the method name. Like so many things it's a matter of degrees. If the method was called table.multiSel() then you'll be more likely to need to consult the docs.
It's not optimistic in my experience. Much of the time when doing code review or bug hunting other people's code, it's less about knowing exactly what a particular method does, as much as being able to rapidly estimate your way to relevant areas.
If nothing else, verbose names can make it faster to ignore irrelevant code.
To further expand on Apple's recommendation to not make Swift libraries just yet — It's also an matter of compatibility. You could certainly make a Swift framework, but given that Swift as a language is changing every 6 months or so right now, it doesn't make sense to make a framework using Swift.
You could easily hold up another project if you haven't changed your Swift code to the latest, or the opposite is true as well: Your Swift framework is up-to-date with the latest language, but the app using your framework is not, etc.
