
CareKit Framework - rjzzleep
https://github.com/carekit-apple/CareKit
======
IMcD23
I wonder why it's not a part of Apple's Github account,
[https://github.com/apple/](https://github.com/apple/) and instead on it's
own. [https://github.com/carekit-apple/](https://github.com/carekit-apple/)

~~~
DannyBee
Often the answer to these kind of things is mundane, and comes down to "large
companies are large"

~~~
untog
Heh, that was my thought too. "Because it was taking forever to get someone to
make me a new repo"

~~~
Fomite
"And by someone, I mean Jim."

~~~
downvotemyjokes
Dammit Jim!

------
k-mcgrady
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).

~~~
chasing
Curious which app you tried out...

~~~
k-mcgrady
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.

~~~
chasing
Cool. (Full disclosure: I'm the lead developer on the diabetes one.)

~~~
moflome
What did CareKit offer you that would make developing an app (or your upcoming
hardware) for iOS more compelling than on, say, Android? Thanks!

~~~
chasing
We made the decision to develop for iOS first before CareKit hit the scene.

------
markolschesky
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](https://github.com/molsches/CareKit)

~~~
huslage
I think you might want to check out ResearchKit
[https://www.apple.com/researchkit/](https://www.apple.com/researchkit/) as
well.

------
an_account_name
3-Clause BSD. Not too shabby.

------
Cyph0n
I guess Swift still isn't widely adopted inside Apple. Or it could be that
CareKit was started before Swift. Anyone know for sure?

~~~
guessbest
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.

~~~
pducks32
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.

~~~
cloudjacker
runOnSentencesAsMethodNamesDidNotAppealToYou ?

~~~
sjwright
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.

~~~
cloudjacker
> often saving you a round trip to the docs

that's optimistic

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

~~~
sjwright
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.

------
pipedreams2
but what is it tho.

