Databases
StackOverflow2013
Postsdbo
POStore big JSON in Titanium for iOS and android
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POStore big JSON in Titanium for iOS and android
    primarykey
    data
    text
    <h2>How the app works</h2> <p>Currently an app is in the works which utility is to explore activities in 5 regions. Each activity is represented as an JS object with a fair amount of properties. Activities can be viewed through different filters in their respective tab, for example categories or a map. Inside each main filter, there are options to filter on date, region, accessibility etc.</p> <h2>The challenge</h2> <p>There is a lot of JSON that needs to be stored on the device, and support is required for both <strong>iOS and android</strong>. In the best case scenario the data needs to be in sync with the database, and all data needs to be available on the device. The app will need to be snappy for a good experience, this means that fetching data needs to be as fast as possible. Furthermore, filtering data needs to be as snappy as possible.</p> <h2>Viable solutions considered so far (which don't quite cut it yet)</h2> <p><strong><a href="https://github.com/Monglo" rel="nofollow noreferrer">MongloDB</a> with the <a href="https://github.com/Monglo/MongloDB-Titanium-Store" rel="nofollow noreferrer">MongloDB Titanium Store adapter</a>, silver bullet?</strong></p> <p>This approach at first seemed be the silver bullet. Although the project seems promising, it is maintained by one heroic hacker, and the project is in need of some documentation. I have inspected the source, and hacked my way through the API, but to no avail, console.log and jasmine tests won't cut it this time. More important still, it is not quite finished yet, and features compared to MongoDB are missing. A great project, I hope it will catch on more and be capable enough to assist desperate titanium developers in the future.</p> <p><strong><a href="https://github.com/irlgaming/jsondb-public/blob/master/faq.md" rel="nofollow noreferrer">JSONDB</a>, only for iOS</strong></p> <p>This app really needs to work on both platforms, iOS and android, so no reason for trying this. Moreover, JSONDB works within a single context only, which would be a serious concern as well.</p> <p><strong>Ti Filesystem and JSON.stringify + JSON.parse, not memory efficient</strong></p> <p>A viable solution for saving a small list of saved items, which is also a feature in the app. But in <a href="https://stackoverflow.com/questions/5865621/how-to-parse-a-big-json-file-in-android">other posts</a> issues over memory limits with the use of JSON methods have been noticed for android. Though this might not be the least of my problem, memory efficiency overal will be a huge problem. Never have I seen benchmarks for performance with file reading and writing for Titanium, so I am not sure how big of an impact reading and writing would be. Filtering big objects is a huge concern as well, <a href="http://underscorejs.org/" rel="nofollow noreferrer">underscore</a> won't manage this kind of big data. Iterating big objects is a huge problem no matter what approach I will choose.</p> <p><strong>Big ass global object</strong></p> <p>Practically the same approach as a Filesystem, only keep it in a global. This has the same issues and is just a plain unethical practice.</p> <p><strong>SQLite, yuck</strong></p> <p>Highly document oriented JSON data to SQlite, it sounds worse than samsung galaxy fanboys. Any feedback on this?</p> <p><strong>Multiple files + SQLite to maintain + lazy load, unicorns and rainbows?</strong></p> <p>Desperate for a solution, I might be onto something in the course of writing this post. There are probably something 10-16 main categories which each 1 to 4 subcategories. Keep all the activities for a subcategory in it's own file, which is a quite slim JSON. Browsing through categories, each subcategory is rendered in it's own TableViewSection, each subcategory be appended independently to the table based on how much the user is scrolled down, effectively lazy loading the content. There is only one quite quick file read. Within this view adding more subfilters effects only the already loaded items, and iterating this items is reasonably affordable.</p> <p>Updating the data is also quite effective, only files that are subject to change are updated. A SQLite database can maintain the dates of all activities which have a expiry date, it can dynamically build it's own JSON file for the upcoming seven days or month. This will make the calendar view quite smooth for most usage. Picking future dates will be a nightmare though.</p> <p>Still the map is an issue...</p> <p>If you have read all of this, thank you. If you have experience with something similar, or might be onto something, feel free to reply! I have to quit writing, quit coding and start sleeping.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USjeroen
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POStore big JSON in Titanium for iOS and android
      1. USRamesh India
      1. VTFavorite
    2. VO
      singulars
      1. POStore big JSON in Titanium for iOS and android
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload