I need your opinion in which do you think are the best practices to do multiple queries to cloudkit.
I've an app that has a Main feed - I query this feed when the app launches and everything works perfectly, but I want to achieve , or at least understand how it's done in the, for example, Medium app for iOS for the bookmarks tab.
In the Medium app, after the first query in app launch if you click on the Bookmarks tab, all the posts are 'already there' so I assume they query that table asynchronously after the first query.
I thought that I could do a second query , after the first 'main' one, to the bookmarks table for the given user, and fill an array with those objects, then populate the table view as soon as the user clicks the tab.
My worries are on having an array, which main contain a lot of data and it's not used, and even could not be used for a good portion of the time during the app usage
Do you think that is a good practice or that I could achieve this on a different approach?
Thanks ;)
Related
I'm using Firebase database for my application, and basically people post new chapters of different series into the app.
So, I have one parent called "series" which hosts information about the different series:
Then, I have one parent called "chapters" which contains many different children that are the different series keys, and under them are many chapters (so the chapters are under each series).
However, I also want to have a section of the app where the user can view all newly added chapters across all different series, so I made a "latestReleases" parent, which automatically gets added to whenever a new chapter is added to "chapters."
However, the way I am currently displaying latestReleases is to add the entirely of "latestReleases" to an array and then sort by date. Although with a small amount of chapters this works fine, there are now thousands of chapters, so there are thousands of things in latestReleases. Therefore, it takes literally forever for it to load. There must be a better way to do this, correct? I feel like a better way would be to only load part of the latestReleases, and then the user can choose to load more incrementally. However, it this possible? How else would I be able to achieve this? Would I need to create several "latestReleases" parents that get updated automatically? Thanks!
I've built a Rails app, basically a CRUD app for memos/notes.
A notes title must be unique. If a user enters a name already taken a warning message is shown prompting them to chose another.
My question is how to make this latency for this feedback as close to zero as possible. When creating a note little UX speed bumps like this will get annoying for user quickly.
Of course the main bottleneck is the network. Inspired by Meteor (and mini-mongo) I was thinking some kind of local storage could be a solution?
I.E. When app first loads, send ALL JSON to the client with ALL note titles. The app (front end is Angular JS) could check LocalStorage (or App Cache, Web SQL?) instead of incurring a network round trip. The feedback would be instant.
I've used LocalStorage in the past to augment an app, but in the scenario it'd really seriously depend on it. I'm not sure how confident I'd be building on something that user might not have. Also as the number of user Notes/Memos I have doubts how feasible it is to send a JSON object down the wire with ALL the note titles. That might get pretty big. On the other hand MeteorJS seems to do this with no probs.
Has anyone done something similar or have any pointers? Thanks!
I don't know how Meteor works here, but you're right that storing all note titles in localStorage is not a good idea. Actually, you don't need localStorage here, you can just put it in a JS array, because you need this data only once (when checking new note title).
I think, there could be 2 possible solutions:
You can change your business requirements and allow non-unique title. Is there really a necessity for titles to be unique?
You can verify note title when user submits form. In this case you can provide suggestions for users, so they not spend time guessing vacant title.
Or, if titles must be unique only within a user (two users can have same title for their notes), you can really load all note titles in JS array and check uniqueness while users types in a title.
Or you can send an AJAX request checking title uniqueness as soon as user finished typing the title. In this case you can win some seconds.
Or you can send an AJAX request as soon as user typed in 3 symbols. The request will return all titles that begin with these 3 symbols, so you don't need to load all the titles.
I am building a simple informational based app that provides the users with built in Leaflets and Images to view, on a variety of topics. It's a UITabBar -based application where the first tab is a list of Leaflets, the second is a list of Videos and the third is a list of Languages. Each tab is represented by a UITableViewController.
I would like to set up a favouriting mechanism where users can swipe across any leaflet or video in the UITableViewCell and "favourite" it. Whichever they favourite will then get added to the 4th tab called (unimaginatively), Favourites.
I'm not using Core Data with this application because there's no real need to do that and because I'm quite new to this concept, I'm wondering on the best way to save up to 50 favourites. How would I store this? Would I use something like a NSUserDefault for example?
It's a broad question because I've looked online and I'm not quite sure how to approach this.
I would really appreciate if anyone had any guides or thoughts on how to firstly save this and secondly, how to fetch the favourites for the favourites tab. Would/Could I use something like a NSFetchedResultsController even though I'm not using Core Data?
Should I just use Core Data with this, to save the favourites?
Any thoughts on this would really be appreciated.
I am currently working on an application in Rails (though language/framework shouldn't matter for this question since it is more of a theoretical one). I'm working on wrapping my head around this problem:
Say I am tracking millions of blogs online and am plugged into their RSS feeds. My app pings these feeds every few few minutes to see if there has been any new activity across any of these millions of blogs. If there is any new activity, I want to alert users of my application who have signed up to receive alerts for specific blogs that there has been an alert.
Does it make sense to have a user_blog_alerts table (where a user can specify custom keywords to be alerted about) and continuously check this table against every new entry that comes in from my feed? And when there is a match, to add them to a queue (using Redis)?
What is the best, most efficient way to build and model this alerting system? Am I even thinking about this in the right way? Are there any good examples or tutorials on this when working with such large amounts of data?
I'm not sure what the right way to do this is, but the thought of continuously scanning a table over and over sounds exhausting (ie. unscalable).
Off the top of my head, what if you created a LIST for every blog in Redis. The values would be the user IDs of those who wanted an alert. The key name would contain the blog id (ex: "user_blog_alerts:12345").
Then when you got a new post for blog 12345 it's a simple lookup to see if that key exists. If it does, then fire off alerts for each user in the list.
I'm looking to get some insight on a project of mine before I get too deep into it with possibly a poor setup. The app is a simple database collection with a few table views.
Quick example:
First table view is populated with teacher names. Select the teacher and the next table view is populated with all of the students in that class. Further, select that student and an info view arises with details for that student.
The plan is to use SQLite, so I'm looking to make sure I set views up properly to make it easier on myself later.
My thoughts so far:
TeacherViewController - Grab info from DB to populate the table view. Contains segue within didSelectRowAtIndexPath to jump to StudentView.
StudentViewController - Again grabs info from the DB from that teacher's table to populate with students, with a segue to jump to info page.
StudentInfoView - Contains the forms ready to be populated with info.
There needs to be the ability to add teachers, as well as add students within each teacher/class. Since I haven't dove into SQLite yet, I'd like advice from those experienced.
Thanks, and let me answer any questions you may have.
The most important thing I have found when using SQLite is to ensure that you arrange your views in line with large data captures.
For instance I have a word game and the most intense call to the DB is to generate the starting position of the game. So I do this in a separate thread whilst playing a tutorial, when the viewController first loads. The rest of the calls are quick and easy so can be done at the required time within the game without any impact on performance (i.e. this includes lines like select count(*) from six where word = '%#' - where the DB table has 22000 words)
You will find that sqlite calls are very quick. I think your approach sounds fine as the large calls will be done on the load of the viewControllers where you can easily add loading indicators.
One thing to bare in mind - which can get an app rejected is where you store the sqlite db - because if it is to large then you need to ensure that it isn't backed up via iCloud without asking the user for permission.