Issues with Acer Tablet/Android 3.1

marka1211 wrote on Wednesday, August 10, 2011:

I just purchased an Acer Iconia A500, running Android 3.1, for use with OpenEMR.  Testing with the git-openemr 4.1.0-dev, the most obvious issue is that one cannot add a new patient.  Using Firefox/Ubuntu from my laptop, pressing the “Create New Patient” button causes a new window to pop up, asking for confirmation.  No popup window opens using the Android web browser.

Another, less critical issue with the Android browser, is that the opening page is very long - the schedule in the top window extends far below the bottom edge of the screen, and is not a scrollable window.  Even farther down the screen is the separator between the upper and lower window.

I have not installed firefox on the Acer, to see how it compares.  However, the current trend is that the Android tablets will soon be the dominant platform, and should probably be compatible out of the box with OEMR.

BTW, congrats on the Certification status!  The more I learn about OEMR, the more impressed I become.

yehster wrote on Wednesday, August 10, 2011:

Old versions of jQuery seem to be an issue for newer devices/browsers.

I modified new_comprehensive.php on my development machine to use jQuery-1.6.1.min.js and it works on my android phone.  I was able to replicate Mark’s problem on my phone before when using the very old  js/jQuery.js script that is part of main branch.

As an aside, I think it’s a bit premature to declare Android tablets the dominant platform.  Fragmentation of android is a big problem, and even though the change seems to work with my Samsung android phone, there is no guarantee that it’ll work on your Acer device.  iOS certainly has a larger market share on the tablet front at this point. 

Framescrolling seems to be a consistent issue across tablet platforms, as I guess the scroll gestures are unable to distinguish if you want to scroll the whole window or just the individual frame.  The correct approach will require some additional thought.

mike-h30 wrote on Wednesday, August 10, 2011:

As an aside, I think it’s a bit premature to declare Android tablets the dominant platform. Fragmentation of android is a big problem, and even though the change seems to work with my Samsung android phone, there is no guarantee that it’ll work on your Acer device. iOS certainly has a larger market share on the tablet front at this point.

Our physician wants iPads in the office.  I am seeing more iPads in the offices of our physician and chiropractor colleagues.  It would be a mistake for OpenEMR to ignore iOS.  iOS could catapult OpenEMR further ahead of the commercial EMR competition.

Albert: iPad has already won healthcare tablet war
http://mobihealthnews.com/10537/albert-ipad-has-already-won-healthcare-tablet-war/

10 Ways The iPad Is Changing Healthcare
http://www.businessinsider.com/10-ways-the-ipad-is-changing-healthcare-2010-7

Medtronic:  Better Medicine Through iPad
http://www.apple.com/ipad/business/profiles/medtronic/

Further, seeing ads like this makes me hope that OpenEMR does not abandon iOS.

Flash is dead. Keep up to date with SitePoint’s HTML5 & CSS3 eBook
http://www.appsumo.com/html5-and-css3-for-the-real-world/

yehster wrote on Wednesday, August 10, 2011:

Mark,
My suggestion as an experiment to see if new jQuery fixes things for you is to download the latest version from here:
http://docs.jquery.com/Downloading_jQuery#Current_Release
and replace the js/jquery.js file in your installation with the newest stable release.

It won’t address the scrolling problem, but it may fix the popup issues.

voipbound wrote on Wednesday, August 10, 2011:

I vaguely remember reading that Apple is planning to abandon IOS and bring the Ipad into the fold with its OSX operating system.  Anyone remember glancing through this bit of info?

yehster wrote on Wednesday, August 10, 2011:

The issue isn’t really about Linux vs. Windows vs. iOS vs. Android for OpenEMR, as it currently is and always will be a browser based application.  It is very unlikely that anyone will write a truly native OpenEMR application targeted at iOS or Android. 

Support on iPad is about making sure that our HTML and javascript and layout decisions work for safari.  Android support entails testing with either the browser that comes with what ever Android device one chooses to use or trying to standardize on a common browser like Dolphin(HD) or Firefox for Android. 

This kind of sums up the issue if we can make sure that our javascript is truly cross platform (i.e. by upgrading jQuery and figuring out the frame layout/scrolling issues.)
http://www.xkcd.com/934/

