Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

FYI: Automatically "pushing" updates to deployed devices

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    FYI: Automatically "pushing" updates to deployed devices

    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:
    • 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
    Last edited by mbunds; 08-08-2015, 04:18 PM.

    #2
    Re: FYI: Automatically "pushing" updates to deployed devices

    Mark,

    Thank you for this discussion. You have brought up a number of important topics that we also have to consider. We have the same situation, only different.

    In our case, we do the inspection, but other companies do the fixes. We are setting up a training center for these other company installers to train them how to do the fixes properly and want to provide them with a tablet stocked with helper apps as part of their tuition. The installers "all" have iPhones, but we can certainly select any tablet we want for this purpose.

    So, our additional issues are:
    Do we care what they do with the tablet after we "give" it to them?
    I think the answer is yes, because if they mess up something, they will claim that "our" tablet doesn't work and expect us to fix it.

    We will be adding and updating more apps as we go. How do they add/update these apps to their tablets?
    I'd like to be able to create a microSD card they can slip into their tablet (again, not an iPad) to do the adds and updates. I'm wondering if a tablet app could access the SD card and do adds and updates. If so, perhaps we could use an internal serial number to make sure it is only done on the specific tablets.

    Let's keep this thread going....
    Pat Bremkamp
    MindKicks Consulting

    Comment


      #3
      Re: FYI: Automatically "pushing" updates to deployed devices

      Not sure if hydration needs to be an issue. I guess it depends upon how you build your app. Alpha only builds the top most parent UX in a phonegap build. Child UX's are rendered via AJAX callbacks, meaning you need to have connectivity. If you are building disconnected apps keep in mind you can't run any xbasic dynamically if you are disconnected.
      Peter
      AlphaBase Solutions, LLC

      [email protected]
      https://www.alphabasesolutions.com


      Comment


        #4
        Re: FYI: Automatically "pushing" updates to deployed devices

        Originally posted by Peter.Greulich View Post
        Not sure if hydration needs to be an issue. I guess it depends upon how you build your app. Alpha only builds the top most parent UX in a phonegap build. Child UX's are rendered via AJAX callbacks, meaning you need to have connectivity. If you are building disconnected apps keep in mind you can't run any xbasic dynamically if you are disconnected.
        We will be building offline-capable apps exclusively, so we would avoid any features that require connectivity in order to function, with the possible exception of maintenance utilities which would only be run within the plant network.

        So far, it appears that the functionality provided by Alpha Anywhere will allow us to avoid having to code anything exotic enough to require the use of dynamic xbasic, and it is more likely that we would create native Android applications using Eclipse for support of exotic functions if they ever became necessary, most likely for performance enhancement.

        As of now, nothing we plan to create falls outside of Alpha's intrinsic capabilities, so I am confident we won't run into any serious roadblocks on the Alpha side of things.

        Comment


          #5
          Re: FYI: Automatically "pushing" updates to deployed devices

          Originally posted by Pat Bremkamp View Post
          Do we care what they do with the tablet after we "give" it to them?
          I think the answer is yes, because if they mess up something, they will claim that "our" tablet doesn't work and expect us to fix it.
          If your reputation is at any risk due to the possible actions of your users, then you are looking at the very reason Apple is so careful about the quality of apps they allow to be deployed from their stores, even the "private" ones. I'm sure they realize that poor quality apps reflect badly upon their company despite the fact that they did not create them, because some users don't understand that a poorly-performing app can be created despite running on a otherwise excellent platform. It is also common for users to unintentionally install malware, or deliberately tinker with the system in a way that invites all kinds of trouble, and then blame the provider.

          Our system would be exclusive to our company, relieving us of many of the complications involved in distributing apps to a more "public" forum. If my company were presenting tablet systems to external vendors exclusively for purposes related to our business, my decision would be the same: Provide locked-down, "purpose built" systems that restrict user access to those processes that management deems necessary for them to perform these functions, otherwise the tablets would be vulnerable to the disadvantages mentioned above.

          Having said all of this, it would be a simple matter to make the same apps available for download and installation via a public or private repository like Google Play for Android, or Apple's App Store (which is one of the reasons Alpha has integrated the PhoneGap API), as these are the best avenues so far for pushing updates when devices are deployed into the wild, and when users can be trusted to manage their own device.

          We chose the Android platform because the OS is open source, and Android APK's are not subject to the same scrutiny as those targeting Apple devices if we ever need to make apps available to larger user bases, although we would have them served from a private store rather than the public one.

          Originally posted by Pat Bremkamp View Post
          We will be adding and updating more apps as we go. How do they add/update these apps to their tablets?
          I'd like to be able to create a microSD card they can slip into their tablet (again, not an iPad) to do the adds and updates. I'm wondering if a tablet app could access the SD card and do adds and updates. If so, perhaps we could use an internal serial number to make sure it is only done on the specific tablets.
          A tablet app certainly can access SD card storage, but each tablet has to be configured to allow "side-loading" of third-party apps, which is fairly simple on an Android device, but impossible on an Apple device unless it is being accessed using a valid developer's license ($99.00 yr. +restrictions), or it has been "jailbroken", which is never allowed within an enterprise environment for obvious reasons.

          Deploying apps using SD cards was not a viable option for us because this would require corralling all of the devices for updates, or tracking each device that had been updated, or not, applying the updates in a piecemeal fashion which never works out well.

          Since our fondest wish is to keep "hybrid app" update availability as close to our local system as possible, we found that PhoneGap with Hydration enabled seems to be as close as we can get for now. Using this method, the updates still come from "the cloud" as they are compiled and served from the Adobe PhoneGap servers, which is not as desireable as it would be to push them from our local servers, but it will serve our needs until I can figure out how to automate local PhoneGap builds using command interfaces and the Android API, and then push them out of our server.

          Comment


            #6
            Re: FYI: Automatically "pushing" updates to deployed devices

            pat bremcamp and mark bunds
            good morning to both of you.
            you have indicated about the personal use of your ipad or apple not allowing you to modify the kernel to use ipad, which both of you seem to like, in a kiosk mode or store mode whichever way it is called, I like to bring to your attention to an article I came across that might be of interest to you
            http://www.webascender.com/Blog/ID/4...p#.Vcx-fs9RHIU
            there seems to be a method, guided access, to run single app primarily meant for kid safe ipad, may be you can adopt to your needs?
            I am not as experienced as you both are, and do not have need for that yet. so it is not coming from personal experience. just by reading the article.
            if it is not useful, please ignore this.
            thanks for reading

            gandhi

            version 11 3381 - 4096
            mysql backend
            http://www.alphawebprogramming.blogspot.com
            [email protected]
            Skype:[email protected]
            1 914 924 5171

            Comment


              #7
              Re: FYI: Automatically "pushing" updates to deployed devices

              +GGandhi - Thank you for this, it is extremely useful information!

              While Apple devices are not viable in our environment, they are a very good platform for other companies who will want to have options allowing them to secure their tablets.

              Any information related to ways to secure mobile devices is invaluable since options that will work for some customers may not be useful to others. Advice from users who consider themselves to be inexperienced can be extremely useful, because these individuals will usually seek the path of least resistance, exposing simple methods to those of us who often become lost in the details.

              So, thanks again!

              Comment


                #8
                Re: FYI: Automatically "pushing" updates to deployed devices

                First, I want to correct a statement made by Peter Greulich in his post on this thread where he states: "Alpha only builds the top most parent UX in a phonegap build. Child UX's are rendered via AJAX callbacks, meaning you need to have connectivity. If you are building disconnected apps keep in mind you can't run any xbasic dynamically if you are disconnected."

                This is no longer true. Starting in V3.5 there is a new option for how child UX component should be loaded.

                See the new property "Optimization" which appears for embedded components and components loaded using Action Javascript.

                You can specify that the load method should be "AjaxCallback", "Precomputed" or "AjaxIfOnLine_PrecomputedIfOffLine" and "Dynamic"

                Before V3.5 the only option was "AjaxCallback". But if you choose "Precomputed" the child component is rendered at the time the PhoneGap application is built and at runtime when you load the component it is loaded from the local PhoneGap package. In other words there is no need to make an ajax callback and therefore it does not matter if you do not have a connection.

                The "Precomputed" option is recursive. So if a parent UX loads 'uxChild1' using the 'precomputed' option, and 'uxChild1' loads 'uxGrandChild1' using the 'precomputed' option then at build-time all of the components (the parent Ux, uxChild1 and uxGrandChild1) will be pre-rendered as part of the PhoneGap package and there will be no ajax callbacks necessary to load the child, or grand child.

                The "dynamic" option allows you to write Javascript to decide whether to make an Ajax callback or to load the local copy of the child component.

                This feature is discussed in the V3.5 release notes.

                The next point I would like to make is that while PhoneGap Build Hydration is certainly a great, useful feature, my personal opinion is that it is really to be used while you are developing and testing an app and it is not really ideal for a deployed app. However, while you are in the design phase of an app, I think that using a "shell" application (search in the "Rre-release notes for 'PhoneGap - PhoneGap Shell ') is actually a better solution.

                So, having stated that Hydration would not be our first choice for getting updates out to a deployed PhoneGap application, the question remains, how would we recommend that you approach the problem?

                I believe that the best solution would be one that allows the PhoneGap application to make a callback to the Alpha server to see if a new version is available and then, if one is, to "fetch" the new version and then store it in a file on the device. Then, when the application loads, it can check to see if a newer version has been stored in a file on the device and if a newer version is found, then the component would be loaded from this file. While a developer could implement this today by writing their own code, (it would be a fair amount of code) I think that this is a pattern that many users would like to employ and we expect that at some point Alpha will build this pattern into the UX component as a 'feature' that can be used without requiring any programming.

                In effect, what I am proposing here, is a solution that does not require the developer to put updates to an app in an app store. Only the initial version of the app needs to be in the store, and then all subsequent updates to the app are managed by Alpha based on settings that the developer makes in his/her UX components.

                Comment


                  #9
                  Re: FYI: Automatically "pushing" updates to deployed devices

                  Originally posted by Selwyn Rabins View Post
                  I believe that the best solution would be one that allows the PhoneGap application to make a callback to the Alpha server to see if a new version is available and then, if one is, to "fetch" the new version and then store it in a file on the device. Then, when the application loads, it can check to see if a newer version has been stored in a file on the device and if a newer version is found, then the component would be loaded from this file. While a developer could implement this today by writing their own code, (it would be a fair amount of code) I think that this is a pattern that many users would like to employ and we expect that at some point Alpha will build this pattern into the UX component as a 'feature' that can be used without requiring any programming.
                  Companies creating locked-down mobile systems may consider this functionality to be critical enough to sway their opinion toward Alpha over other packages.

                  That is probably the direction I would have headed after hammering out the details of our core application functionality. In a nutshell, if I understand PhoneGap functionality well enough, we would need to install the required SDK's for our target platform(s), programmatically (or manually) manipulate the Cordova CLI to generate new packages locally, check the revision folder from the remote app, grab the file and store it on the mobile device, then trigger the installation of the new package.

                  Then again, I wonder if I am over-thinking the need for this?

                  Since we want to limit users to Alpha applications served from the Alpha server, our main concern is that the locked-down devices could require occasional updates to a custom, "frameless" browser, but would they?

                  The Android devices we will use will be rooted to allow control over the system functions made available to our users, so a custom browser could be installed during the initial commissioning and configuration of a device, but does the PhoneGap package provide more functionality for our purposes, in terms of access to on-board sensors, than Alpha running in the browser?

                  Our most important requirements for mobile devices beyond the usual data collection and information presentation functions are the ability to take and store photos, collect signatures and hand-written notes, and possibly the ability to record and store short videos or audio notes, which I don't believe require the use of Phone Gap since it appears that Alpha Anywhere will provide (at least the first two) of these functions running from within a browser.

                  Expanded functionality would be required for remote, cellular-connected field service devices, like presenting a GPS application within a modal window, which I don't think could be launched from within a browser, and I don't know if other sensors like the accelerometers, gyro's, or the compass can, so these may require API-specific applications to be compiled with the appropriate PhoneGap plugins. But for basic plant floor data collection and information presentation, do we need to use PhoneGap to build a locked-down device?

                  Comment


                    #10
                    Re: FYI: Automatically "pushing" updates to deployed devices

                    So, then, if I understand what you are proposing, Selwyn, if I can predict what all my applications will be, I could load a "Master App" from the app store and pull the applications as sub-apps from our own server as they become available. If so, that will give us a great deal of control.

                    I like it.
                    Pat Bremkamp
                    MindKicks Consulting

                    Comment


                      #11
                      Re: FYI: Automatically "pushing" updates to deployed devices

                      It's been awhile, but I finally got a chance to play with the PhoneGap shell, and it seems too good to be true!


                      Using the shell is like having the best of both worlds; the only time the project needs to be rebuilt using PhoneGap is if changes have been made to PhoneGap plug-ins, but any changes to the Alpha app can be instantly reloaded from the local server!

                      It appears that the PhoneGap shell could be modified to "hide," then the server could push messages to the tablet fleet notifying users that an app update is available. This could provide us with the control over when an update is applied, allowing us to optionally delay notifications until the user has finished and closed the last job, and with the use of web- sockets, we could poll the fleet and trigger updates automatically on units that were not executing a job!

                      It also appears that PhoneGap CLI could be employed on a server to perform " local builds", but a method for pushing them out to the fleet has yet to be explored.

                      Regardless, even if no practical means can be found for pushing out the APK's built on a local machine, rebuilding the PhoneGap shell isn't necessary nearly as often as rebuilding the AA UX components, and the PhoneGap shell's "refresh" functionality has that handled perfectly!

                      Comment


                        #12
                        Re: FYI: Automatically "pushing" updates to deployed devices

                        It maybe that in near future installing apps like we now do is just history. First signs can already be seen. Google App Streaming and Apple On Demand Resources.
                        Soon we are streaming apps so no need to push updates.

                        Comment

                        Working...
                        X