Hi Olof, Since your query includes people interested in the topic, I end up being in the result set. I'll write down a couple of points below.
I am really interested in this, but for me Mac is not an affordable platform at the moment. I simply can't cover the cost of having a proper Mac and an iPad. This did not stop me from thinking about it though. If you go with a native app, you'll need to develop it in Objective-C, or that has been the case up until recently. With iOS 4.0, Apple introduced severe limitations to its SDK, the worst one being not being able to use any other language other than Objective-C and Apple development environment. (not so sure about the dev env) This led to lots of criticism, and recently Apple eased it a little bit, which made monotouch ( http://monotouch.net/ ) an alternative solution to Objective C, or that is my understanding of the status. For companies with C# implementation, this is a serious advantage. Other companies would probably produce objective c back ends for their compilers if this practice gets established, but you'd still have to use Mac as a development platform to link to iOS functionality. If you're not doing C#, then your options are Objective-C and web applications. I won't go into HTML 5 praising here, since I personally see it as a dangerous hype at this point, till the tooling side of things mature. For web applications, you can again leverage your existing investment with some improvements/customizations for Apple platform. However, there is one critical aspect of native application deployment: the Apple review process. Apple has very strict rules for not allowing apps interpret code. How and why an application is considered to be interpreting code is completely up to judgement of Apple people, and if they think your app is hosting another app, then you simply won't get your place on the app store. The reason this may be a problem is the nature of openEHR: various components may be plugged at runtime and Apple people may interpret some functionality as intepreted code. If you think about it, many runtime aspects of openEHR implementation read model descriptions and orchestrate things accordingly. This is the power and flexibility of openEHR, but to Apple, this means an app hosting other apps, thus losing control of their app store (the last bit is my view of their approach). I can't see any technical issues with Apple platforms. In case of Objective C it would be a big task, but that is all. Apple's iron claws around deployment would be my concern. The web app is probably the safest when it comes to deployment. Anyway, my 2 cents (is there a British form of this expression? just out of curiosity) Kind regards Seref On Thu, Sep 23, 2010 at 11:25 AM, Olof Torgersson < olof.torgersson at chalmers.se> wrote: > Hi, > > Is there anyone who's done any work related to openEHR for the iPhone/iPad? > > I guess one would need an implementation of the reference model etc in > Objective-C since that's the only supported language on the platform. > > If you are working on this or interested in the topic then I would be > interested in knowing about it. > > regards > > Olof Torgersson > > --- > Olof Torgersson > > Associate Professor > Department of Applied Information Technology > Chalmers University of Technology and G?teborg University > SE-412 96 G?teborg, Sweden > > email: olof.torgersson at chalmers.se > phone: +46 31 772 54 06 > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100923/efbb6e08/attachment.html>
