Yehster:
The way you suggest is the way we’re already trying to implement. The Home button in the menu is just there to allow people to use the full site since the frames are causing such a ruckus right now. Be sure to hit the little blue triangle at the bottom of the app, individual pages are in there. It doesn’t work great at the moment, but thats why this is still just an alpha release.
Can you provide a link to the other demo? We’ll make it the default.
arnabnaha: the server address needs a trailing slash “/” as of right now. We’re going to make it look for this and add it if it isn’t present, but for testing purposes, you can just put it in yourself until we get that fixed. Please try this and confirm if this addresses the issue.
When I first tried it, I hit the blue triangle, tried a bunch of menu items and nothing happened.
Now, I can’t select the login textboxes at all. That aside…
I think the fundamental issue you are going to run into is that every navigation element in existing pages calls the javascript function “top.restoreSession()” which is defined in the top frame. However, when you break out the individual web pages, that is no longer defined.
Can the android app inject additional javascript onto the rendered webpage? If you can define a stub for top.restoreSession that exists in the android app, that may get you to the next step.
yehster: Thank you for the astute observation. Arimal is researching that now. He says Android has javascript interfaces, so it shouldn’t be too difficult, now that he’s aware of the issue. There will probably be another point release soon.
Some of the plans for other tweaks we have in mind for the app:
- full android-based search function, instead of relying on the web page system
- current patient shown in the title bar
We are debating whether to move the drawer onto the menu button, and have the current options accessible via a button in the drawer. We’re thinking that this will make the drawer more device friendly as most devices have a dedicated hard menu button or touch area. Thoughts?
Hi
Tried with only the host name as server name and it connected nicely…i just tried “nahahealthclinic.dyndns.org/” and bingo…i got the connection. Now after entering into the home screen after entering the username and password in the login screen, found out that the calendar only shows half in the portrait view.I cannot move the page side ways to see the rest of the calendar but the length of the calendar is full.
mdsupport:
thanks, checking it out now. Are these always up to date? They offer the ability to print an XML file. If we can parse that, we may be able to make it searchable.
The codes will always be up to date because the CDC assigns them. In a way that is the source of problem for systems that maintain a copy of the data for local use - the copied data can become obsolete unless someone remembers to periodically check for the new codes. This is not a functionality in the current software but it does offer a ‘Proof of Concept’ where the mobile interface will integrate several sources of information - OEMR being just one of them.
If their XML printout link is static, we should be able to parse it real-time. This is all far horizon stuff obviously. Right now, we’re concentrating on getting the main functions working well.
A small update. Changed font on the buttons and using the “Patient Finder” page on the search button. Seems to work somewhat. Please test and report, thanks.
Guys,
Have you setup a server of your own for internal testing? https://github.com/yehster/openemr/commit/65ea8e236bb63cba26bb0dbedbb08dbf4646d779
If so, you should pull this commit. It wraps the top.restoreSession call in an exception handling block, so that when a new dialog is opened (like with the patient search button) execution can continue if that function is missing (since you have no restoreSession function
I am able to use the search page with no frames under firefox with this change.
An additional change might be to make dlgOpen use the current window based on user agent so that when using android you would get the search results in the current frame work instead of opening a new window. Not sure what happens in your android app’s browser if javascript tells it to open a new window.
The reality I think is that the session info shouldn’t be tracked on just the top level frame, but rather on each individual page, separate discussion though.
I think your chances of success would be greatly improved if we can identify appropriate server side changes that you can test out.
Changes like the one I pushed to git won’t make it to the demo servers for a “very long” time as they would have to be reviewed before they can become an official part of the source code.
Brady can answer your question about frequency of update better, but I believe that the 4.1.0 demo basically gets updated as he deems code ready for patching 4.1.0 (the actual process may happen ,more frequently as part of an automated process) but the code gets updated as he commits stuff to the rel-410 branch. The 4.1.1 demo server gets updated nightly with whatever new changes may have been pushed to master that day.
Ok, we’re gonna use the 2099 one, the development, 4.1.0 server. Cool that its 2099. Ghostrider 2099 was awesome!
Big internal changes on this one, not much you’ll see, but we’d appreciate if you all could test it. Arimal re-organized the code to run more efficiently, with less threads, and it seems to cache data better as well. I’ve changed a couple of the button destinations, but I’m still looking for better if you have suggestions, or any that are just useless that need removing. http://dl.dropbox.com/u/38293434/OpenEMR.apk
Probably won’t be any more releases until after Christmas… unless its just some button changes. Arimal is attempting to tackle the javascript interfaces next and soap, now that the re-write is done.
Hi,
Getting the following message when open the app:
‘Site ID is missing from session data!’
(this is a message from the interface/globals.php script related to the site name and multisite module)
-brady
