Google Health Obj-C Client?

[Ford]

The service-specific classes in /Source/Clients are very helpful.

Are there any plans for creating an explicit client for Google
Health? I'm thinking of classes like GDataServiceGoogleHealth,
GDataFeedHealth, GDataEntryHealth, and so on.

I've started developing my own subclasses, but don't want to invest
too much time if something else is already in the works.

Thanks,
Ford

[Greg Robbins]

The health API is essentially the CCR XML wrapped in a generic GData, as far as I am aware. You should be able to use the base classes from the GData framework without subclassing them, as demonstrated in the BloggerSample application from the project's Examples folder.

I've not written any health-specific classes in the library, in part because no one had previously expressed interest in using them, and in part because I'm not sure what beyond the current base classes would be helpful. If you can suggest how health-specific elements, entries, and feed would aid your project, that would be useful.

[Ford]

Very true, the Health API isn't all that different from a standard
GData feed.

I think the benefits of Health-specific classes would be the addition
of convenience methods for listing profiles, listing notices, getting
the CCR XML, auto-setting the serviceId, string constants for Health
URLs, and so on -- syntactic sugar at a class level.

Nothing groundbreaking, I know. From what I can tell, that's all
the .NET and Java clients do.

[Greg Robbins]

It will be a while before I can take another look at the Health API. How about trying to implement your application in the model of the BloggerSample, without any entry or feed subclasses (perhaps create a file to hold the needed string constants.) You'll need to rely on the unknownChildren method to get at the CCR XML.

If you run into any issues where that model doesn't work adequately -- such as really needing custom GData extensions (non-CCR), or some other aspect of using the API that the base classes don't handle -- let me know. I'll either augment the current base classes or add a health-specific set of client classes, as those should be pretty easy.

As far as I am aware, you're the first person using the health API from Obj-C, so you get to endure the pain, or blaze the trail, or some metaphor.  But I do want to make sure that any code needed by multiple developers is in the library, not recreated by each developer.

[Ford]

Hi Greg, thanks so much for your help.

I went ahead and created my own Service/Feed/Entry subclasses, not
because I needed to, but because it seemed like a cleaner design.
Sounds like the Health API is off your radar for now, but I'd be happy
to post my code somewhere if it would help someone.

Oh, thanks for the unknownChildren tip. I was using a pretty gnarly
xpath (something like "//*[local-name()='ContinuityOfCareRecord']")
but unknownChildren feels like a better approach -- probably easier on
the iPhone's tiny processor.

I'm fine enduring a little pain -- if it were easy, it wouldn't be
quite as fun! :-)

Ford

[Greg Robbins]

I've checked in some health classes to the top-of-trunk svn repository. You're welcome to use those, or continue to use your own class alternatives.


There's no sample application in the project yet for the health classes, so here's how to use them.


Allocate the service object and generate the URLs during development using the sandbox service class:

GDataServiceGoogleHealth* service = [[GDataServiceGoogleHealthSandbox alloc] init];
NSURL *profileListFeedURL = [GDataServiceGoogleHealthSandbox profileListFeedURL];
[service fetchHealthFeedWithURL:profileListFeedURL
                       delegate:self
              didFinishSelector:@selector(profileListTicket:finishedWithFeed:)
                didFailSelector:@selector(profileListTicket:failedWithError:)];


The profile ID is available in the content element of the profile list feed entries:
 
GDataEntryBase *profileListEntry = [healthListFeed firstEntry];
NSString *profileID = [[profileListEntry content] stringValue];

NSURL *profileFeedURL = [GDataServiceGoogleHealthSandbox profileFeedURLForProfileID:profileID];
[service fetchHealthFeedWithURL:profileFeedURL
                       delegate:self
              didFinishSelector:@selector(profileTicket:finishedWithFeed:)
                didFailSelector:@selector(profileTicket:failedWithError:)];


The CCR and profile metadata elements just contain unparsed XML; use the childXMLElements or
XMLElements methods to extract those.
 
GDataEntryHealthProfile *profileEntry = [profileFeed firstEntry];
GDataContinuityOfCareRecord *ccr = [profileEntry continuityOfCareRecord];
GDataProfileMetaData *metadata = [profileEntry profileMetaData];

[Try]

Hi Ford ,

I m implementing the google health on my iPhone application. I have
done authentication & retrieved the profile but now i stuck on ccr
parsing can you please me for that.

Thanks,
Dipen

On Jan 23, 8:32 pm, Ford <fpars...@gmail.com> wrote:
> Hi Greg, thanks so much for your help.
>
> I went ahead and created my own Service/Feed/Entry subclasses, not
> because I needed to, but because it seemed like a cleaner design.

> Sounds like theHealthAPI is off your radar for now, but I'd be happy

> to post my code somewhere if it would help someone.
>
> Oh, thanks for the unknownChildren tip.  I was using a pretty gnarly
> xpath (something like "//*[local-name()='ContinuityOfCareRecord']")
> but unknownChildren feels like a better approach -- probably easier on
> the iPhone's tiny processor.
>
> I'm fine enduring a little pain -- if it were easy, it wouldn't be
> quite as fun! :-)
>
> Ford
>
> On Jan 20, 3:42 pm, Greg Robbins <grobb...@google.com> wrote:
>

> > It will be a while before I can take another look at theHealthAPI. How

> > about trying to implement your application in the model of the
> > BloggerSample, without any entry or feed subclasses (perhaps create a file
> > to hold the needed string constants.) You'll need to rely on the
> > unknownChildren method to get at the CCR XML.
>
> > If you run into any issues where that model doesn't work adequately -- such
> > as really needing custom GData extensions (non-CCR), or some other aspect of
> > using the API that the base classes don't handle -- let me know. I'll either

> > augment the current base classes or add ahealth-specific set of client

> > classes, as those should be pretty easy.
>

> > As far as I am aware, you're the first person using thehealthAPI from