tmccormi wrote on Wednesday, August 10, 2011:

It is all about having clean and modern HTML in our code.  Which is hard with some of the legacy stuff and the frames.  We need to continue to work toward moving away from frames and using more HTML5 + CSS (with extreme care).   At some point we may need to say “support for the following browsers….” so we aren’t buried in every option and every version of every browser.
-Tony

julialongtin wrote on Thursday, August 11, 2011:

Tony:
I would say that we should concentrate on standards compliance first and foremost, to a set of standards our target browsers should(!) support.

I’ve been using the xhtml standards for my output… and can’t really even tell you what css level i’m using off the top of my head(2? 2.1?).

Anyone else want to say what standards their using when writing code for OpenEMR?

Julia Longtin

yehster wrote on Thursday, August 11, 2011:

I agree that conforming to HTML and CSS standards is a good idea, however, the cause of the issue in the original post is javascript and frames.

In addition to updating the used jQuery version, if we special case scrolling to “yes” instead of auto for tablet based browsers, that might address the other part of the issue on Androiid and iPad

Moving away from frames is a good goal, but as I understand it, we would have to change almost every screen to do that and it would be a pretty monumental task.  We can’t really do it piecemeal.

garryhallford wrote on Thursday, August 11, 2011:

I am using an iPad without any problems so far but I am not using Safari. I use either Skyfire or Terra third party browsers which seem to handle everything except real-time flash.

-Garry

marka1211 wrote on Thursday, August 11, 2011:

I haven’t worked out all the permutations, but updating jquery did not fix the pop-up problem.  The pop-up does work, sometimes, on 4.0.  I’ll have to do some more testing to see if I can find a pattern to when it does or doesn’t.

Another annoyance has surfaced, though: pressing the TAB key on the Android software keyboard does not advance the cursor to the next field.  I suspect this is an issue with the Android, but it sure makes it a PIA when filling in the New Patient form.

tmccormi wrote on Friday, August 12, 2011:

One thing I liked about the HP webOS tablet, the TAB key worked.  I had the same browser size issues though.
-Tony

stephen-smith wrote on Sunday, August 14, 2011:

I agree with Julia that we should be less concerned with specific devices/environments and more concerned about standards compliance.

IME, that’s rarely enough, but it does get us most of the way there.  When specific devices/environments fail to implement their side of the standard correctly, we should document it on the wiki and avoid that feature of the standard.  Thus, we would target the proper intersection of the standard and the partial implementations that we must deal with.  It will be a shared responsibility to avoid the “trouble spots” documented on the wiki.

Must to my distaste, the industry considers HTML 5 a standard, so we should use it as a foundation.  I don’t think CSS 3 is a candidate recommendation yet, so we should continue to target CSS 2.1, although I am open to having a white list of well-supported CSS 3 features on the wiki.  I don’t know who is maintaining the current JavaScript/ECMAScript standard, but that must also be paired with the HTML 5 DOM documentation…  we should try and use jQuery for as much as possible and rely on the jQuery developers to do most of the “heavy lifting” when it comes to cross-browser scripting.

tmccormi wrote on Sunday, August 14, 2011:

I agree with Stephen here, on all counts.  I was just reading a decent HTML5 book and it suggested the use of a javascript library available from www.modernizer.com.  This allows detecting HTML5 code and the browser level support and falling back to a JS backup function when HTML5 won’t work.   I have seen a couple of other similar frameworks for supporting migration to “pure” HTML5 while keeping backward compatibility.
-Tony

marka1211 wrote on Tuesday, August 16, 2011:

For anyone following along, I have now tried several browsers on the Android 3.1 platform.  The only one I’ve found which seems to work correctly is Opera Mobile, which handled the pop-ups correctly, even with the “old” version of jquery.js.   Interestingly, Firefox on the Android was one of the worst performers.

yehster wrote on Friday, August 19, 2011:

I believe that I have a solution to the calendar scrolling issue on tablet platforms.

The fundamental problem is that tablet platforms don’t provide the means to scroll individual DIV elements.  It’s not an issue because of the frames presentation as I had suspected. 

