I posted a question on the "Mobile & Browser Applications" category in these forums inquiring about the best way to "push" application updates to deployed devices:
http://www.alphasoftware.com/alphafo...ate-deployment
I am hoping this topic is relevant enough for the Tablet Optimized Forms forum since my company is looking forward to specializing our tablet system in a way that the devices will be geared for use exclusively within our organization, and we believe other developers may be able to benefit by an open discussion about the tricks and traps involved in creating a specialized "tablet replacement system."
I could certainly benefit from any information that eases the creation of such a system, so any tips are certainly welcome, as are any corrections if I have unwittingly misrepresented or misunderstood programs, functions and features, or their application in any way.
At risk of overstating the obvious, consumer grade tablets are loaded with apps and utilities that allow users to perform many tasks that are not relevant in the context of our company and its services and processes, and since the excellent performance of Alpha Anywhere applications is pretty much a given, we can dispense with the typical assortment of user applications and utilities, and limit user's ability to access to system controls and settings, allowing a tablet to be optimized for specific tasks as defined by the Alpha applications suite. Among other benefits of locking the tablet down to specific tasks are:
Successfully implementing these features essentially converts the tablet into a purpose-built device that is totally and strictly under management control. To us, the only feature lacking is a way to conveniently and robustly manage application updates without exposing the tablet OS and its settings to unauthorized users.
While I realize that using Alpha Anywhere's default system requires no user application "updates" since any revised applications are served from the Alpha Server as a web application, our "clipboard replacement" tablets will eventually be "kiosked," offering the user nothing but the Alpha application. This is not a problem for Alpha Anywhere in itself, since the tablet OS can easily be configured to launch a frameless browser that exclusively connects to the Alpha Server on our local network.
In order to offer the greatest amount of screen space, and to prevent casual browsing (management suggests that our mechanics need to be working, not watching cat videos on YouTube,) we would have had to select or build a chromeless browser that connects to nothing but the Alpha server, but this would have involved deploying and installing an Android or iPhone application to each mobile device, which is out of Alpha's paradigm.
Fortunately, the incredibly brilliant team at Alpha Software has leveraged the PhoneGap API which solves half of the problem as it eliminates the need to use a separate browser. Alpha made this possible by providing a UX component for PhoneGap builds that supplants the requirement for an external browser. Furthermore, PhoneGap provides an "in-app" browser, allowing the Alpha application to maintain state if the developer needs to provide browsing functions without exiting the application, which is perfect for our "kiosked" devices.
The other half of the problem involves the deployment of updates to multiple devices without having to require users to scan QR codes from PhoneGap build, send email attachments, deploy SD cards, or connect each device to a development machine for updates. Ideally, we would like to compile PhoneGap builds locally and then push them to our devices from a local server, but as yet I have found no manageable way to emulate the same style of "push" services provided by the Google Play Store or App Store from a local source.
That leaves two options;
1. Using a private channel in the Google Play store ($25.00 registration fee) or iTunes ($99.00 - $299.00+ yr, subject to a plethora of draconian rules, conditions, and other typical Apple OS complications)
2. Employ PhoneGap "Hydration," a new feature that causes the PhoneGap management app installed on target devices to detect and offer updates upon launching a PhoneGap-built app.
iPhone vs Android: Make no mistake, we love Apple devices, which are fast, solid, robust, and just plain cool, but despite the fact that Alpha Anywhere coupled with PhoneGap takes the pain away from developing apps for iPhone/iPad platforms, deploying apps for these devices from Apple authorized sources is both expensive and inconvenient, which is why we decided to eschew Apple products and invest in Android powered tablets, namely the Samsung Galaxy Note Pro 12.2. Also, our intent to "kiosk" a tablet will certainly require root access, and even possibly the ability to recompile the OS kernel, both of which are possible with the Android device.
It is unlikely that we could obtain an "unlocked" i-device from Apple, and slightly more unlikely that Apple would make its source code available for kernel adjustments (unlikely as in "not in this universe, EVER!)
Under different circumstances I would have selected the iPad as our device of choice, but they fell short of our requirements in too many ways. Sorry Apple, that's 36 missed sales opportunities, and more as we abandon our enterprise deployed iPhones in favor of a more developer-friendly platform. Besides, our system will require users to collect photos in unfavorable lighting conditions, and the Note Pro tablets are equipped with a camera flash; iPads are not, plus the Samsung's 12.2 inch screen offers a lot more space on which to run Alpha's Tablet Optimized Forms than the largest iPad. Executive management personnel who insist on keeping their iPhones can access our Alpha Anywhere dashboard apps in the usual manner via webclips.
"Certified Alphaholic" user David Kates (thanks a million, David!) was the one who provided the answer to my question on the forums regarding automatic deployment, suggesting that I check out the PhoneGap "Hydration feature," and after a brief test, it appears to suit our needs perfectly until we can figure out a way to perform the same functions from our local server, if ever.
While setting up and deploying PhoneGap-built APK's from a private Google Play Store "channel" is inexpensive and very straight-forward, there are a couple of disadvantages that cause it to fall just short of our goals.
As with any Android device, many apps downloaded from the Play Store can be set to update automatically, which would be fine if it weren't for the fact that some operations in process might be interrupted by spontaneous updates if one becomes available in the middle of a job. And even though it would be up to us to decide when to deploy updates to the store, worker processes at our company do not all start and stop synchronously, as we often operate 24/7, and regularly have technicians deployed to other parts of the world.
It makes sense then, that the user must be allowed to decide when it will be convenient to allow the update.
On the other hand, if we opt to deploy apps from the Play Store requiring manual updates, we would have to allow notifications from the Android OS, but as we don't want to expose any of the Android system controls since, we will be turning the notification areas off to avoid allowing a user to access system functions.
PhoneGap's "Hydration" feature fills the bill because it only checks for available updates upon launch of the app, as it will when the user logs on to the device at the beginning of a work day, or when other users log in to process other jobs or operations. Authenticated managers would be able to trigger updates at will.
I have tested Hydration by uploading and compiling the Cordova "Hello World" default demo app on PhoneGap Build, installing it one time by scanning the QR code offered upon a successful installation, and then "updating" the code by changing the HTML and icon. After exiting and then relaunching the app, PhoneGap "Hydra" informed me in a full-screen view that an update was available, and presented buttons allowing me to either commit or ignore the update.
Since Phone Gap Hydration must be enabled from the PhoneGap Build web interface (in the "Settings" section which only appears after you have uploaded a project,) it will have no problem working with an application created by Alpha's PhoneGap integration. Once Hydration is enabled for a given app, it remains enabled for every update until you turn it off. As long as your Alpha Anywhere PhoneGap account settings are pointed to the correct account and named application, Hydration will be applied every time the build is re-compiled.
Page 61 of this document supplied by Alpha Software provides more details about using Hydration: http://downloads.alphasoftware.com/C...honegapdoc.pdf
http://www.alphasoftware.com/alphafo...ate-deployment
I am hoping this topic is relevant enough for the Tablet Optimized Forms forum since my company is looking forward to specializing our tablet system in a way that the devices will be geared for use exclusively within our organization, and we believe other developers may be able to benefit by an open discussion about the tricks and traps involved in creating a specialized "tablet replacement system."
I could certainly benefit from any information that eases the creation of such a system, so any tips are certainly welcome, as are any corrections if I have unwittingly misrepresented or misunderstood programs, functions and features, or their application in any way.
At risk of overstating the obvious, consumer grade tablets are loaded with apps and utilities that allow users to perform many tasks that are not relevant in the context of our company and its services and processes, and since the excellent performance of Alpha Anywhere applications is pretty much a given, we can dispense with the typical assortment of user applications and utilities, and limit user's ability to access to system controls and settings, allowing a tablet to be optimized for specific tasks as defined by the Alpha applications suite. Among other benefits of locking the tablet down to specific tasks are:
- Productivity "enforcement" (no time wasters like browsers, games, videos, or music permitted)...
- System security enhancement (device settings are not accessible by unauthorized users)...
- Anti-theft measures (the device is rendered useless if it is detached from the network under certain circumstances, and can report its location under others)
Successfully implementing these features essentially converts the tablet into a purpose-built device that is totally and strictly under management control. To us, the only feature lacking is a way to conveniently and robustly manage application updates without exposing the tablet OS and its settings to unauthorized users.
While I realize that using Alpha Anywhere's default system requires no user application "updates" since any revised applications are served from the Alpha Server as a web application, our "clipboard replacement" tablets will eventually be "kiosked," offering the user nothing but the Alpha application. This is not a problem for Alpha Anywhere in itself, since the tablet OS can easily be configured to launch a frameless browser that exclusively connects to the Alpha Server on our local network.
In order to offer the greatest amount of screen space, and to prevent casual browsing (management suggests that our mechanics need to be working, not watching cat videos on YouTube,) we would have had to select or build a chromeless browser that connects to nothing but the Alpha server, but this would have involved deploying and installing an Android or iPhone application to each mobile device, which is out of Alpha's paradigm.
Fortunately, the incredibly brilliant team at Alpha Software has leveraged the PhoneGap API which solves half of the problem as it eliminates the need to use a separate browser. Alpha made this possible by providing a UX component for PhoneGap builds that supplants the requirement for an external browser. Furthermore, PhoneGap provides an "in-app" browser, allowing the Alpha application to maintain state if the developer needs to provide browsing functions without exiting the application, which is perfect for our "kiosked" devices.
The other half of the problem involves the deployment of updates to multiple devices without having to require users to scan QR codes from PhoneGap build, send email attachments, deploy SD cards, or connect each device to a development machine for updates. Ideally, we would like to compile PhoneGap builds locally and then push them to our devices from a local server, but as yet I have found no manageable way to emulate the same style of "push" services provided by the Google Play Store or App Store from a local source.
That leaves two options;
1. Using a private channel in the Google Play store ($25.00 registration fee) or iTunes ($99.00 - $299.00+ yr, subject to a plethora of draconian rules, conditions, and other typical Apple OS complications)
2. Employ PhoneGap "Hydration," a new feature that causes the PhoneGap management app installed on target devices to detect and offer updates upon launching a PhoneGap-built app.
iPhone vs Android: Make no mistake, we love Apple devices, which are fast, solid, robust, and just plain cool, but despite the fact that Alpha Anywhere coupled with PhoneGap takes the pain away from developing apps for iPhone/iPad platforms, deploying apps for these devices from Apple authorized sources is both expensive and inconvenient, which is why we decided to eschew Apple products and invest in Android powered tablets, namely the Samsung Galaxy Note Pro 12.2. Also, our intent to "kiosk" a tablet will certainly require root access, and even possibly the ability to recompile the OS kernel, both of which are possible with the Android device.
It is unlikely that we could obtain an "unlocked" i-device from Apple, and slightly more unlikely that Apple would make its source code available for kernel adjustments (unlikely as in "not in this universe, EVER!)
Under different circumstances I would have selected the iPad as our device of choice, but they fell short of our requirements in too many ways. Sorry Apple, that's 36 missed sales opportunities, and more as we abandon our enterprise deployed iPhones in favor of a more developer-friendly platform. Besides, our system will require users to collect photos in unfavorable lighting conditions, and the Note Pro tablets are equipped with a camera flash; iPads are not, plus the Samsung's 12.2 inch screen offers a lot more space on which to run Alpha's Tablet Optimized Forms than the largest iPad. Executive management personnel who insist on keeping their iPhones can access our Alpha Anywhere dashboard apps in the usual manner via webclips.
"Certified Alphaholic" user David Kates (thanks a million, David!) was the one who provided the answer to my question on the forums regarding automatic deployment, suggesting that I check out the PhoneGap "Hydration feature," and after a brief test, it appears to suit our needs perfectly until we can figure out a way to perform the same functions from our local server, if ever.
While setting up and deploying PhoneGap-built APK's from a private Google Play Store "channel" is inexpensive and very straight-forward, there are a couple of disadvantages that cause it to fall just short of our goals.
As with any Android device, many apps downloaded from the Play Store can be set to update automatically, which would be fine if it weren't for the fact that some operations in process might be interrupted by spontaneous updates if one becomes available in the middle of a job. And even though it would be up to us to decide when to deploy updates to the store, worker processes at our company do not all start and stop synchronously, as we often operate 24/7, and regularly have technicians deployed to other parts of the world.
It makes sense then, that the user must be allowed to decide when it will be convenient to allow the update.
On the other hand, if we opt to deploy apps from the Play Store requiring manual updates, we would have to allow notifications from the Android OS, but as we don't want to expose any of the Android system controls since, we will be turning the notification areas off to avoid allowing a user to access system functions.
PhoneGap's "Hydration" feature fills the bill because it only checks for available updates upon launch of the app, as it will when the user logs on to the device at the beginning of a work day, or when other users log in to process other jobs or operations. Authenticated managers would be able to trigger updates at will.
I have tested Hydration by uploading and compiling the Cordova "Hello World" default demo app on PhoneGap Build, installing it one time by scanning the QR code offered upon a successful installation, and then "updating" the code by changing the HTML and icon. After exiting and then relaunching the app, PhoneGap "Hydra" informed me in a full-screen view that an update was available, and presented buttons allowing me to either commit or ignore the update.
Since Phone Gap Hydration must be enabled from the PhoneGap Build web interface (in the "Settings" section which only appears after you have uploaded a project,) it will have no problem working with an application created by Alpha's PhoneGap integration. Once Hydration is enabled for a given app, it remains enabled for every update until you turn it off. As long as your Alpha Anywhere PhoneGap account settings are pointed to the correct account and named application, Hydration will be applied every time the build is re-compiled.
Page 61 of this document supplied by Alpha Software provides more details about using Hydration: http://downloads.alphasoftware.com/C...honegapdoc.pdf
Comment