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

Ajax Callbacks Work on Working Preview, but not on Actual Mobile App

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

    Ajax Callbacks Work on Working Preview, but not on Actual Mobile App

    Hello everyone! I hope you're doing well!

    I seem to have hit a wall with an Ajax Callback issue on mobile devices, and I'd really appreciate some advice!

    A little background: I work for a small company related to staffing and temporary employment. My background is not in computers, unfortunately. After working for the company for a few years, I recognized that an app allowing workers to clock in and out from their phones would make life easier for everyone involved. Our database guy had built our database in Alpha Anywhere and recommended that I use it for the App. However, he explained that he did not have much experience working with mobile app development. Within the space of a couple months, I created a demo app that did everything we wanted (including wowing people at a trade show) except for communicate with our database. Our database guy then took the demo app and worked on connecting it to the database via an SQL server. Recently, he sent it to me to run through PhoneGap Build and work the bugs out. When I run it on the Working Preview, everything works just fine. When I install it on my Android phone and play with it, though, it does not communicate with the SQL server. After playing with it a bit, I have determined that the Ajax callbacks are failing--but only on my phone. I assume the issue has something to do with either plugins or the Ajax URL setting in the PhoneGap Build menu. I am not very knowledgeable about plugins, unfortunately. The Ajax URL setting appears to only be needed if you are calling the Alpha Anywhere servers, but I am not sure about that.

    Has anyone else experienced a similar issue? Thank you so much for your time!

    Sincerely,
    Alex



    #2
    could be a lot of things causing the fail, like is the db on your local machine?
    NWCOPRO: Nuisance Wildlife Control Software My Application: http://www.nwcopro.com "Without forgetting, we would have no memory at all...now what was I saying?"

    Comment


      #3
      Hi,
      Try building the apk based on the "phonegap shell" then you can check the call back and also add the component and see if it is working.

      Comment


        #4
        When I had the same problem it was because of the: URL For Ajax Callbacks in the PhoneGap Build Project settings. It seems it requires a / at the end for example https://yourdomain.com/yourappname/

        You may also want to look at your settings for same site as the documentation in the latest release shows (below), I had to set it to none after one I my PhoneGap applications similarly was not able to make Ajax callbacks and this fixed it:

        Cookies - The Google Chrome browser has introduced a new policy for handling cookies to make them "secure-by-default". See https://blog.chromium.org/2019/10/de...y-for-new.html.
        This change has been pushed out on a limited basis, but will become generally available with Chrome version 80 in February 2020. Other browsers are pledged to follow suit. This change is intended to increase security and privacy.

        A cookie's SameSite policy will be enforced to prevent cross site access to those cookies. Some 3rd party site integrations may not behave as expected once this change is in place. For example, a 3rd party payment handler/processor may rely on the previous behavior for cookies (which made the cookies available). When using version 80 or later of Chrome, the cookies will not be available to the 3rd party site.

        If a web application has a 3rd party site integration that is not working as expected, use the Chrome developer tools to view the browser's console. A message like this will likely be there:

        A cookie associated with a cross-site resource at <3rd part site> was set without the 'SameSite' attribute. It has been blocked, as Chrome now only delivers cookies with cross-site requests if they are set with 'SameSite=None' and 'Secure'. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

        Alpha Anywhere has been enhanced to default its cookies to use the most secure SameSite policy of "Strict". No changes need to be made to an application for this setting to be used. Only build 6382 or later of Alpha Anywhere Application Server or the Application Server for IIS need to be installed.

        If an application needs to have access to Alpha Anywhere system cookies such as the session cookie or authentication cookie in a cross-site way, the cookie SameSite policy may need to be set to "Lax" or "None". "None" will result in the same behavior as before the SameSite policy existed.

        The SameSite policy can be changed in one of two ways.
        For Alpha Anywhere Application Server, the cookie SameSite policy can be set in the server settings dialog on the advanced tab in the Sessions section.



        For Alpha Anywhere Application Server for IIS, the cookie SameSite policy can be set in the Web Project Properties dialog.


        David Weinstein
        Best Tech
        [email protected]t

        Comment


          #5
          Thanks for the detailed information on this since I think I have been running into this issue. However, when I set the Same Site value to "None" my Phone Gap apps starts working but the login for my web app start failing (it goes straight the logout screen). So my basic question is can one web application server now support both a phone gap application and a web application at the same time (same URL) since they appear to require different same site settings?

          Comment


            #6
            Hi, I wondered if you ever figured out the answer to your question in the last post: "So my basic question is can one web application server now support both a phone gap application and a web application at the same time (same URL) since they appear to require different same site settings?". I have the same issue.

            Comment


              #7
              It can support both. We run numerous applications from one server that have both a web based front end and a mobile version, both with the same endpoint url.

              Comment

              Working...
              X