The fix that I think will work is if you change your interface/themes/ajax_calendar.css file so as to not specify the height of the bigCal DIV (It’s currently set to 80%) the browser will then put scroll bar if needed on the whole frame instead of just the list of appointments.

On Tablet platforms (at least on iPad) I believe that the frame will just become big enough to display the calendar, pushing down the bottom frame.

The downside of this change is that on desktop systems: if part of your calendar overflows the frame, then when you scroll the whole frame scrolls instead of just the list of appointments and you lose quick/easy access to buttons at the top.

cybercod wrote on Monday, January 09, 2012:

mike-h30:  I would suggest that if you want to create a dedicated iOS app, that you’d be at the front of a short line.  The OpenEMR devs have their hands full with the server project.  Its very easy to say “you should do X”… its a lot harder to actually do X.

Me and my buddy are working on a dedicated Android OpenEMR app, but we will not be working on an iOS app.  Why?  Android has a lower barrier to entry for developers.  We do not like Apples policies, or their dictatorial market rules and regulations, nor do we want to jump through the big flaming hoops necessary to get an app on the Apple App Store.  With Android, the tools are free, the SDK is free, getting the software to users OUTSIDE of the market is easier, and getting the software to users INSIDE the market is easier.

When an iOS developer gets interested in OpenEMR, it’ll get an iOS app. 

But popularity is but one factor in these decisions, and frankly, for people who cherish open-source values, Apple does not seem to deserve or warrant the popularity it is currently receiving, and if the iPad gains popularity, that would actually be a bad thing for the end users, not a good thing.

There… thats my soapbox for the day.  Enjoy.

mike-h30 wrote on Monday, January 09, 2012:

cybercod:  Thanks for the comments.  I agree that the server app is number one priority.  iOS would be an added bonus but not a pressing need at the moment.

My main problem with Android (as yehster has already pointed out) is the fragmentation.  While an app may work on one Android device there is no guarantee that it will work on another device or even continue to work with any new Android updates.

The Year Android Had Multiple Personality Disorder
http://www.zdnet.com/blog/perlow/2011-the-year-android-had-multiple-personality-disorder/19486

In 2011 Google’s Android brought us splits in versions, open source commitment, carrier and OEM implementations, preferred device vendors and application ecosystems.

Also, I am not seeing Android as “open” as folks like to believe.

Is Android Open?
http://www.wired.com/epicenter/2010/10/is-android-open/

Android basically gives you two options: Accept what Google gives you, or fork the entire codebase. Other than the ability to roll your own version of Android,** it’s really no different than iOS**, which works on a similar “take what Apple gives you” model.

It’s the lack of community-based development that Android’s critics say makes it no more “open” than Apple’s locked-down, decidedly not-open iOS model. As Perens says, “most open source projects  instant access to changes as they are made … and an open door for anyone to participate.”

Unlike major open source projects like Firefox or the Linux kernel, you can’t see what’s happening behind the scenes with Android, nor can small developers contribute to the project in any meaningful way. Google typically releases major updates to Android at press conferences, not unlike those Apple uses to show off new iPhone features.

Once the code is released, Android developers can download it and do what they want with it, but they have no way of seeing what’s happening behind the scenes every day.

While Android may have the legal licensing to qualify as open source, it utterly fails on the equally important issues of transparency and community.

There Is No Such Thing as Android, Only Android-Comapible
http://www.wired.com/epicenter/2011/12/only-android-compatible/

Let’s start with a basic contradiction. Even though it’s open source and free to modify, Google keeps Android’s development tightly under wraps until they’re ready to show it to the world. In the case of Honeycomb, Google even held on to the source code powering devices already in the market.

cybercod wrote on Tuesday, January 10, 2012:

http://apple.slashdot.org/story/12/01/08/069204/leaked-memo-says-apple-provides-backdoor-to-governments

This quote is retarded:
“Android basically gives you two options: Accept what Google gives you, or fork the entire codebase. Other than the ability to roll your own version of Android, it’s really no different than iOS, which works on a similar “take what Apple gives you” model.”

The reason it is retarded is that iOS is not open AT ALL.  Either you, or the original author is confusing the term “source code” with “APK”.

