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!
Related
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 ;)
Im working on the search feature for my app and I would like to give users the option for some sorting of viewing the recipes. Im trying to make a popular feature but Im not entirely sure where to start and if I need to make any modifications to my schema. Ive read this post http://sorentwo.com/2013/12/30/let-postgres-do-the-work.html and get the jist of what its doing. My main question is how do I track when a page is viewed and use that in the calculations? And also track views over time?
Also for using things like comments as a weight is it better to count the number of comments dynamically (query the comment table and add them up) or keep a column in the recipe table that gets added to whenever a comment is added?
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.
I'm building a web app for bookmark storage with a directory system.
I've already got these collections set up:
Path(s)
---> Directories (embedded documents)
---> Links (embedded documents)
User(s)
So performance wise, should I:
- add the user id to the created path
- embed the whole Paths collection into the specific user
I want to pick option 2, but yeah, I dunno...
EDIT:
I was also thinking about making the whole interface ajaxified. So, that means I'll load the directories and links from a specific path (from the logged in user) through ajax. That way, it's faster and I don't have to touch the user collection. Maybe that changes things?
Like I've said in the comments, 1 huge collection in the whole database seems kinda strange. Right?
Well the main purpose of the mongoDB is to support redundant data.I will recommend second option is better because In your scenario what I feel that if you embed path collection into the specific user then by using only single query you can get all data about user as well as related to path collection as well.
And if you follow first option then you have to fire two separates queries to get all data which will increase your work somewhat.
As mongodb brings data into the RAM so after getting data from one collection you can store it into cursor and from that cursor data you can fetch data from another collection. So if we see performance wise I dont think it will affect a lot.
RE: the edit. If you are going to store everything in a single doc and use embedded docs, then when you make your queries make sure you just select the data you need, otherwise you will load the whole doc including the embedded docs.
I need to generate a user interface for entering a sales document (eg invoice). I'm trying to use components of "developer express" specifically the QuantumGrid component (TcxGrid). I've seen the demos of master-detail components and search in the devexpress support center, but none has helped me because all use 2 grids to handle the master-detail relation, and edit multiple records at once.
I just need to edit a record (document) at a time and using a pair of objects dataware components (eg TDBEdit) in the header and a grid to handle the detail.
something like this
Where can I find a basic example of using these components in this way?
Tthe Master/Child properties in the QuantumGrid are mainly designed to nest multiple items in the grid. If you setup the relationship in the data components you can simply hook the controls up to the correct DataSource and everything will work.
So if you have two DataSets Customer and Invoice. The Invoice Master Datasource is the Customer DataSource. Then on your edit controls you point to the Customer DataSource and you point the Grid to the Invoice DataSource.
If you think about what the Master/Detail relationship is doing it really just filters the records on the Detail DataSet to match the current record on the Master DataSet. Individual Edit controls will always display the "current" record in the DataSet they are connected to. Grids will show all visible records in the DataSet they are connected to.
I have a tendency to not use Master/Detail relationships in an edit form like you show here. I'm assuming there is some way on a different screen to pick the invoice to edit. I usually create a copy of the needed DataSets with only the records needed for this edit. If I am editing a existing invoice I copy the current records. If it is a new invoice I can start off with an empty recordset. It is more work - I have some generic library functions that will copy a DataSet Structure and then copy one or more records into that Dataset. Depending on your setup you can also requery your Database to just get the records you are interested in. Obviously that should not be done in all cases. Another issue with this approach is you need a way to update any other Datasets you may have with this data - i.e. your main search screen.
However, once I get on the edit screen I find it makes things eaiser. Now I don't need to worry about the master detail relationship at the top level. If the invoice has internal Master/Detail relationships you can just deal with those, but you know that the DataSets only have the data for this one invoice - not everything in the Database.
In the case of your form if you limit the Data in the DataSets you can just hook everything up directly and it should work as you expect. You would only have one record in the Customer DataSet and the invoice would just have the records for this Invoice.
I think you'll need to take care of the master-detail relations in your ClientDataSource components. The grid will then follow this relation.
Why don't you ask this at support#devexpress.com ?
The reason why I have a vcl subscription is, apart from the quality of the components of course, because they do have a great support site and staff ?
There you ask it directly to the people who have written the stuff, and they are most likely happy to supply you with a sample program (at least I have received a lot of samples over the years).
The premise is the same as with any other master-detail relationship, regardless of the components. You will need to setup the master-detail on the dataset level to accomplish what you want.