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

Any benefit to using client side data cache vs persisted lists?

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

    Any benefit to using client side data cache vs persisted lists?

    Hello. I am creating a PhoneGap app that needs to give users access to a read-only address master file while disconnected. It currently gets downloaded after the user logs in to the app and is used to populate a list via the "setListColumnsAndPopulate" method. I can then query the list using the "listObj.getData" method to obtain address info for every property id that exists in another table (list) the app uses.

    This works fine but I'm confused about the difference between just using a list control that's persisted to local storage/file system versus the client side data cache process. With data cache, it appears I can't update it and sync changes back to the server automatically, whereas with a list control I can. And isn't using data cache and then populating a list control with it the same as using a persisted list populated initially from a SQL table? Are there other benefits to using the client side data cache that I'm missing? Are there JS functions available to let me search client side data cache files so I don't have to populate lists with them first? Does populating a list with the client side data increase the amount of storage used by the mobile app or does the list simply point to the client side data as its source?

    Thanks for any insights you can offer...

    #2
    Re: Any benefit to using client side data cache vs persisted lists?

    A few considerations:

    - With client side data cache, you don't have all the overhead of the List control (for example, even if you "hide" the list control, you'll be rendering the list HTML in the background nevertheless). That being said, even if you are not going to show the list anywhere where the user can actually see it, I would do "Dynamic" List Virtualization anyway.
    - In the past I've seen some features that only work ("only" as in: without some extra coding) with client side data caches. It may no longer be the case but I remember only being able to place markers on a map based off data from data cache and not being able to based off a list control.
    - But with data cache, as you know, you lose tons of features available with list controls and especially list controls with detail views (even if you aren't planning to sync back to the backend database).
    - I personally like the offline client side filtering you can do against a list control. Not sure how easy it is to "filter" the data cache data.
    - I think having a list with lookup columns based off a read-only "list" is pretty easy to set up versus, perhaps, doing the same sort of thing based off a data cache. Plus the lookup columns data gets stored (and persisted in your case) with the list data.
    - Finally, I have a feeling that the documentation is better for list controls versus data cache but it could just be that there isn't much to data caches that require a lot of documentation or it could be that I haven't worked with them enough requiring me to search for more documentation
    Last edited by jgrannis; December 19, 2017, 12:30 PM.

    Comment


      #3
      Re: Any benefit to using client side data cache vs persisted lists?

      Tom, it kinda sounds like you could go another route. If you want to deliver data to your device... and then load a subset of that data into a List... you could use SQLite, which Alpha supports.

      Comment


        #4
        Re: Any benefit to using client side data cache vs persisted lists?

        We went the SQLite route for this sort of situation before the possibility of persisting list control data to the filesystem (added in Spring of 2017, I believe).

        We just have had some headaches dealing with the async nature of the calls to SQLite. Ie. Moving on and trying to work with the resultArray before the transaction is actually complete. We were getting a lot of transaction queues which we pretty much resolved through using well placed settimeouts.
        We still get hard to replicate, "the database is open" situations where the app just hangs and we can't figure out how to force the database to close.

        Comment


          #5
          Re: Any benefit to using client side data cache vs persisted lists?

          Additional consideration:

          I find that the list control has some powerful pre-built features if your list data includes images (either by storing the path to the image or in BLOBs). Not sure it would be as easy to work with images stored in a client side data cache (nor SQLite... I've been fighting a little also with images stored in SQlite).

          Comment


            #6
            Re: Any benefit to using client side data cache vs persisted lists?

            Like everything else... it's what tools are needed... and how you work with those tools. I have an app in the Apple Store using SQLite and did encounter specific issues during development... which were all fixed with code correction and logic flow correction. Whatever issues I encountered... I created... and then fixed.

            Comment


              #7
              Re: Any benefit to using client side data cache vs persisted lists?

              David, Jeff, thanks for your input on this! Will take a look at SQLite, see how it works in the app and then decide on the best route to take...

              Comment


                #8
                Re: Any benefit to using client side data cache vs persisted lists?

                David & Jeff, thanks again for your feedback about this. After testing my app with Client Side Data Cache, SQLite and persisted List controls, I finally decided to go back to using lists. As you both mentioned, I too experienced timing issues with SQLite that proved to be overwhelming. Although setting the database up and getting it to download worked perfectly, often the resultArray and other data items affected by queries weren't populated before subsequent JS calls tried to access them. Also, I didn't want to have to build delays into my app or spend time figuring out how to actually make them work properly.

                I could have used the data cache for some read-only tables and did get it working without too much effort, but it finally just seemed easier to use list controls for everything. The built-in client/server synchronization options and all of the data lookup and update capabilities made the app come together without a lot of extra effort using lists.

                It was a great exercise in exploring options and now I have a much better understanding of each approach. I also think spending some time with the actual SQLite documentation would help in working around some of the timing issues. If you have any other resources you think I should check out as well, please let me know.

                I am grateful for all of your contributions to this forum!

                Comment

                Working...
                X