Yes, Google does hold some bits of Android close to its chest temporarily, but it DOES get released eventually.  You CANNOT fork iOS.  And the ability to fork is the defining aspect of open source.  Open source does NOT mean they will do whatever you tell them to, it means that you can take a snapshot of what they have and change it, and re-release it.  With Android you can get entire re-rolled distros like Replicant.  http://replicant.us/about/

If someone tried to do that with iOS, Apple would sue them back to the dark ages. 

On the subject of fragmentation, while it is currently considered a hindrance, it will eventually prove to be a boon (and some say it already has) as Android evolves to cope with a myriad of different devices and situations.  I think the old saying “what doesn’t kill you makes you stronger” applies here.

It can also be argued that fragmentation and its current (if diminished) level openness are already making Android a much more attractive platform for the following reason:  device lifespan.

With Android, in many cases, you can take a device that is no longer supported by its manufacturer and install a newer firmware that increases its functionality and provides new features and compatibility. http://www.cyanogenmod.com/

This means that old devices will get refreshed with increased usability and remain viable and workable tools as a result, saving them from the landfill, reducing consumerism and adding resale value.  Android devices will get used until they fall apart, but an iOS device will become technically obsolete whenever Apple decides to stop supporting it, forcing the user to upgrade.

And while you chew on all that, think about iOS security stance; providing a back door to governments (and not just yours) to enter the device.  And maybe you trust the government, and you’re fine with that, but backdoors don’t stay secret forever. http://apple.slashdot.org/story/12/01/08/069204/leaked-memo-says-apple-provides-backdoor-to-governments

Yet the Android is secure enough for the NSA itself to use, after some custom tweaking.  http://selinuxproject.org/page/SEAndroid

And as a result of Android’s open-source nature, the changes the NSA made are available to end users also.

So what would you recommend to a doctor?  A tablet that the Indian government (and most assuredly a lot of other governments) have access to, which could eventually be accessible by any nerd with a chip on a his shoulder if it leaks, which will likely have to be replaced long before it gets physically broken, and is many times the price…

Or a tablet that can be updated even if its parent company files chapter eleven, can be configured to a level of security usually only reserved for secret agents, that will be useful until the day its hardware gives out?

With iPads, a doctor or hospital would have only Apple to turn to for support as they generally don’t like 3rd party repair services.  With Android, hospitals could hire an in-house technician to service the devices, maintain their own customized interface, and respond instantly to issues the users face, perhaps even have a spare-parts pool as they become broken to refurbish units and further reduce the hardware costs associated with having a fleet of tablets.

I said it once before, but it bears repeating.  iPads do not deserve the popularity they are enjoying. 

If you have any further arguments after this post, other than undeserved popularity, please feel free to list them.  I think debate is a healthy thing, and bear you no animosity.

jojohit wrote on Tuesday, January 10, 2012:

I use OpenEMR on IE on my PC. It behaves the same way on a Chrome browser on a PC. On a tablet I’ve tried it on Motorola Xoom 10" (Android 3.2.1) with many the built-in browser (supposed to be Chrome), Safari, and Firefox but the format and layout is unusable. Then on iPad2, the built-in Safari browser has the same format/layout problems.

I have not tried it on current Windows 7 tablets yet. But the theory is the Windows 7 OS is the same regardless of being installed on a PC or on a tablet, which means IE should work the same way. The advantage of using a tablet is its lightweight and mobile, touch screen and wireless.

My problem with current tablet devices however is the largest 10" screen is still unusable in my opinion. The screen is still too small for OpenEMR that I have to scroll the screen everywhere. Also, touch screen is difficult with small fonts. I could not imagine issuing the tablets to a provider wishing them to use it and fat finger the links. This is a usability factor problem. My suggestion is to use a minimum of 15" screen which is not available on any tablet form factor at all, but probably on foldable laptop touch screens.

This is no shot to all Windows haters out there. This is an experience. I’ve bought an Android and iPad2 for nothing; I want to share this info so you don’t have to make the same mistake. The only option for now is a 15" laptop - touch screen and outward folding screen is a preference.

JP